Re: [PATCH 07/10] perf: Directly pass PERF_AUX_* flags to perf_aux_output_end

On Fri, Feb 17, 2017 at 03:40:23PM +0200, Alexander Shishkin wrote: > Will Deacon writes: > > > @@ -485,7 +485,8 @@ int intel_bts_interrupt(void) > > return handled; > > > > perf_aux_output_end(>handle, local_xchg(>data_size, 0), > > -

Re: [PATCH 07/10] perf: Directly pass PERF_AUX_* flags to perf_aux_output_end

On Fri, Feb 17, 2017 at 03:40:23PM +0200, Alexander Shishkin wrote: > Will Deacon writes: > > > @@ -485,7 +485,8 @@ int intel_bts_interrupt(void) > > return handled; > > > > perf_aux_output_end(>handle, local_xchg(>data_size, 0), > > - !!local_xchg(>lost,

Re: [PATCH] scripts: objdiff: Ignore debug info when comparing

Hi Stephen, On Thu, Feb 16, 2017 at 01:18:20PM -0800, Stephen Boyd wrote: > If the kernel is configured to be built with debug symbols, or > has bug tables, comparing files may not work if line numbers > change. This makes comparing object files with these options > harder to do. Let's strip out

Re: [PATCH] scripts: objdiff: Ignore debug info when comparing

Hi Stephen, On Thu, Feb 16, 2017 at 01:18:20PM -0800, Stephen Boyd wrote: > If the kernel is configured to be built with debug symbols, or > has bug tables, comparing files may not work if line numbers > change. This makes comparing object files with these options > harder to do. Let's strip out

Re: [PATCH net-next v2 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address

Hello, On Fri, 17 Feb 2017 14:30:03 +0100, Gregory CLEMENT wrote: > I have just tested it and as I feared, with HWBM enabled, a simple iperf > just doesn't work. And that's expected: the whole point of HWBM is that the buffer into which a RX packet is placed is allocated by the HW, and its

Re: [PATCH net-next v2 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address

Hello, On Fri, 17 Feb 2017 14:30:03 +0100, Gregory CLEMENT wrote: > I have just tested it and as I feared, with HWBM enabled, a simple iperf > just doesn't work. And that's expected: the whole point of HWBM is that the buffer into which a RX packet is placed is allocated by the HW, and its

Re: [PATCH v2] drm/color: Document CTM eqations

What's the verdict? We've got [1] which is about to become another (driver) implementation - better to change before that merges than after I guess. -Brian [1] https://lkml.org/lkml/2017/2/13/304 On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote: Hi, On 15 February 2017 at 11:39,

Re: [PATCH v2] drm/color: Document CTM eqations

What's the verdict? We've got [1] which is about to become another (driver) implementation - better to change before that merges than after I guess. -Brian [1] https://lkml.org/lkml/2017/2/13/304 On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote: Hi, On 15 February 2017 at 11:39,

Re: [PATCH v2 4/4] pinctrl: samsung: Use devres version of gpiochip_add_data

On Fri, Feb 17, 2017 at 03:35:04PM +0200, Krzysztof Kozlowski wrote: > On Thu, Feb 16, 2017 at 01:27:16PM +, Charles Keepax wrote: > > Use devm_gpiochip_add_data to simplify the error path in > > samsung_gpiolib_register. Additionally this would also fix a leak if > > the pinctrl driver was

Re: [PATCH v2 4/4] pinctrl: samsung: Use devres version of gpiochip_add_data

On Fri, Feb 17, 2017 at 03:35:04PM +0200, Krzysztof Kozlowski wrote: > On Thu, Feb 16, 2017 at 01:27:16PM +, Charles Keepax wrote: > > Use devm_gpiochip_add_data to simplify the error path in > > samsung_gpiolib_register. Additionally this would also fix a leak if > > the pinctrl driver was

Re: [PATCH 07/10] perf: Directly pass PERF_AUX_* flags to perf_aux_output_end

Will Deacon writes: > @@ -485,7 +485,8 @@ int intel_bts_interrupt(void) > return handled; > > perf_aux_output_end(>handle, local_xchg(>data_size, 0), > - !!local_xchg(>lost, 0)); > + local_xchg(>lost, 0) ?

Re: [PATCH 07/10] perf: Directly pass PERF_AUX_* flags to perf_aux_output_end

Will Deacon writes: > @@ -485,7 +485,8 @@ int intel_bts_interrupt(void) > return handled; > > perf_aux_output_end(>handle, local_xchg(>data_size, 0), > - !!local_xchg(>lost, 0)); > + local_xchg(>lost, 0) ? > +

Re: [PATCH] building libtraceevent with clang

Em Thu, Feb 16, 2017 at 09:00:23PM -0500, Steven Rostedt escreveu: > On Mon, 13 Feb 2017 14:20:20 -0300 > Arnaldo Carvalho de Melo wrote: > > +++ b/tools/lib/traceevent/plugin_function.c > > @@ -130,7 +130,7 @@ static int function_handler(struct trace_seq *s, struct > >

Re: [PATCH] building libtraceevent with clang

Em Thu, Feb 16, 2017 at 09:00:23PM -0500, Steven Rostedt escreveu: > On Mon, 13 Feb 2017 14:20:20 -0300 > Arnaldo Carvalho de Melo wrote: > > +++ b/tools/lib/traceevent/plugin_function.c > > @@ -130,7 +130,7 @@ static int function_handler(struct trace_seq *s, struct > > pevent_record *record, >

Re: [PATCH] pata: remove the at91 driver

On Fri, 17 Feb 2017 13:36:08 +0100 Bartlomiej Zolnierkiewicz wrote: > Hi, > > On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote: > > This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove > > at91sam9261/at91sam9g10 legacy board support").

Re: [PATCH] pata: remove the at91 driver

On Fri, 17 Feb 2017 13:36:08 +0100 Bartlomiej Zolnierkiewicz wrote: > Hi, > > On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote: > > This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove > > at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared > >

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

On Tue, 7 Feb 2017, Stephane Eranian wrote: > > I think the design must ensure that the following usage models can be > monitored: >- the allocations in your CAT partitions >- the allocations from a task (inclusive of children tasks) >- the allocations from a group of tasks

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

On Tue, 7 Feb 2017, Stephane Eranian wrote: > > I think the design must ensure that the following usage models can be > monitored: >- the allocations in your CAT partitions >- the allocations from a task (inclusive of children tasks) >- the allocations from a group of tasks

Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to ENTRY/ENDPROC

On 02/17/2017, 02:16 PM, Josh Poimboeuf wrote: > On Fri, Feb 17, 2017 at 11:47:57AM +0100, Jiri Slaby wrote: >> This is just a preview, not to merged now, only later with DWARF >> unwinder series. This is what the series will serve for (aside from >> cleanup and unification). >> >> I am aware of

Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to ENTRY/ENDPROC

On 02/17/2017, 02:16 PM, Josh Poimboeuf wrote: > On Fri, Feb 17, 2017 at 11:47:57AM +0100, Jiri Slaby wrote: >> This is just a preview, not to merged now, only later with DWARF >> unwinder series. This is what the series will serve for (aside from >> cleanup and unification). >> >> I am aware of

Re: [PATCH net-next v2 1/2] net: mvneta: avoid getting status from rx_desc as much as possible

Hi Jisheng, On ven., févr. 17 2017, Jisheng Zhang wrote: > In hot code path mvneta_rx_hwbm(), the rx_desc->status is read twice. > The rx_desc is allocated by dma_alloc_coherent, it's uncacheable if > the device isn't cache-coherent, reading from uncached memory is >

Re: [PATCH net-next v2 1/2] net: mvneta: avoid getting status from rx_desc as much as possible

Hi Jisheng, On ven., févr. 17 2017, Jisheng Zhang wrote: > In hot code path mvneta_rx_hwbm(), the rx_desc->status is read twice. > The rx_desc is allocated by dma_alloc_coherent, it's uncacheable if > the device isn't cache-coherent, reading from uncached memory is > fairly slow. So reuse the

Re: [PATCH 4/4] ARM: davinci: add pdata-quirks for da850-evm vpif display

2017-02-17 14:15 GMT+01:00 Sekhar Nori : > On Thursday 16 February 2017 11:51 PM, Bartosz Golaszewski wrote: >> Similarly to vpif capture: we need to register the vpif display driver >> and the corresponding adv7343 encoder in pdata-quirks as the DT >> support is not complete -

Re: [PATCH 4/4] ARM: davinci: add pdata-quirks for da850-evm vpif display

2017-02-17 14:15 GMT+01:00 Sekhar Nori : > On Thursday 16 February 2017 11:51 PM, Bartosz Golaszewski wrote: >> Similarly to vpif capture: we need to register the vpif display driver >> and the corresponding adv7343 encoder in pdata-quirks as the DT >> support is not complete - there isn't

Re: [PATCH v2 4/4] pinctrl: samsung: Use devres version of gpiochip_add_data

On Thu, Feb 16, 2017 at 01:27:16PM +, Charles Keepax wrote: > Use devm_gpiochip_add_data to simplify the error path in > samsung_gpiolib_register. Additionally this would also fix a leak if > the pinctrl driver was unbound, although admittedly I can't see any > good use-case for doing so, but

Re: [PATCH v2 4/4] pinctrl: samsung: Use devres version of gpiochip_add_data

On Thu, Feb 16, 2017 at 01:27:16PM +, Charles Keepax wrote: > Use devm_gpiochip_add_data to simplify the error path in > samsung_gpiolib_register. Additionally this would also fix a leak if > the pinctrl driver was unbound, although admittedly I can't see any > good use-case for doing so, but

Re: [PATCH] tools lib traceevent: It's preempt not prempt

Em Thu, Feb 16, 2017 at 08:13:52PM -0500, Steven Rostedt (VMware) escreveu: > Fix the typo of the function name pevent_data_prempt_count() Thanks, applied and added: Fixes: c52d9e4e677b ("tools lib traceevent: Add retrieval of preempt count and latency flags") - Arnaldo > Signed-off-by:

Re: [PATCH] tools lib traceevent: It's preempt not prempt

Em Thu, Feb 16, 2017 at 08:13:52PM -0500, Steven Rostedt (VMware) escreveu: > Fix the typo of the function name pevent_data_prempt_count() Thanks, applied and added: Fixes: c52d9e4e677b ("tools lib traceevent: Add retrieval of preempt count and latency flags") - Arnaldo > Signed-off-by:

Re: [PATCH V3 0/4] Define coherent device memory node

On Fri, Feb 17, 2017 at 05:11:57PM +0530, Anshuman Khandual wrote: > On 02/15/2017 11:50 PM, Mel Gorman wrote: > > On Wed, Feb 15, 2017 at 05:37:22PM +0530, Anshuman Khandual wrote: > >>This four patches define CDM node with HugeTLB & Buddy allocation > >> isolation. Please refer to the last

Re: [PATCH V3 0/4] Define coherent device memory node

On Fri, Feb 17, 2017 at 05:11:57PM +0530, Anshuman Khandual wrote: > On 02/15/2017 11:50 PM, Mel Gorman wrote: > > On Wed, Feb 15, 2017 at 05:37:22PM +0530, Anshuman Khandual wrote: > >>This four patches define CDM node with HugeTLB & Buddy allocation > >> isolation. Please refer to the last

Re: [PATCH 3/4] fpga dt: bindings for Altera Partial Reconfiguraion IP.

On Wed, Feb 15, 2017 at 3:10 PM, wrote: > From: Matthew Gerlach > > Device Tree bindings for Altera Partial Reconfiguraion IP? > > Signed-off-by: Matthew Gerlach > --- >

Re: [PATCH 3/4] fpga dt: bindings for Altera Partial Reconfiguraion IP.

On Wed, Feb 15, 2017 at 3:10 PM, wrote: > From: Matthew Gerlach > > Device Tree bindings for Altera Partial Reconfiguraion IP? > > Signed-off-by: Matthew Gerlach > --- > Documentation/devicetree/bindings/fpga/altera-pr-ip.txt | 12 > 1 file changed, 12 insertions(+) > create

Re: [PATCH net-next v2 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address

Hi Jisheng, On ven., févr. 17 2017, Jisheng Zhang wrote: > In hot code path such as mvneta_rx_hwbm() and mvneta_rx_swbm, the > buf_phys_addr field of rx_dec is accessed. The rx_desc is allocated by > dma_alloc_coherent, it's uncacheable if the device isn't cache >

Re: [PATCH net-next v2 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address

Hi Jisheng, On ven., févr. 17 2017, Jisheng Zhang wrote: > In hot code path such as mvneta_rx_hwbm() and mvneta_rx_swbm, the > buf_phys_addr field of rx_dec is accessed. The rx_desc is allocated by > dma_alloc_coherent, it's uncacheable if the device isn't cache > coherent, reading from

Re: [Suggestion/Problems] perf annoate: Some problems related to the source code view and Improvement of it with line numbers

Em Fri, Feb 17, 2017 at 11:33:29AM +0900, Taeung Song escreveu: > Hi, Arnaldo :) > > Regarding perf annotate: > > 1) Problem : wrong line numbers on perf-annotate (both stdio and TUI) > 2) Problem : wrong sum of overhead(percent) matching source lines > 3) Suggestion : new option showing only

Re: [Suggestion/Problems] perf annoate: Some problems related to the source code view and Improvement of it with line numbers

Em Fri, Feb 17, 2017 at 11:33:29AM +0900, Taeung Song escreveu: > Hi, Arnaldo :) > > Regarding perf annotate: > > 1) Problem : wrong line numbers on perf-annotate (both stdio and TUI) > 2) Problem : wrong sum of overhead(percent) matching source lines > 3) Suggestion : new option showing only

Applied "spi: ti-qspi: revise ti_qspi_probe() failure flow" to the spi tree

The patch spi: ti-qspi: revise ti_qspi_probe() failure flow has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Applied "spi: ti-qspi: revise ti_qspi_probe() failure flow" to the spi tree

The patch spi: ti-qspi: revise ti_qspi_probe() failure flow has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On 17 February 2017 at 12:45, Tobias Jakobi wrote: > Hello Maxime, > > Maxime Ripard wrote: >> Hi, >> >> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >>> I was wondering about the following. Wasn't there some strict >>> requirement about code going

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

On 17 February 2017 at 12:45, Tobias Jakobi wrote: > Hello Maxime, > > Maxime Ripard wrote: >> Hi, >> >> On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >>> I was wondering about the following. Wasn't there some strict >>> requirement about code going upstream, which also included

[PATCH v9 1/2] Add OV5647 device tree documentation

Create device tree bindings documentation. Signed-off-by: Ramiro Oliveira Acked-by: Rob Herring --- .../devicetree/bindings/media/i2c/ov5647.txt | 35 ++ 1 file changed, 35 insertions(+) create mode 100644

[PATCH v9 2/2] Add support for OV5647 sensor.

The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 and RAW 10 output formats, and MIPI CSI-2 interface. The driver adds support for 640x480 RAW 8. Signed-off-by: Ramiro Oliveira --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig |

[PATCH v9 1/2] Add OV5647 device tree documentation

Create device tree bindings documentation. Signed-off-by: Ramiro Oliveira Acked-by: Rob Herring --- .../devicetree/bindings/media/i2c/ov5647.txt | 35 ++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt diff

[PATCH v9 2/2] Add support for OV5647 sensor.

The OV5647 sensor from Omnivision supports up to 2592x1944 @ 15 fps, RAW 8 and RAW 10 output formats, and MIPI CSI-2 interface. The driver adds support for 640x480 RAW 8. Signed-off-by: Ramiro Oliveira --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig | 11 +

[PATCH v9 0/2] Add support for Omnivision OV5647

Hello, This patchset adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in RAW 8. This is the ninth version of the OV5647 camera driver patchset. v9: - Remove unused struct - Remove comments - Refactor error handling in i2c r/w functions - Change

[PATCH v9 0/2] Add support for Omnivision OV5647

Hello, This patchset adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in RAW 8. This is the ninth version of the OV5647 camera driver patchset. v9: - Remove unused struct - Remove comments - Refactor error handling in i2c r/w functions - Change

[PATCH] PM / sleep: Fix test_suspend after sleep state rework

When passing "test_suspend=mem" to the kernel: PM: can't test 'mem' suspend state and the suspend test is not run. Commit 406e79385f3223d8 ("PM / sleep: System sleep state selection interface rework") changed pm_labels[] from a contiguous NULL-terminated array to a sparse array (with the

[PATCH] PM / sleep: Fix test_suspend after sleep state rework

When passing "test_suspend=mem" to the kernel: PM: can't test 'mem' suspend state and the suspend test is not run. Commit 406e79385f3223d8 ("PM / sleep: System sleep state selection interface rework") changed pm_labels[] from a contiguous NULL-terminated array to a sparse array (with the

Re: [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i

On Thu, Feb 16, 2017 at 08:05:24PM +0100, Maxime Ripard wrote: > Hi, > [...] > > + > > +struct emac_variant { > > + u32 default_syscon_value; > > Why do you need a default value? Can't you read it from the syscon > directly? > Why not, but you can see the default value as "value for

Re: [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i

On Thu, Feb 16, 2017 at 08:05:24PM +0100, Maxime Ripard wrote: > Hi, > [...] > > + > > +struct emac_variant { > > + u32 default_syscon_value; > > Why do you need a default value? Can't you read it from the syscon > directly? > Why not, but you can see the default value as "value for

Re: [PATCH 4/4] ARM: davinci: add pdata-quirks for da850-evm vpif display

On Thursday 16 February 2017 11:51 PM, Bartosz Golaszewski wrote: > Similarly to vpif capture: we need to register the vpif display driver > and the corresponding adv7343 encoder in pdata-quirks as the DT > support is not complete - there isn't currently a way to define the > output_routing in the

Re: [PATCH 4/4] ARM: davinci: add pdata-quirks for da850-evm vpif display

On Thursday 16 February 2017 11:51 PM, Bartosz Golaszewski wrote: > Similarly to vpif capture: we need to register the vpif display driver > and the corresponding adv7343 encoder in pdata-quirks as the DT > support is not complete - there isn't currently a way to define the > output_routing in the

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

Hi, On Friday 17 February 2017 03:20 PM, Kishon Vijay Abraham I wrote: > Add endpoint mode support to designware driver. This uses the > EP Core layer introduced recently to add endpoint mode support. > *Any* function driver can now use this designware device > in order to achieve the EP

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

Hi, On Friday 17 February 2017 03:20 PM, Kishon Vijay Abraham I wrote: > Add endpoint mode support to designware driver. This uses the > EP Core layer introduced recently to add endpoint mode support. > *Any* function driver can now use this designware device > in order to achieve the EP

Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to ENTRY/ENDPROC

On Fri, Feb 17, 2017 at 11:47:57AM +0100, Jiri Slaby wrote: > This is just a preview, not to merged now, only later with DWARF > unwinder series. This is what the series will serve for (aside from > cleanup and unification). > > I am aware of CFI_STARTPROC and CFI_ENDPROC left defined in other

Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to ENTRY/ENDPROC

On Fri, Feb 17, 2017 at 11:47:57AM +0100, Jiri Slaby wrote: > This is just a preview, not to merged now, only later with DWARF > unwinder series. This is what the series will serve for (aside from > cleanup and unification). > > I am aware of CFI_STARTPROC and CFI_ENDPROC left defined in other

Re: [PATCH] pata: remove the at91 driver

Hi, On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote: > This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove > at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared > adding DT support to it, it probably means it's no longer used and is > thus a

Re: [PATCH] pata: remove the at91 driver

Hi, On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote: > This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove > at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared > adding DT support to it, it probably means it's no longer used and is > thus a

Re: [PATCH v2 04/22] Documentation: PCI: Guide to use pci endpoint configfs

Às 9:50 AM de 2/17/2017, Kishon Vijay Abraham I escreveu: > Add Documentation to help users use pci endpoint to configure > pci endpoint function and to bind the endpoint function > with endpoint controller. > > Signed-off-by: Kishon Vijay Abraham I > --- >

Re: [PATCH v2 04/22] Documentation: PCI: Guide to use pci endpoint configfs

Às 9:50 AM de 2/17/2017, Kishon Vijay Abraham I escreveu: > Add Documentation to help users use pci endpoint to configure > pci endpoint function and to bind the endpoint function > with endpoint controller. > > Signed-off-by: Kishon Vijay Abraham I > --- > Documentation/PCI/00-INDEX

[PATCH] net: ethernet: stmmac: dwmac-rk: Add RK3328 gmac support

From: "david.wu" Add constants and callback functions for the dwmac on rk3328 socs. As can be seen, the base structure is the same, only registers and the bits in them moved slightly. Signed-off-by: david.wu ---

[PATCH] net: ethernet: stmmac: dwmac-rk: Add RK3328 gmac support

From: "david.wu" Add constants and callback functions for the dwmac on rk3328 socs. As can be seen, the base structure is the same, only registers and the bits in them moved slightly. Signed-off-by: david.wu --- .../devicetree/bindings/net/rockchip-dwmac.txt | 1 +

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote: > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote: > > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote: > > > But when I discussed this with Vincent, he suggested that it may not be > > > required > >

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote: > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote: > > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote: > > > But when I discussed this with Vincent, he suggested that it may not be > > > required > >

Re: [PATCH] tpm: Fix expected number of response bytes of TPM1.2 PCR Extend

Hi James, On Wed, 2017-02-15 at 20:09 +0200, Jarkko Sakkinen wrote: > On Wed, Feb 15, 2017 at 11:56:23AM -0500, Stefan Berger wrote: > > The TPM1.2 PCR Extend operation only returns 20 bytes in the body, > > which is the size of the PCR state. > > > > This fixes a problem where IMA gets errors

Re: [PATCH] tpm: Fix expected number of response bytes of TPM1.2 PCR Extend

Hi James, On Wed, 2017-02-15 at 20:09 +0200, Jarkko Sakkinen wrote: > On Wed, Feb 15, 2017 at 11:56:23AM -0500, Stefan Berger wrote: > > The TPM1.2 PCR Extend operation only returns 20 bytes in the body, > > which is the size of the PCR state. > > > > This fixes a problem where IMA gets errors

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >> I was wondering about the following. Wasn't there some strict >> requirement about code going upstream, which also included that there >> was a full open-source driver stack for it? >>

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

Hello Maxime, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:43:06PM +0100, Tobias Jakobi wrote: >> I was wondering about the following. Wasn't there some strict >> requirement about code going upstream, which also included that there >> was a full open-source driver stack for it? >>

[PATCH 2/2] f2fs: fix the case when there is no free segment to allocate for CURSEG_WARM_NODE

If the free segments are used up, then new_curseg will fail for CURSEG_WARM_NODE, in this case, we should use change_curseg instead of new_curseg. Signed-off-by: Yunlong Song --- fs/f2fs/segment.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/segment.c

[PATCH 2/2] f2fs: fix the case when there is no free segment to allocate for CURSEG_WARM_NODE

If the free segments are used up, then new_curseg will fail for CURSEG_WARM_NODE, in this case, we should use change_curseg instead of new_curseg. Signed-off-by: Yunlong Song --- fs/f2fs/segment.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index

[PATCH 1/2] mkfs.f2fs: add option to set the value of reserved segments and overprovision segments

Signed-off-by: Yunlong Song --- include/f2fs_fs.h | 3 +++ lib/libf2fs.c | 3 +++ mkfs/f2fs_format.c | 21 ++--- mkfs/f2fs_format_main.c | 10 +- 4 files changed, 29 insertions(+), 8 deletions(-) diff --git

[PATCH 1/2] mkfs.f2fs: add option to set the value of reserved segments and overprovision segments

Signed-off-by: Yunlong Song --- include/f2fs_fs.h | 3 +++ lib/libf2fs.c | 3 +++ mkfs/f2fs_format.c | 21 ++--- mkfs/f2fs_format_main.c | 10 +- 4 files changed, 29 insertions(+), 8 deletions(-) diff --git a/include/f2fs_fs.h b/include/f2fs_fs.h

[PATCH 0/2] Reduce the overprovision size a lot in f2fs

Rethink the meaning of reserved segments and overprovision segments in f2fs The key issue is that flash FTL has already made overprovision itself, e.g. 7%, according to the difference between gigabyte (GB) and gibibyte (GiB). And this part can nenver be seen by the upper file system. The device

[PATCH 0/2] Reduce the overprovision size a lot in f2fs

Rethink the meaning of reserved segments and overprovision segments in f2fs The key issue is that flash FTL has already made overprovision itself, e.g. 7%, according to the difference between gigabyte (GB) and gibibyte (GiB). And this part can nenver be seen by the upper file system. The device

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

On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote: > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote: > > Good morning to everyone. > > > On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote: > > > Just as an aside, has anyone given any thought

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

On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote: > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote: > > Good morning to everyone. > > > On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote: > > > Just as an aside, has anyone given any thought

Re: [PATCH v4 00/36] i.MX Media Driver

On Fri, Feb 17, 2017 at 02:22:14PM +0200, Sakari Ailus wrote: > Hi Philipp, Steve and Russell, > > On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > > I think with Russell's explanation of how the imx219 sensor operates, > > we'll have to do something before calling the sensor

Re: [PATCH v4 00/36] i.MX Media Driver

On Fri, Feb 17, 2017 at 02:22:14PM +0200, Sakari Ailus wrote: > Hi Philipp, Steve and Russell, > > On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > > I think with Russell's explanation of how the imx219 sensor operates, > > we'll have to do something before calling the sensor

Re: [PATCH 3/6] mm/migrate: Add copy_pages_mthread function

-migration/20170217-200523 config: i386-tinyconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): mm/copy_pages_mthread.c: In fu

Re: [PATCH 3/6] mm/migrate: Add copy_pages_mthread function

-migration/20170217-200523 config: i386-tinyconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): mm/copy_pages_mthread.c: In fu

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate >

Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote: > There are ~4300 uses of pr_warn and ~250 uses of the older > pr_warning in the kernel source tree. > > Make the use of pr_warn consistent across all kernel files. > > This excludes all files in tools/ as there is a separate > define pr_warning

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 02/17/2017 07:30 AM, Pan Xinhui wrote: > > > 在 2017/2/17 14:05, Michael Ellerman 写道: >> Pan Xinhui writes: >>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >>> index 9c0e17c..f6e5c3d 100644 >>> --- a/arch/powerpc/xmon/xmon.c >>> +++

Re: [PATCH] powerpc/xmon: Fix an unexpected xmon onoff state change

On 02/17/2017 07:30 AM, Pan Xinhui wrote: > > > 在 2017/2/17 14:05, Michael Ellerman 写道: >> Pan Xinhui writes: >>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c >>> index 9c0e17c..f6e5c3d 100644 >>> --- a/arch/powerpc/xmon/xmon.c >>> +++ b/arch/powerpc/xmon/xmon.c >>> @@ -76,6

Re: [PATCH v4 00/36] i.MX Media Driver

Hi Philipp, Steve and Russell, On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > On Thu, 2017-02-16 at 14:27 -0800, Steve Longerbeam wrote: > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > > On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: > >

Re: [PATCH v4 00/36] i.MX Media Driver

Hi Philipp, Steve and Russell, On Fri, Feb 17, 2017 at 12:43:38PM +0100, Philipp Zabel wrote: > On Thu, 2017-02-16 at 14:27 -0800, Steve Longerbeam wrote: > > > > On 02/16/2017 02:20 PM, Russell King - ARM Linux wrote: > > > On Wed, Feb 15, 2017 at 06:19:02PM -0800, Steve Longerbeam wrote: > >

[GIT PULL] Please pull powerpc/linux.git powerpc-4.10-5 tag

Hi Linus, Please pull one last powerpc fix for 4.10. This is actually tagged for stable, so it's not the end of the world if you'd rather not pull it this late. cheers The following changes since commit f83e6862047e1e371bdc5d512dd6cabe8a3965b8: powerpc/powernv: Properly set "host-ipi" on

[GIT PULL] Please pull powerpc/linux.git powerpc-4.10-5 tag

Hi Linus, Please pull one last powerpc fix for 4.10. This is actually tagged for stable, so it's not the end of the world if you'd rather not pull it this late. cheers The following changes since commit f83e6862047e1e371bdc5d512dd6cabe8a3965b8: powerpc/powernv: Properly set "host-ipi" on

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote: > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote: > > But when I discussed this with Vincent, he suggested that it may not be > > required > > at all as the scheduler (with the helped of "decayed") doesn't call into >

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote: > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote: > > But when I discussed this with Vincent, he suggested that it may not be > > required > > at all as the scheduler (with the helped of "decayed") doesn't call into >

[PATCH] initramfs: Provide a way to ignore image provided by bootloader

Many "embedded" architectures provide CMDLINE_FORCE to allow the kernel to override the command line provided by an inflexible bootloader. However there is currrently no way for the kernel to override the initramfs image provided by the bootloader meaning there are still ways for bootloaders to

[PATCH] initramfs: Provide a way to ignore image provided by bootloader

Many "embedded" architectures provide CMDLINE_FORCE to allow the kernel to override the command line provided by an inflexible bootloader. However there is currrently no way for the kernel to override the initramfs image provided by the bootloader meaning there are still ways for bootloaders to

Re: [PATCH 04/21] ARM: sun8i: dt: Add DT bindings documentation for Allwinner dwmac-sun8i

On Thu, Feb 16, 2017 at 07:48:18PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:48:42PM +0100, Corentin Labbe wrote: > > This patch adds documentation for Device-Tree bindings for the > > Allwinner dwmac-sun8i driver. > > > > Signed-off-by: Corentin Labbe

Re: [PATCH 04/21] ARM: sun8i: dt: Add DT bindings documentation for Allwinner dwmac-sun8i

On Thu, Feb 16, 2017 at 07:48:18PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Feb 16, 2017 at 01:48:42PM +0100, Corentin Labbe wrote: > > This patch adds documentation for Device-Tree bindings for the > > Allwinner dwmac-sun8i driver. > > > > Signed-off-by: Corentin Labbe > > --- > >

[PATCH v2 1/2] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

If we crossed a sample window while in NO_HZ we will add LOAD_FREQ to the pending sample window time on exit, setting the next update not one window into the future, but two. This situation on exiting NO_HZ is described by: this_rq->calc_load_update < jiffies < calc_load_update In this

[PATCH v2 1/2] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

If we crossed a sample window while in NO_HZ we will add LOAD_FREQ to the pending sample window time on exit, setting the next update not one window into the future, but two. This situation on exiting NO_HZ is described by: this_rq->calc_load_update < jiffies < calc_load_update In this

[PATCH v2 2/2] sched/loadavg: Use {READ,WRITE}_ONCE() for sample window

'calc_load_update' is accessed without any kind of locking and there's a clear assumption in the code that only a single value is read or written. Make this explicit by using READ_ONCE() and WRITE_ONCE(), and avoid unintentionally seeing multiple values, or having the load/stores split.

[PATCH v2 0/2] sched/loadavg: Fix loadavg spikes and sprinkle {READ,WRITE}_ONCE()

Peter, Frederic, Here's a v2 of the patch series to fix the loadavg spikes I'm seeing on a v3.12 based kernel, caused by delaying load sampling if a sample period was crossed while in NO_HZ idle. I tried to make the changelog for PATCH 1 clearer this time around by incorporating suggestions

[PATCH v2 2/2] sched/loadavg: Use {READ,WRITE}_ONCE() for sample window

'calc_load_update' is accessed without any kind of locking and there's a clear assumption in the code that only a single value is read or written. Make this explicit by using READ_ONCE() and WRITE_ONCE(), and avoid unintentionally seeing multiple values, or having the load/stores split.

[PATCH v2 0/2] sched/loadavg: Fix loadavg spikes and sprinkle {READ,WRITE}_ONCE()

Peter, Frederic, Here's a v2 of the patch series to fix the loadavg spikes I'm seeing on a v3.12 based kernel, caused by delaying load sampling if a sample period was crossed while in NO_HZ idle. I tried to make the changelog for PATCH 1 clearer this time around by incorporating suggestions

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