Re: [PATCH] Documentation: clock: address more for clock-cells property

On 06/01, Chunyan Zhang wrote: > The value of property 'clock-cells' is not determined only by the number of > clock outputs in one clock node, it is actually determined by whether the > clock output in this node can be referenced directly without index. If > the output clock has to be referenced

Re: [PATCH] Documentation: clock: address more for clock-cells property

On 06/01, Chunyan Zhang wrote: > The value of property 'clock-cells' is not determined only by the number of > clock outputs in one clock node, it is actually determined by whether the > clock output in this node can be referenced directly without index. If > the output clock has to be referenced

Re: [PATCH v3 3/5] clk: qcom: ipq8074: Add Global Clock Controller support

On 06/01, Varadarajan Narayanan wrote: > From: Abhishek Sahu > > This patch adds support for the global clock controller found on > the IPQ8074 based devices. This includes UART, I2C, SPI etc. > > Signed-off-by: Abhishek Sahu > Signed-off-by:

Re: [PATCH v3 3/5] clk: qcom: ipq8074: Add Global Clock Controller support

On 06/01, Varadarajan Narayanan wrote: > From: Abhishek Sahu > > This patch adds support for the global clock controller found on > the IPQ8074 based devices. This includes UART, I2C, SPI etc. > > Signed-off-by: Abhishek Sahu > Signed-off-by: Varadarajan Narayanan > --- >

[GIT PULL] ACPI fixes for v4.12-rc4

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.12-rc4 with top-most commit 60319130254084b337e02439d3b4ec301b6328bb Merge branches 'acpi-button', 'acpica' and 'acpi-sysfs' on top of commit

[GIT PULL] ACPI fixes for v4.12-rc4

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.12-rc4 with top-most commit 60319130254084b337e02439d3b4ec301b6328bb Merge branches 'acpi-button', 'acpica' and 'acpi-sysfs' on top of commit

Re: [PATCH v4 2/2] clk: bcm2835: Minimise clock jitter for PCM clock

On 06/01, Phil Elwell wrote: > Fractional clock dividers generate accurate average frequencies but > with jitter, particularly when the integer divisor is small. > > Introduce a new metric of clock accuracy to penalise clocks with a good > average but worse jitter compared to clocks with an

Re: hexagon: Use raw_copy_to_user

Hi Richard, On Fri, Jun 02, 2017 at 04:33:04PM -0500, Richard Kuo wrote: > On Fri, Jun 02, 2017 at 06:03:53AM -0700, Guenter Roeck wrote: > > ping > > > > On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote: > > > Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced >

Re: [PATCH v4 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER

On 06/01, Phil Elwell wrote: > Restrict clock sources for the PCM peripheral to the oscillator and > PLLD_PER because other source may have varying rates or be switched off. > Prevent other sources from being selected by replacing their names in > the list of potential parents with dummy entries

Re: [PATCH v4 2/2] clk: bcm2835: Minimise clock jitter for PCM clock

On 06/01, Phil Elwell wrote: > Fractional clock dividers generate accurate average frequencies but > with jitter, particularly when the integer divisor is small. > > Introduce a new metric of clock accuracy to penalise clocks with a good > average but worse jitter compared to clocks with an

Re: hexagon: Use raw_copy_to_user

Hi Richard, On Fri, Jun 02, 2017 at 04:33:04PM -0500, Richard Kuo wrote: > On Fri, Jun 02, 2017 at 06:03:53AM -0700, Guenter Roeck wrote: > > ping > > > > On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote: > > > Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced >

Re: [PATCH v4 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER

On 06/01, Phil Elwell wrote: > Restrict clock sources for the PCM peripheral to the oscillator and > PLLD_PER because other source may have varying rates or be switched off. > Prevent other sources from being selected by replacing their names in > the list of potential parents with dummy entries

[PATCH] Staging: ccree: ssi_aead.h: Fixed a pointer declaration error.

Fixed a pointer declaration error , the dereferencing operator was misplaced. Signed-off-by: srishti sharma --- drivers/staging/ccree/ssi_aead.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ccree/ssi_aead.h

[PATCH] Staging: ccree: ssi_aead.h: Fixed a pointer declaration error.

Fixed a pointer declaration error , the dereferencing operator was misplaced. Signed-off-by: srishti sharma --- drivers/staging/ccree/ssi_aead.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ccree/ssi_aead.h b/drivers/staging/ccree/ssi_aead.h index

Re: [PATCH] clk: Re-evaluate clock rate on min/max update

On 06/02, Peter De Schrijver wrote: > On Thu, Jun 01, 2017 at 02:12:51AM -0700, Stephen Boyd wrote: > > On 04/13, Peter De Schrijver wrote: > > > On Wed, Apr 12, 2017 at 09:46:05AM -0700, Stephen Boyd wrote: > > > > On 03/21, Peter De Schrijver wrote: > > > > > > No. But I do rely on the rate

Re: [PATCH] clk: Re-evaluate clock rate on min/max update

On 06/02, Peter De Schrijver wrote: > On Thu, Jun 01, 2017 at 02:12:51AM -0700, Stephen Boyd wrote: > > On 04/13, Peter De Schrijver wrote: > > > On Wed, Apr 12, 2017 at 09:46:05AM -0700, Stephen Boyd wrote: > > > > On 03/21, Peter De Schrijver wrote: > > > > > > No. But I do rely on the rate

[GIT PULL] Power management fixes for v4.12-rc4

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.12-rc4 with top-most commit bb5710e72c217e5bbdf0969a2fd84f5f5ad7fc2b Merge branch 'pm-cpufreq' on top of commit 5ed02dbb497422bf225783f46e6eadd237d23d6b Linux 4.12-rc3 to receive

[GIT PULL] Power management fixes for v4.12-rc4

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.12-rc4 with top-most commit bb5710e72c217e5bbdf0969a2fd84f5f5ad7fc2b Merge branch 'pm-cpufreq' on top of commit 5ed02dbb497422bf225783f46e6eadd237d23d6b Linux 4.12-rc3 to receive

Re: [PATCH] clk: bcm2835: Correct the prediv logic

On 05/15, Eric Anholt wrote: > From: Phil Elwell > > If a clock has the prediv flag set, both the integer and fractional > parts must be scaled when calculating the resulting frequency. > > Signed-off-by: Phil Elwell > Signed-off-by: Eric Anholt

Re: [PATCH] clk: bcm2835: Correct the prediv logic

On 05/15, Eric Anholt wrote: > From: Phil Elwell > > If a clock has the prediv flag set, both the integer and fractional > parts must be scaled when calculating the resulting frequency. > > Signed-off-by: Phil Elwell > Signed-off-by: Eric Anholt > --- Applied to clk-next -- Qualcomm

Re: [PATCH V3 2/3] clk: add managed version of clk_bulk_get

On 05/19, Dong Aisheng wrote: > This patch introduces the managed version of clk_bulk_get. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Russell King > Cc: Geert Uytterhoeven > Cc: "Rafael J.

Re: [PATCH V3 0/3] clk: introduce clk_bulk_get accessories

On 05/19, Dong Aisheng wrote: > These helper function allows drivers to get several clk consumers in > one operation. If any of the clk cannot be acquired then any clks > that were got will be put before returning to the caller. > I've merged the first two into a stable branch and merged to

Re: [PATCH V3 2/3] clk: add managed version of clk_bulk_get

On 05/19, Dong Aisheng wrote: > This patch introduces the managed version of clk_bulk_get. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Russell King > Cc: Geert Uytterhoeven > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: Mark Brown > Cc: Shawn Guo > Cc: Fabio Estevam > Cc:

Re: [PATCH V3 0/3] clk: introduce clk_bulk_get accessories

On 05/19, Dong Aisheng wrote: > These helper function allows drivers to get several clk consumers in > one operation. If any of the clk cannot be acquired then any clks > that were got will be put before returning to the caller. > I've merged the first two into a stable branch and merged to

Re: [PATCH] clk: meson-gxbb: Add const to some parent name arrays

On 06/02, Stephen Boyd wrote: > These can be marked as const * const. > > Cc: Neil Armstrong > Cc: Jerome Brunet > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of

Re: [PATCH] clk: meson-gxbb: Add const to some parent name arrays

On 06/02, Stephen Boyd wrote: > These can be marked as const * const. > > Cc: Neil Armstrong > Cc: Jerome Brunet > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH V3 1/3] clk: add clk_bulk_get accessories

On 05/19, Dong Aisheng wrote: > These helper function allows drivers to get several clk consumers in > one operation. If any of the clk cannot be acquired then any clks > that were got will be put before returning to the caller. > > This can relieve the driver owners' life who needs to handle

Re: [PATCH V3 1/3] clk: add clk_bulk_get accessories

On 05/19, Dong Aisheng wrote: > These helper function allows drivers to get several clk consumers in > one operation. If any of the clk cannot be acquired then any clks > that were got will be put before returning to the caller. > > This can relieve the driver owners' life who needs to handle

[PATCH] drivers: char: mem: Fix wraparound check to allow mappings up to the end

A recent fix to /dev/mem prevents mappings from wrapping around the end of physical address space. However, the check was written in a way that also prevents a mapping reaching just up to the end of physical address space, which may be a valid use case (especially on 32-bit systems). This patch

[PATCH] drivers: char: mem: Fix wraparound check to allow mappings up to the end

A recent fix to /dev/mem prevents mappings from wrapping around the end of physical address space. However, the check was written in a way that also prevents a mapping reaching just up to the end of physical address space, which may be a valid use case (especially on 32-bit systems). This patch

Re: CLK_OF_DECLARE advice required

On 06/01, Phil Elwell wrote: > On 01/06/2017 07:39, Stephen Boyd wrote: > > On 05/31, Phil Elwell wrote: > >> For my edification, can you pretend for a moment that the application was > >> a valid one and > >> answer any of my original questions?: > >> > >> 1. Should all system clock drivers use

Re: CLK_OF_DECLARE advice required

On 06/01, Phil Elwell wrote: > On 01/06/2017 07:39, Stephen Boyd wrote: > > On 05/31, Phil Elwell wrote: > >> For my edification, can you pretend for a moment that the application was > >> a valid one and > >> answer any of my original questions?: > >> > >> 1. Should all system clock drivers use

[PATCH v2] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain

An earlier change to this function (3bdae810721b) fixed a leak in the case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the glom_skb buffer, used for emulating a scattering read, is never used or referenced after its contents are copied into the destination buffers, and therefore

[PATCH v2] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain

An earlier change to this function (3bdae810721b) fixed a leak in the case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the glom_skb buffer, used for emulating a scattering read, is never used or referenced after its contents are copied into the destination buffers, and therefore

[PATCH] clk: sunxi-ng: Move all clock types to a library

e> Signed-off-by: Stephen Boyd <sb...@codeaurora.org> --- Based on linux-next-20170602. drivers/clk/sunxi-ng/Kconfig | 117 -- drivers/clk/sunxi-ng/Makefile | 26 +- 2 files changed, 13 insertions(+), 130 deletions(-) diff --git a/drivers/

[PATCH] clk: sunxi-ng: Move all clock types to a library

ephen Boyd --- Based on linux-next-20170602. drivers/clk/sunxi-ng/Kconfig | 117 -- drivers/clk/sunxi-ng/Makefile | 26 +- 2 files changed, 13 insertions(+), 130 deletions(-) diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kco

[PATCH V4 2/2] sched/fair: Remove group imbalance from calculate_imbalance()

The group_imbalance path in calculate_imbalance() made sense when it was added back in 2007 with commit 908a7c1b9b80 ("sched: fix improper load balance across sched domain") because busiest->load_per_task factored into the amount of imbalance that was calculated. That is not the case today. The

[PATCH V4 2/2] sched/fair: Remove group imbalance from calculate_imbalance()

The group_imbalance path in calculate_imbalance() made sense when it was added back in 2007 with commit 908a7c1b9b80 ("sched: fix improper load balance across sched domain") because busiest->load_per_task factored into the amount of imbalance that was calculated. That is not the case today. The

[PATCH V4 0/2] load_balance() fixes for affinity

We noticed in testing that affined workloads do not provide consistent performance under certain circumstances. To isolate the issue, we began testing with a representative CPU workload. In some cases the CPU workload results would vary by a large percentage from run to run. We used JTAG and

[PATCH V4 1/2] sched/fair: Fix load_balance() affinity redo path

If load_balance() fails to migrate any tasks because all tasks were affined, load_balance() removes the source cpu from consideration and attempts to redo and balance among the new subset of cpus. There is a bug in this code path where the algorithm considers all active cpus in the system (minus

[PATCH V4 0/2] load_balance() fixes for affinity

We noticed in testing that affined workloads do not provide consistent performance under certain circumstances. To isolate the issue, we began testing with a representative CPU workload. In some cases the CPU workload results would vary by a large percentage from run to run. We used JTAG and

[PATCH V4 1/2] sched/fair: Fix load_balance() affinity redo path

If load_balance() fails to migrate any tasks because all tasks were affined, load_balance() removes the source cpu from consideration and attempts to redo and balance among the new subset of cpus. There is a bug in this code path where the algorithm considers all active cpus in the system (minus

Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

Hi, On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote: > From: Maxime Ripard > Date: Fri, 2 Jun 2017 11:13:20 +0200 > > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote: > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller

Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

Hi, On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote: > From: Maxime Ripard > Date: Fri, 2 Jun 2017 11:13:20 +0200 > > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote: > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote: > >> > From: Corentin Labbe >

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

On Thu, Jun 01, 2017 at 10:11:14PM +0800, icen...@aosc.io wrote: > 在 2017-06-01 02:43，Maxime Ripard 写道： > > On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote: > > > > > > > > > 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard > > > 写到: > > > >On Tue,

Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

On Thu, Jun 01, 2017 at 10:11:14PM +0800, icen...@aosc.io wrote: > 在 2017-06-01 02:43，Maxime Ripard 写道： > > On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote: > > > > > > > > > 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard > > > 写到: > > > >On Tue, May 23, 2017 at 09:00:59PM +0800,

Re: [linux-sunxi] [PATCH 1/2] ARM: sun8i: v3s: add device nodes for DE2 display pipeline

On Mon, May 29, 2017 at 09:01:59PM +0800, icen...@aosc.io wrote: > 在 2017-05-29 16:59，Maxime Ripard 写道： > > On Thu, May 25, 2017 at 10:28:24PM +0800, Icenowy Zheng wrote: > > > + compatible = "allwinner,sun8i-v3s-de2-mixer"; > > > + reg =

Re: [linux-sunxi] [PATCH 1/2] ARM: sun8i: v3s: add device nodes for DE2 display pipeline

On Mon, May 29, 2017 at 09:01:59PM +0800, icen...@aosc.io wrote: > 在 2017-05-29 16:59，Maxime Ripard 写道： > > On Thu, May 25, 2017 at 10:28:24PM +0800, Icenowy Zheng wrote: > > > + compatible = "allwinner,sun8i-v3s-de2-mixer"; > > > + reg =

Re: [PATCH v6 03/11] clk: bcm: Add clocks for Stingray SOC

On 06/02, Anup Patel wrote: > diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c > new file mode 100644 > index 000..342f702 > --- /dev/null > +++ b/drivers/clk/bcm/clk-sr.c > @@ -0,0 +1,320 @@ > + > +static const struct iproc_clk_ctrl lcpll_pcie_clk[] = { > +

Re: [PATCH v6 03/11] clk: bcm: Add clocks for Stingray SOC

On 06/02, Anup Patel wrote: > diff --git a/drivers/clk/bcm/clk-sr.c b/drivers/clk/bcm/clk-sr.c > new file mode 100644 > index 000..342f702 > --- /dev/null > +++ b/drivers/clk/bcm/clk-sr.c > @@ -0,0 +1,320 @@ > + > +static const struct iproc_clk_ctrl lcpll_pcie_clk[] = { > +

Re: [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs

Hi Thierry, What is the gain of introducing multiplanar API for this hardware? AFAIR all the HW implementations store the data in a single contiguous memory region and use suitable padding between planes. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Ricky Liang >

Re: [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs

Hi Thierry, What is the gain of introducing multiplanar API for this hardware? AFAIR all the HW implementations store the data in a single contiguous memory region and use suitable padding between planes. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Ricky Liang > > This patch adds

Re: [PATCH 03/11] kernfs: add an API to get kernfs node from inode number

On Fri, Jun 02, 2017 at 02:53:56PM -0700, Shaohua Li wrote: > From: Shaohua Li > > Add an API to get kernfs node from inode number. We will need this to > implement exportfs operations. > > To make the API lock free, kernfs node is freed in RCU context. And we > depend on

Re: [PATCH 03/11] kernfs: add an API to get kernfs node from inode number

On Fri, Jun 02, 2017 at 02:53:56PM -0700, Shaohua Li wrote: > From: Shaohua Li > > Add an API to get kernfs node from inode number. We will need this to > implement exportfs operations. > > To make the API lock free, kernfs node is freed in RCU context. And we > depend on kernfs_node count/ino

ath9k - Division by zero in kernel (as well as firmware panic)

ODroid XU4 $ uname -a Linux computer 4.12.0-rc3-dirty #1 SMP Wed May 31 15:02:05 CDT 2017 armv7l GNU/Linux $ lsusb ... Bus 001 Device 002: ID 2109:2813 VIA Labs, Inc. Bus 001 Device 010: ID 0cf3:7015 Qualcomm Atheros Communications TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros

ath9k - Division by zero in kernel (as well as firmware panic)

ODroid XU4 $ uname -a Linux computer 4.12.0-rc3-dirty #1 SMP Wed May 31 15:02:05 CDT 2017 armv7l GNU/Linux $ lsusb ... Bus 001 Device 002: ID 2109:2813 VIA Labs, Inc. Bus 001 Device 010: ID 0cf3:7015 Qualcomm Atheros Communications TP-Link TL-WN821N v3 / TL-WN822N v2 802.11n [Atheros

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

On 05/26, Fabien Lahoudere wrote: > Hello > > I modify ci_hrdc_imx_probe to bypass "data->phy = > devm_usb_get_phy_by_phandle(>dev, > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = >

Re: [RFC] usb-phy-generic: Add support to SMSC USB3315

On 05/26, Fabien Lahoudere wrote: > Hello > > I modify ci_hrdc_imx_probe to bypass "data->phy = > devm_usb_get_phy_by_phandle(>dev, > "fsl,usbphy", 0);". Everything works as expected and call ci_ulpi_init. > > The problem is that in ci_ulpi_init, before calling "ci->ulpi = >

Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

Cc Marek and Sylwester. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: henryhsu > > The default clock parent of jpeg on Exynos5250 is fin_pll, which is > 24MHz. We have to change the clock parent to CPLL, which is 333MHz, > and set sclk_jpeg to 166MHz. > >

Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

Cc Marek and Sylwester. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: henryhsu > > The default clock parent of jpeg on Exynos5250 is fin_pll, which is > 24MHz. We have to change the clock parent to CPLL, which is 333MHz, > and set sclk_jpeg to 166MHz. > > Signed-off-by: Heng-Ruey Hsu

[PATCH 01/11] kernfs: implement i_generation

From: Shaohua Li Set i_generation for kernfs inode. This is required to implement exportfs operations. Note, the generation is 32-bit, so it's possible the generation wraps up and we find stale files. The possiblity is low, since fhandle matches both inode number and generation. In

[PATCH 01/11] kernfs: implement i_generation

From: Shaohua Li Set i_generation for kernfs inode. This is required to implement exportfs operations. Note, the generation is 32-bit, so it's possible the generation wraps up and we find stale files. The possiblity is low, since fhandle matches both inode number and generation. In most fs, the

[PATCH 08/11] block: always attach cgroup info into bio

From: Shaohua Li blkcg_bio_issue_check() already gets blkcg for a BIO. bio_associate_blkcg() uses a percpu refcounter, so it's a very cheap operation. There is no point we don't attach the cgroup info into bio at blkcg_bio_issue_check. This also makes blktrace outputs correct cgroup

[PATCH 11/11] block: use standard blktrace API to output cgroup info for debug notes

From: Shaohua Li Currently cfq/bfq/blk-throttle output cgroup info in trace in their own way. Now we have standard blktrace API for this, so convert them to use it. Note, this changes the behavior a little bit. cgroup info isn't output by default, we only do this with 'blk_cgroup'

[PATCH 09/11] block: call __bio_free in bio_endio

From: Shaohua Li bio_free isn't a good place to free cgroup/integrity info. There are a lot of cases bio is allocated in special way (for example, in stack) and never gets called by bio_put hence bio_free, we are leaking memory. This patch moves the free to bio endio, which should

[PATCH 10/11] blktrace: add an option to allow displying cgroup path

From: Shaohua Li By default we output cgroup id in blktrace. This adds an option to display cgroup path. Since get cgroup path is a relativly heavy operation, we don't enable it by default. with the option enabled, blktrace will output something like this: dd-1353 [007] d..2

[PATCH 08/11] block: always attach cgroup info into bio

From: Shaohua Li blkcg_bio_issue_check() already gets blkcg for a BIO. bio_associate_blkcg() uses a percpu refcounter, so it's a very cheap operation. There is no point we don't attach the cgroup info into bio at blkcg_bio_issue_check. This also makes blktrace outputs correct cgroup info.

[PATCH 11/11] block: use standard blktrace API to output cgroup info for debug notes

From: Shaohua Li Currently cfq/bfq/blk-throttle output cgroup info in trace in their own way. Now we have standard blktrace API for this, so convert them to use it. Note, this changes the behavior a little bit. cgroup info isn't output by default, we only do this with 'blk_cgroup' option

[PATCH 09/11] block: call __bio_free in bio_endio

From: Shaohua Li bio_free isn't a good place to free cgroup/integrity info. There are a lot of cases bio is allocated in special way (for example, in stack) and never gets called by bio_put hence bio_free, we are leaking memory. This patch moves the free to bio endio, which should be called

[PATCH 10/11] blktrace: add an option to allow displying cgroup path

From: Shaohua Li By default we output cgroup id in blktrace. This adds an option to display cgroup path. Since get cgroup path is a relativly heavy operation, we don't enable it by default. with the option enabled, blktrace will output something like this: dd-1353 [007] d..2 293.015252:

[PATCH 07/11] blktrace: export cgroup info in trace

From: Shaohua Li Currently blktrace isn't cgroup aware. blktrace prints out task name of current context, but the task of current context isn't always in the cgroup where the BIO comes from. We can't use task name to find out IO cgroup. For example, Writeback BIOs always comes from

[PATCH 03/11] kernfs: add an API to get kernfs node from inode number

From: Shaohua Li Add an API to get kernfs node from inode number. We will need this to implement exportfs operations. To make the API lock free, kernfs node is freed in RCU context. And we depend on kernfs_node count/ino number to filter stale kernfs nodes. Signed-off-by: Shaohua

[PATCH 07/11] blktrace: export cgroup info in trace

From: Shaohua Li Currently blktrace isn't cgroup aware. blktrace prints out task name of current context, but the task of current context isn't always in the cgroup where the BIO comes from. We can't use task name to find out IO cgroup. For example, Writeback BIOs always comes from flusher

[PATCH 03/11] kernfs: add an API to get kernfs node from inode number

From: Shaohua Li Add an API to get kernfs node from inode number. We will need this to implement exportfs operations. To make the API lock free, kernfs node is freed in RCU context. And we depend on kernfs_node count/ino number to filter stale kernfs nodes. Signed-off-by: Shaohua Li ---

[PATCH 05/11] kernfs: add exportfs operations

From: Shaohua Li Now we have the facilities to implement exportfs operations. The idea is cgroup can export the fhandle info to userspace, then userspace uses fhandle to find the cgroup name. Another example is userspace can get fhandle for a cgroup and BPF uses the fhandle to

[PATCH 05/11] kernfs: add exportfs operations

From: Shaohua Li Now we have the facilities to implement exportfs operations. The idea is cgroup can export the fhandle info to userspace, then userspace uses fhandle to find the cgroup name. Another example is userspace can get fhandle for a cgroup and BPF uses the fhandle to filter info for

[PATCH 00/11]blktrace: output cgroup info

From: Shaohua Li Hi, Currently blktrace isn't cgroup aware. blktrace prints out task name of current context, but the task of current context isn't always in the cgroup where the BIO comes from. We can't use task name to find out IO cgroup. For example, Writeback BIOs always comes

[PATCH 00/11]blktrace: output cgroup info

From: Shaohua Li Hi, Currently blktrace isn't cgroup aware. blktrace prints out task name of current context, but the task of current context isn't always in the cgroup where the BIO comes from. We can't use task name to find out IO cgroup. For example, Writeback BIOs always comes from flusher

[PATCH 02/11] kernfs: use idr instead of ida to manage inode number

From: Shaohua Li kernfs uses ida to manage inode number. The problem is we can't get kernfs_node from inode number with ida. Switching to use idr, next patch will add an API to get kernfs_node from inode number. Signed-off-by: Shaohua Li --- fs/kernfs/dir.c|

[PATCH 02/11] kernfs: use idr instead of ida to manage inode number

From: Shaohua Li kernfs uses ida to manage inode number. The problem is we can't get kernfs_node from inode number with ida. Switching to use idr, next patch will add an API to get kernfs_node from inode number. Signed-off-by: Shaohua Li --- fs/kernfs/dir.c| 17 -

[PATCH 06/11] cgroup: export fhandle info for a cgroup

From: Shaohua Li Add an API to export cgroup fhandle info. We don't export a full 'struct file_handle', there are unrequired info. Sepcifically, cgroup is always a directory, so we don't need a 'FILEID_INO32_GEN_PARENT' type fhandle, we only need export the inode number and

[PATCH 04/11] kernfs: don't set dentry->d_fsdata

From: Shaohua Li When working on adding exportfs operations in kernfs, I found it's hard to initialize dentry->d_fsdata in the exportfs operations. Looks there is no way to do it without race condition. Look at the kernfs code closely, there is no point to set dentry->d_fsdata.

[PATCH 04/11] kernfs: don't set dentry->d_fsdata

From: Shaohua Li When working on adding exportfs operations in kernfs, I found it's hard to initialize dentry->d_fsdata in the exportfs operations. Looks there is no way to do it without race condition. Look at the kernfs code closely, there is no point to set dentry->d_fsdata. inode->i_private

[PATCH 06/11] cgroup: export fhandle info for a cgroup

From: Shaohua Li Add an API to export cgroup fhandle info. We don't export a full 'struct file_handle', there are unrequired info. Sepcifically, cgroup is always a directory, so we don't need a 'FILEID_INO32_GEN_PARENT' type fhandle, we only need export the inode number and generation number

Re: [PATCH 6/9] [media] s5p-jpeg: Add support for resolution change event

Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: henryhsu > > This patch adds support for resolution change event to notify clients so > they can prepare correct output buffer. When resolution change happened, > G_FMT for CAPTURE should return old

Re: [PATCH 6/9] [media] s5p-jpeg: Add support for resolution change event

Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: henryhsu > > This patch adds support for resolution change event to notify clients so > they can prepare correct output buffer. When resolution change happened, > G_FMT for CAPTURE should return old resolution and format before

[PATCH] sparc64: mm: fix copy_tsb to correctly copy huge page TSBs

When a TSB grows beyond its current capacity, a new TSB is allocated and copy_tsb is called to copy entries from the old TSB to the new. A hash shift based on page size is used to calculate the index of an entry in the TSB. copy_tsb has hard coded PAGE_SHIFT in these calculations. However, for

[PATCH] sparc64: mm: fix copy_tsb to correctly copy huge page TSBs

When a TSB grows beyond its current capacity, a new TSB is allocated and copy_tsb is called to copy entries from the old TSB to the new. A hash shift based on page size is used to calculate the index of an entry in the TSB. copy_tsb has hard coded PAGE_SHIFT in these calculations. However, for

Re: [PATCH] rpmsg: rpmsg_core: fix null-ptr dereference for devices without ops

Hi Henri, On 06/02/2017 06:35 AM, Henri Roosen wrote: > A device might not have an ops structure registered. This The rpmsg devices are registered from the respective backends, which are supposed to plug in their ops. What is the scenario where you think these ops might not be populated? We

Re: [PATCH] rpmsg: rpmsg_core: fix null-ptr dereference for devices without ops

Hi Henri, On 06/02/2017 06:35 AM, Henri Roosen wrote: > A device might not have an ops structure registered. This The rpmsg devices are registered from the respective backends, which are supposed to plug in their ops. What is the scenario where you think these ops might not be populated? We

Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

Cc Marek Szyprowski. Marek, could you share your opinion about this patch? On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal > > This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU > and ARM DMA IOMMU configurations are supported. The

Re: [PATCH] selftests: sync: Skip the test if kernel support is not found

On 05/31/2017 04:40 AM, Michael Ellerman wrote: > The "Sync framework" test doesn't work if the kernel has no support, > obviously. Rather than reporting a failure, check for the kernel support > by looking for /sys/kernel/debug/sync/sw_sync, and if not found skip the > test. > > Signed-off-by:

Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

Cc Marek Szyprowski. Marek, could you share your opinion about this patch? On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal > > This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU > and ARM DMA IOMMU configurations are supported. The address space is >

Re: [PATCH] selftests: sync: Skip the test if kernel support is not found

On 05/31/2017 04:40 AM, Michael Ellerman wrote: > The "Sync framework" test doesn't work if the kernel has no support, > obviously. Rather than reporting a failure, check for the kernel support > by looking for /sys/kernel/debug/sync/sw_sync, and if not found skip the > test. > > Signed-off-by:

Re: [PATCH] rpmsg: virtio_rpmsg_bus: cleanup multiple assignment to ops

On 06/02/2017 06:36 AM, Henri Roosen wrote: > Trivial cleanup: the .ops pointer is assigned twice. This patch removes the > first assignment. > > Signed-off-by: Henri Roosen Acked-by: Suman Anna > --- > drivers/rpmsg/virtio_rpmsg_bus.c | 3 --- > 1

Re: [PATCH] rpmsg: virtio_rpmsg_bus: cleanup multiple assignment to ops

On 06/02/2017 06:36 AM, Henri Roosen wrote: > Trivial cleanup: the .ops pointer is assigned twice. This patch removes the > first assignment. > > Signed-off-by: Henri Roosen Acked-by: Suman Anna > --- > drivers/rpmsg/virtio_rpmsg_bus.c | 3 --- > 1 file changed, 3 deletions(-) > > diff

Re: [PATCH v2] selftests/vm: Fix test for virtual address range mapping for arm64

On 05/18/2017 06:52 AM, Michal Suchanek wrote: > Arm64 has 256TB address space so fix the test to pass on Arm as well. > > Also remove unneeded numaif header. > > Signed-off-by: Michal Suchanek Thanks. Applied to linux-kselftest next for 4.13-rc1 -- Shuah > --- > v2: > -

Re: [PATCH v2] selftests/vm: Fix test for virtual address range mapping for arm64

On 05/18/2017 06:52 AM, Michal Suchanek wrote: > Arm64 has 256TB address space so fix the test to pass on Arm as well. > > Also remove unneeded numaif header. > > Signed-off-by: Michal Suchanek Thanks. Applied to linux-kselftest next for 4.13-rc1 -- Shuah > --- > v2: > - do not test high

Re: [PATCH][net-next] rxrpc: remove redundant proc_remove call

Colin King wrote: > From: Colin Ian King > > The proc_remove call is dead code as it occurs after a return and > hence can never be called. Remove it. > > Detected by CoverityScan, CID#1437743 ("Logically dead code") > > Signed-off-by:

Re: [PATCH][net-next] rxrpc: remove redundant proc_remove call

Colin King wrote: > From: Colin Ian King > > The proc_remove call is dead code as it occurs after a return and > hence can never be called. Remove it. > > Detected by CoverityScan, CID#1437743 ("Logically dead code") > > Signed-off-by: Colin Ian King Acked-by: David Howells

<    1   2   3   4   5   6   7   8   9   10   >