Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue 03-04-18 10:17:53, Steven Rostedt wrote: > On Tue, 3 Apr 2018 15:56:07 +0200 > Michal Hocko wrote: [...] > > I simply do not see the difference between the two. Both have the same > > deadly effect in the end. The direct OOM has an arguable advantage that > > the effect

Re: [PATCH v1] kernel/trace:check the val against the available mem

On Tue 03-04-18 10:17:53, Steven Rostedt wrote: > On Tue, 3 Apr 2018 15:56:07 +0200 > Michal Hocko wrote: [...] > > I simply do not see the difference between the two. Both have the same > > deadly effect in the end. The direct OOM has an arguable advantage that > > the effect is immediate rather

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 08:03:56AM -0700, Paul E. McKenney wrote: > On Tue, Apr 03, 2018 at 04:43:00PM +0200, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 07:17:18AM -0700, Paul E. McKenney wrote: > > > Suggestions for a fix? Clearly great care is required when using it > > > in things like

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

On Tue, Apr 03, 2018 at 08:03:56AM -0700, Paul E. McKenney wrote: > On Tue, Apr 03, 2018 at 04:43:00PM +0200, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 07:17:18AM -0700, Paul E. McKenney wrote: > > > Suggestions for a fix? Clearly great care is required when using it > > > in things like

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/4/3 13:23, Jaegeuk Kim wrote: > > On 04/03, Chao Yu wrote: > >> On 2018/3/31 0:30, Jaegeuk Kim wrote: > >>> Change log from v1: > >>> - add more description > >>> > >>> This fixes xfstests/generic/392. > >>> > >>> The failure was caused by different times

Re: [PATCH v2] f2fs: remain written times to update inode during fsync

On 04/03, Chao Yu wrote: > On 2018/4/3 13:23, Jaegeuk Kim wrote: > > On 04/03, Chao Yu wrote: > >> On 2018/3/31 0:30, Jaegeuk Kim wrote: > >>> Change log from v1: > >>> - add more description > >>> > >>> This fixes xfstests/generic/392. > >>> > >>> The failure was caused by different times

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > Initialize UEFI secure boot state during dom0 boot. Otherwise the > > kernel > > may not even know that it runs on secure boot enabled platform. > > > > Signed-off-by:

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote: > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > > Initialize UEFI secure boot state during dom0 boot. Otherwise the > > kernel > > may not even know that it runs on secure boot enabled platform. > > > > Signed-off-by:

Re: [PATCH v5 3/3] MIPS: use generic GCC library routines from lib/

On Tue, Apr 03, 2018 at 10:24:26AM +0100, Matt Redfearn wrote: > From: Antony Pavlov > > The commit b35cd9884fa5 ("lib: Add shared copies of some GCC library > routines") makes it possible to share generic GCC library routines by > several architectures. > > This commit

Re: [PATCH v5 3/3] MIPS: use generic GCC library routines from lib/

On Tue, Apr 03, 2018 at 10:24:26AM +0100, Matt Redfearn wrote: > From: Antony Pavlov > > The commit b35cd9884fa5 ("lib: Add shared copies of some GCC library > routines") makes it possible to share generic GCC library routines by > several architectures. > > This commit removes several generic

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

+int logic_pio_register_range(struct logic_pio_hwaddr *new_range) +{ + struct logic_pio_hwaddr *range; + resource_size_t start = new_range->hw_start; + resource_size_t end = new_range->hw_start + new_range->size; + resource_size_t mmio_sz = 0; + resource_size_t

Re: [PATCH v17 01/10] LIB: Introduce a generic PIO mapping method

+int logic_pio_register_range(struct logic_pio_hwaddr *new_range) +{ + struct logic_pio_hwaddr *range; + resource_size_t start = new_range->hw_start; + resource_size_t end = new_range->hw_start + new_range->size; + resource_size_t mmio_sz = 0; + resource_size_t

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On 04/03/2018 06:52 PM, Mark Brown wrote: On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: As long as sun4i/sun6i SPI drivers have overriden the default "wait for completion" procedure then we need to properly handle -ETIMEDOUT error from transfer_one(). Why is this connected to

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On 04/03/2018 06:52 PM, Mark Brown wrote: On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: As long as sun4i/sun6i SPI drivers have overriden the default "wait for completion" procedure then we need to properly handle -ETIMEDOUT error from transfer_one(). Why is this connected to

Re: [PATCH V3 4/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Tue, Apr 03, 2018 at 03:32:21PM +0200, Thomas Gleixner wrote: > On Thu, 8 Mar 2018, Ming Lei wrote: > > 1) before 84676c1f21 ("genirq/affinity: assign vectors to all possible > > CPUs") > > irq 39, cpu list 0 > > irq 40, cpu list 1 > > irq 41, cpu list 2 > > irq 42, cpu list 3

Re: [PATCH V3 4/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Tue, Apr 03, 2018 at 03:32:21PM +0200, Thomas Gleixner wrote: > On Thu, 8 Mar 2018, Ming Lei wrote: > > 1) before 84676c1f21 ("genirq/affinity: assign vectors to all possible > > CPUs") > > irq 39, cpu list 0 > > irq 40, cpu list 1 > > irq 41, cpu list 2 > > irq 42, cpu list 3

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

On 04/03/2018 12:56 AM, Greg KH wrote: > On Mon, Apr 02, 2018 at 02:52:31PM -0600, Shuah Khan wrote: >> vhci_hcd module can be removed even when devices are attached. Fix to >> prevent module removal when devices are still attached. >> >> Signed-off-by: Shuah Khan >> ---

Re: [PATCH] usbip: vhc_hcd: prevent module being removed while device are attached

On 04/03/2018 12:56 AM, Greg KH wrote: > On Mon, Apr 02, 2018 at 02:52:31PM -0600, Shuah Khan wrote: >> vhci_hcd module can be removed even when devices are attached. Fix to >> prevent module removal when devices are still attached. >> >> Signed-off-by: Shuah Khan >> --- >>

Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges

On Tue 03-04-18 10:58:53, Johannes Weiner wrote: > On Wed, Mar 21, 2018 at 09:59:28PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > David has noticed that THP memcg charge can trigger the oom killer > > since 2516035499b9 ("mm, thp: remove __GFP_NORETRY from

Re: [PATCH] memcg, thp: do not invoke oom killer on thp charges

On Tue 03-04-18 10:58:53, Johannes Weiner wrote: > On Wed, Mar 21, 2018 at 09:59:28PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > David has noticed that THP memcg charge can trigger the oom killer > > since 2516035499b9 ("mm, thp: remove __GFP_NORETRY from khugepaged and > >

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: > As long as sun4i/sun6i SPI drivers have overriden the default > "wait for completion" procedure then we need to properly > handle -ETIMEDOUT error from transfer_one(). Why is this connected to those drivers specifically?

Re: [PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

On Tue, Apr 03, 2018 at 06:29:00PM +0300, Sergey Suloev wrote: > As long as sun4i/sun6i SPI drivers have overriden the default > "wait for completion" procedure then we need to properly > handle -ETIMEDOUT error from transfer_one(). Why is this connected to those drivers specifically?

Re: [PATCH 14/15] ARM: pxa: change SSP devices allocation

On Tue, Apr 3, 2018 at 5:32 PM, Robert Jarzmik wrote: > Arnd Bergmann writes: > > chop chop ... removed several mail recipients to leave only the ASoC / PXA > subset ... > >> On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik >> wrote:

Re: [PATCH 14/15] ARM: pxa: change SSP devices allocation

On Tue, Apr 3, 2018 at 5:32 PM, Robert Jarzmik wrote: > Arnd Bergmann writes: > > chop chop ... removed several mail recipients to leave only the ASoC / PXA > subset ... > >> On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik >> wrote: >> >>> >>> +static struct pxa_ssp_info pxa_ssp_infos[] = { >>>

Re: call/normal switch was Re: omap4-droid4: voice call support was

Hi! > > OK thanks for checking. So probably only n_gsm channel 1 is for normal > > Qualcomm at commands, and then channel 2 and others are commands > > implemented by Motorola on the mdm6600. > > > > I guess we'd have to add support for reading and writing to > > /dev/gsmtty2 at least as it

Re: call/normal switch was Re: omap4-droid4: voice call support was

Hi! > > OK thanks for checking. So probably only n_gsm channel 1 is for normal > > Qualcomm at commands, and then channel 2 and others are commands > > implemented by Motorola on the mdm6600. > > > > I guess we'd have to add support for reading and writing to > > /dev/gsmtty2 at least as it

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

On Tue, 2018-04-03 at 15:45 +0200, Ladislav Michl wrote: > On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote: > > From: Colin Ian King > > Hello Colin, > > > Trivial fix to spelling mistake in pr_debug message text > > would you mind making this patch a bit

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

On Tue, 2018-04-03 at 15:45 +0200, Ladislav Michl wrote: > On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote: > > From: Colin Ian King > > Hello Colin, > > > Trivial fix to spelling mistake in pr_debug message text > > would you mind making this patch a bit less non-trivial and >

Re: [PATCH v3 2/4] mfd: add Gateworks System Controller core driver

On Wed, Mar 28, 2018 at 8:14 AM, Tim Harvey wrote: > The Gateworks System Controller (GSC) is an I2C slave controller > implemented with an MSP430 micro-controller whose firmware embeds the > following features: > - I/O expander (16 GPIO's) using PCA955x protocol > - Real

Re: [PATCH v3 2/4] mfd: add Gateworks System Controller core driver

On Wed, Mar 28, 2018 at 8:14 AM, Tim Harvey wrote: > The Gateworks System Controller (GSC) is an I2C slave controller > implemented with an MSP430 micro-controller whose firmware embeds the > following features: > - I/O expander (16 GPIO's) using PCA955x protocol > - Real Time Clock using

[PATCH v3 2/6] spi: sun6i: handle chip select polarity flag

The chip select polarity flag is declared as supported but is not handled in the code. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun6i.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c index

[PATCH v3 2/6] spi: sun6i: handle chip select polarity flag

The chip select polarity flag is declared as supported but is not handled in the code. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun6i.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c index 88ad45e..78acc1f 100644 ---

[PATCH v3 1/6] spi: sun6i: coding style/readability improvements

Minor changes to fulfill the coding style and improve the readability of the code. Changes in v2: 1) Fixed issue with misplacing a piece of code that requires access to the transfer structure into sun6i_spi_prepare_message() function where the transfer structure is not available. Signed-off-by:

[PATCH v3 1/6] spi: sun6i: coding style/readability improvements

Minor changes to fulfill the coding style and improve the readability of the code. Changes in v2: 1) Fixed issue with misplacing a piece of code that requires access to the transfer structure into sun6i_spi_prepare_message() function where the transfer structure is not available. Signed-off-by:

[PATCH v3 4/6] spi: sun6i: use completion provided by SPI core

As long as the completion is already provided by the SPI core then there is no need to waste extra-memory on this. Also a waiting function was added to avoid code duplication. Changes in v2: 1) Fixed issue with passing an invalid argument into devm_request_irq() function. Signed-off-by: Sergey

[PATCH v3 4/6] spi: sun6i: use completion provided by SPI core

As long as the completion is already provided by the SPI core then there is no need to waste extra-memory on this. Also a waiting function was added to avoid code duplication. Changes in v2: 1) Fixed issue with passing an invalid argument into devm_request_irq() function. Signed-off-by: Sergey

[PATCH v3 0/6] spi: Add support for DMA transfers in sun6i SPI driver

The following patchset provides corrections for PIO-mode and support for DMA transfers in sun6i SPI driver. Changes in v2: 1) Fixed issue with misplacing a piece of code that requires access to the transfer structure into sun6i_spi_prepare_message() function where the transfer structure is not

[PATCH v3 0/6] spi: Add support for DMA transfers in sun6i SPI driver

The following patchset provides corrections for PIO-mode and support for DMA transfers in sun6i SPI driver. Changes in v2: 1) Fixed issue with misplacing a piece of code that requires access to the transfer structure into sun6i_spi_prepare_message() function where the transfer structure is not

[PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode

There is no need to handle 3/4 empty interrupt as the maximum supported transfer length in PIO mode is equal to FIFO depth, i.e. 128 bytes for sun6i and 64 bytes for sun8i SoCs. Changes in v3: 1) Restored processing of 3/4 FIFO full interrupt. Signed-off-by: Sergey Suloev

[PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode

There is no need to handle 3/4 empty interrupt as the maximum supported transfer length in PIO mode is equal to FIFO depth, i.e. 128 bytes for sun6i and 64 bytes for sun8i SoCs. Changes in v3: 1) Restored processing of 3/4 FIFO full interrupt. Signed-off-by: Sergey Suloev ---

[PATCH] rapidio: use a reference count for struct mport_dma_req

Once the dma request is passed to the DMA engine, the DMA subsystem would hold a pointer to this structure and could call the completion callback after do_dma_request() has timed out. The current code deals with this by putting timed out SYNC requests to a pending list and freeing them later,

[PATCH] rapidio: use a reference count for struct mport_dma_req

Once the dma request is passed to the DMA engine, the DMA subsystem would hold a pointer to this structure and could call the completion callback after do_dma_request() has timed out. The current code deals with this by putting timed out SYNC requests to a pending list and freeing them later,

[PATCH v3 5/6] spi: sun6i: introduce register set/unset helpers

Two helper functions were added in order to set/unset specified flags in registers. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun6i.c | 37 - 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/drivers/spi/spi-sun6i.c

[PATCH v3 5/6] spi: sun6i: introduce register set/unset helpers

Two helper functions were added in order to set/unset specified flags in registers. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun6i.c | 37 - 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/drivers/spi/spi-sun6i.c

[PATCH v3 6/6] spi: sun6i: add DMA transfers support

DMA transfers are now available for sun6i and sun8i SoCs. The DMA mode is used automatically as soon as requested transfer length is more than FIFO length. Changes in v3: 1) Debug log enhancements. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun6i.c | 331

[PATCH v3 6/6] spi: sun6i: add DMA transfers support

DMA transfers are now available for sun6i and sun8i SoCs. The DMA mode is used automatically as soon as requested transfer length is more than FIFO length. Changes in v3: 1) Debug log enhancements. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun6i.c | 331

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > Initialize UEFI secure boot state during dom0 boot. Otherwise the > kernel > may not even know that it runs on secure boot enabled platform. > > Signed-off-by: Daniel Kiper > --- >  arch/x86/xen/efi.c   

Re: [PATCH v2] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot

On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote: > Initialize UEFI secure boot state during dom0 boot. Otherwise the > kernel > may not even know that it runs on secure boot enabled platform. > > Signed-off-by: Daniel Kiper > --- >  arch/x86/xen/efi.c|   57 >

Re: [PATCH v2 11/17] kvm: arm64: Configure VTCR per VM

On 03/04/18 15:58, James Morse wrote: Hi Suzuki, On 27/03/18 14:15, Suzuki K Poulose wrote: We set VTCR_EL2 very early during the stage2 init and don't touch it ever. This is fine as we had a fixed IPA size. This patch changes the behavior to set the VTCR for a given VM, depending on its

Re: [PATCH v2 11/17] kvm: arm64: Configure VTCR per VM

On 03/04/18 15:58, James Morse wrote: Hi Suzuki, On 27/03/18 14:15, Suzuki K Poulose wrote: We set VTCR_EL2 very early during the stage2 init and don't touch it ever. This is fine as we had a fixed IPA size. This patch changes the behavior to set the VTCR for a given VM, depending on its

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

On 04/03/2018 11:19 AM, Cornelia Huck wrote: On Tue, 3 Apr 2018 11:12:45 -0400 Tony Krowiak wrote: On 04/03/2018 07:17 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:49 -0400 Tony Krowiak wrote: Provides the sysfs interfaces

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

On 04/03/2018 11:19 AM, Cornelia Huck wrote: On Tue, 3 Apr 2018 11:12:45 -0400 Tony Krowiak wrote: On 04/03/2018 07:17 AM, Cornelia Huck wrote: On Wed, 14 Mar 2018 14:25:49 -0400 Tony Krowiak wrote: Provides the sysfs interfaces for assigning AP domains to and unassigning AP domains

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: > > > >> "bpf: Restrict kernel image access functions when the kernel is locked > >> down": > >> This patch just sucks in general. > > > > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since > > it gives you

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: > > > >> "bpf: Restrict kernel image access functions when the kernel is locked > >> down": > >> This patch just sucks in general. > > > > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since > > it gives you

Re: [PATCH 02/15] ARM: pxa: add dma slave map

On Tue, Apr 3, 2018 at 5:18 PM, Robert Jarzmik wrote: > Arnd Bergmann writes: > >>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >>> + { "smc91x.0", "data",

Re: [PATCH 02/15] ARM: pxa: add dma slave map

On Tue, Apr 3, 2018 at 5:18 PM, Robert Jarzmik wrote: > Arnd Bergmann writes: > >>> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >>> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >>> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, >> >> This one is

Re: [PATCH v2 5/6] i2c: i2c-stm32f7: Add DMA support

> +#define STM32F7_I2C_DMA_LEN_MIN 0x1 ... > + if (i2c_dev->dma && f7_msg->count >= STM32F7_I2C_DMA_LEN_MIN) { Are you using DMA for every message with a length >= 1? The setup of that might be more expensive than the DMA gain, if so. signature.asc Description: PGP

Re: [PATCH v2 5/6] i2c: i2c-stm32f7: Add DMA support

> +#define STM32F7_I2C_DMA_LEN_MIN 0x1 ... > + if (i2c_dev->dma && f7_msg->count >= STM32F7_I2C_DMA_LEN_MIN) { Are you using DMA for every message with a length >= 1? The setup of that might be more expensive than the DMA gain, if so. signature.asc Description: PGP

[PATCH v2 0/2] iio: add unit converter

Hi! This driver implements support for voltage dividers and current sense circuits. It's pretty generic and should be easily adaptable to other linear scaling purposes... The driver is still named "unit converter", because it was not clear to me that there was a real problem with the driver

[PATCH v2 0/2] iio: add unit converter

Hi! This driver implements support for voltage dividers and current sense circuits. It's pretty generic and should be easily adaptable to other linear scaling purposes... The driver is still named "unit converter", because it was not clear to me that there was a real problem with the driver

[PATCH v2 1/2] dt-bindings: iio: afe: add current-sense-cuicuit and voltage-divider

An ADC is often used to measure other quantities indirectly. These bindings describe two cases, a current through a sense resistor, and a "big" voltage measured with the help of a voltage divider. Signed-off-by: Peter Rosin --- .../bindings/iio/afe/current-sense-circuit.txt

[PATCH v2 2/2] iio: afe: unit-converter: new driver

If an ADC channel measures the midpoint of a voltage divider, the interesting voltage is often the voltage over the full resistance. E.g. if the full voltage is too big for the ADC to handle. Likewise, if an ADC channel measures the voltage across a resistor, the interesting value is often the

[PATCH v2 1/2] dt-bindings: iio: afe: add current-sense-cuicuit and voltage-divider

An ADC is often used to measure other quantities indirectly. These bindings describe two cases, a current through a sense resistor, and a "big" voltage measured with the help of a voltage divider. Signed-off-by: Peter Rosin --- .../bindings/iio/afe/current-sense-circuit.txt | 45

[PATCH v2 2/2] iio: afe: unit-converter: new driver

If an ADC channel measures the midpoint of a voltage divider, the interesting voltage is often the voltage over the full resistance. E.g. if the full voltage is too big for the ADC to handle. Likewise, if an ADC channel measures the voltage across a resistor, the interesting value is often the

Re: [PATCH 14/15] ARM: pxa: change SSP devices allocation

Arnd Bergmann writes: chop chop ... removed several mail recipients to leave only the ASoC / PXA subset ... > On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik wrote: > >> >> +static struct pxa_ssp_info pxa_ssp_infos[] = { >> + { .dma_chan_rx_name =

Re: [PATCH 14/15] ARM: pxa: change SSP devices allocation

Arnd Bergmann writes: chop chop ... removed several mail recipients to leave only the ASoC / PXA subset ... > On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik wrote: > >> >> +static struct pxa_ssp_info pxa_ssp_infos[] = { >> + { .dma_chan_rx_name = "ssp1_rx", .dma_chan_tx_name = "ssp1_tx",

[GIT] Sparc

1) Add support for ADI (Application Data Integrity) found in more recent sparc64 cpus. Essentially this is keyed based access to virtual memory, and if the key encoded in the virual address is wrong you get a trap. The mm changes were reviewed by Andrew Morton and others. Work by

[GIT] Sparc

1) Add support for ADI (Application Data Integrity) found in more recent sparc64 cpus. Essentially this is keyed based access to virtual memory, and if the key encoded in the virual address is wrong you get a trap. The mm changes were reviewed by Andrew Morton and others. Work by

Re: [PATCH v2 3/6] i2c: i2c-stm32f7: Add initial SMBus protocols support

> >> All SMBus protocols are implemented except SMBus-specific protocols. > > > > What does that mean? > > It miss SMBus Host Notification and SMBBus Alert. They are almost ready but > I'm > struggling to put them back to operational state after recent changes related > to > SMBust Host

Re: [PATCH v2 3/6] i2c: i2c-stm32f7: Add initial SMBus protocols support

> >> All SMBus protocols are implemented except SMBus-specific protocols. > > > > What does that mean? > > It miss SMBus Host Notification and SMBBus Alert. They are almost ready but > I'm > struggling to put them back to operational state after recent changes related > to > SMBust Host

[PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

As long as sun4i/sun6i SPI drivers have overriden the default "wait for completion" procedure then we need to properly handle -ETIMEDOUT error from transfer_one(). Signed-off-by: Sergey Suloev --- drivers/spi/spi.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[PATCH v2 1/6] spi: core: handle timeout error from transfer_one()

As long as sun4i/sun6i SPI drivers have overriden the default "wait for completion" procedure then we need to properly handle -ETIMEDOUT error from transfer_one(). Signed-off-by: Sergey Suloev --- drivers/spi/spi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH v2 3/6] spi: sun4i: coding style/readability improvements

Minor changes to fulfill the coding style and improve the readability. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/spi/spi-sun4i.c

[PATCH v2 3/6] spi: sun4i: coding style/readability improvements

Minor changes to fulfill the coding style and improve the readability. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 32 +--- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c index

[PATCH v2 4/6] spi: sun4i: use completion provided by SPI core driver

As long as the completion already provided by the SPI core then there is no need to waste extra-memory on this. Also a waiting function was added to avoid code duplication. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 62

[PATCH v2 4/6] spi: sun4i: use completion provided by SPI core driver

As long as the completion already provided by the SPI core then there is no need to waste extra-memory on this. Also a waiting function was added to avoid code duplication. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 62 - 1 file

[PATCH v2 5/6] spi: sun4i: introduce register set/unset helpers

Two helper functions were added in order to set/unset specified flags in registers. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 40 +++- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git

[PATCH v2 5/6] spi: sun4i: introduce register set/unset helpers

Two helper functions were added in order to set/unset specified flags in registers. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 40 +++- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/drivers/spi/spi-sun4i.c

[PATCH v2 6/6] spi: sun4i: add DMA transfers support

DMA transfers are now available for sun4i-family SoCs. The DMA mode is used automatically as soon as requested transfer length is more than FIFO length. Changes in v2: 1) Debug log enhancements. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 299

[PATCH v2 6/6] spi: sun4i: add DMA transfers support

DMA transfers are now available for sun4i-family SoCs. The DMA mode is used automatically as soon as requested transfer length is more than FIFO length. Changes in v2: 1) Debug log enhancements. Signed-off-by: Sergey Suloev --- drivers/spi/spi-sun4i.c | 299

[PATCH v2 0/6] spi: Add support for DMA transfers in sun4i SPI driver

The following patchset provides corrections for PIO-mode and support for DMA transfers in sun4i SPI driver. Changes in v2: 1) Restored processing of 3/4 FIFO full interrupt. 2) Debug log enhancements. Sergey Suloev (6): spi: core: handle timeout error from transfer_one() spi: sun4i:

[PATCH v2 2/6] spi: sun4i: restrict transfer length in PIO-mode

There is no need to handle the 3/4 FIFO empty interrupt as the maximum supported transfer length in PIO mode is 64 bytes. As long as a problem was reported previously with filling FIFO on A10s we want to stick with 63 bytes depth. Changes in v2: 1) Restored processing of 3/4 FIFO full interrupt.

[PATCH v2 0/6] spi: Add support for DMA transfers in sun4i SPI driver

The following patchset provides corrections for PIO-mode and support for DMA transfers in sun4i SPI driver. Changes in v2: 1) Restored processing of 3/4 FIFO full interrupt. 2) Debug log enhancements. Sergey Suloev (6): spi: core: handle timeout error from transfer_one() spi: sun4i:

[PATCH v2 2/6] spi: sun4i: restrict transfer length in PIO-mode

There is no need to handle the 3/4 FIFO empty interrupt as the maximum supported transfer length in PIO mode is 64 bytes. As long as a problem was reported previously with filling FIFO on A10s we want to stick with 63 bytes depth. Changes in v2: 1) Restored processing of 3/4 FIFO full interrupt.

Re: [PATCH v2 2/6] i2c: i2c-stm32f7: Add slave support

On Mon, Mar 26, 2018 at 10:41:51AM +0200, Pierre Yves MORDRET wrote: > > > On 03/25/2018 08:16 PM, Wolfram Sang wrote: > > On Wed, Mar 21, 2018 at 05:48:56PM +0100, Pierre-Yves MORDRET wrote: > >> This patch adds slave support for I2C controller embedded in STM32F7 SoC > >> > >> Signed-off-by:

Re: [PATCH v2 2/6] i2c: i2c-stm32f7: Add slave support

On Mon, Mar 26, 2018 at 10:41:51AM +0200, Pierre Yves MORDRET wrote: > > > On 03/25/2018 08:16 PM, Wolfram Sang wrote: > > On Wed, Mar 21, 2018 at 05:48:56PM +0100, Pierre-Yves MORDRET wrote: > >> This patch adds slave support for I2C controller embedded in STM32F7 SoC > >> > >> Signed-off-by:

Re: [GIT PULL] siginfo fix for v4.16-rc5

On Apr 3, 2018, at 10:27 AM, Eric W. Biederman wrote: > Geert Uytterhoeven writes: > >> On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman >> wrote: >> >>> A 2-byte alignment for 4 byte pointers. That is a new one to me.

Re: [GIT PULL] siginfo fix for v4.16-rc5

On Apr 3, 2018, at 10:27 AM, Eric W. Biederman wrote: > Geert Uytterhoeven writes: > >> On Mon, Apr 2, 2018 at 10:17 PM, Eric W. Biederman >> wrote: >> >>> A 2-byte alignment for 4 byte pointers. That is a new one to me. >> >> Not just for pointers, also for int and long. > > The

Re: [PATCH] locking/hung_task: Show all hung tasks before panic

On Mon, Apr 2, 2018 at 5:35 PM, Paul E. McKenney wrote: > On Mon, Apr 02, 2018 at 11:12:04PM +0900, Tetsuo Handa wrote: >> When we get a hung task it can often be valuable to see _all_ the hung >> tasks on the system before calling panic(). >> >> Quoting from >>

Re: [PATCH] locking/hung_task: Show all hung tasks before panic

On Mon, Apr 2, 2018 at 5:35 PM, Paul E. McKenney wrote: > On Mon, Apr 02, 2018 at 11:12:04PM +0900, Tetsuo Handa wrote: >> When we get a hung task it can often be valuable to see _all_ the hung >> tasks on the system before calling panic(). >> >> Quoting from >>

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

Andrea Parri wrote: > Sorry, but I don't understand your objection: are you suggesting to add > something like "Always return 0 on !SMP" to the comment? what else? Something like that, possibly along with a warning that this might not be what you want. You

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

Andrea Parri wrote: > Sorry, but I don't understand your objection: are you suggesting to add > something like "Always return 0 on !SMP" to the comment? what else? Something like that, possibly along with a warning that this might not be what you want. You might actually want it to return

Re: [PATCH v1] perf stat: enable 1ms interval for printing event counters values

On Tue, Apr 03, 2018 at 06:04:13PM +0300, Alexey Budankov wrote: > > Currently print count interval for performance counters values is > limited by 10ms so reading the values at frequencies higher than 100Hz > is restricted by the tool. > > This change makes perf stat -I possible on

Re: [PATCH v1] perf stat: enable 1ms interval for printing event counters values

On Tue, Apr 03, 2018 at 06:04:13PM +0300, Alexey Budankov wrote: > > Currently print count interval for performance counters values is > limited by 10ms so reading the values at frequencies higher than 100Hz > is restricted by the tool. > > This change makes perf stat -I possible on

Re: [PATCH 02/15] ARM: pxa: add dma slave map

Arnd Bergmann writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an

Re: [PATCH 02/15] ARM: pxa: add dma slave map

Arnd Bergmann writes: >> + { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) }, >> + { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) }, > > This one is interesting, as you are dealing with an off-chip device, > and

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

On Tue, 3 Apr 2018 11:12:45 -0400 Tony Krowiak wrote: > On 04/03/2018 07:17 AM, Cornelia Huck wrote: > > On Wed, 14 Mar 2018 14:25:49 -0400 > > Tony Krowiak wrote: > > > >> Provides the sysfs interfaces for assigning AP domains to > >>

Re: [PATCH v3 09/14] s390: vfio-ap: sysfs interfaces to configure domains

On Tue, 3 Apr 2018 11:12:45 -0400 Tony Krowiak wrote: > On 04/03/2018 07:17 AM, Cornelia Huck wrote: > > On Wed, 14 Mar 2018 14:25:49 -0400 > > Tony Krowiak wrote: > > > >> Provides the sysfs interfaces for assigning AP domains to > >> and unassigning AP domains from a mediated matrix device.

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

On Tue, Apr 03, 2018 at 09:50:19AM -0400, Alan Stern wrote: > On Mon, 2 Apr 2018, Paul E. McKenney wrote: > > > > > I will look at this more later, reaching end of both battery and useful > > > > attention span... > > > > Like the following, perhaps? > > > >

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

On Tue, Apr 03, 2018 at 09:50:19AM -0400, Alan Stern wrote: > On Mon, 2 Apr 2018, Paul E. McKenney wrote: > > > > > I will look at this more later, reaching end of both battery and useful > > > > attention span... > > > > Like the following, perhaps? > > > >

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