Re: [PATCH v2 1/2] sched/fair: Fix how load gets propagated from cfs_rq to its sched_entity

On Wed, May 03, 2017 at 05:45:46PM -0400, Tejun Heo wrote: > FUDGE2: Changes things a lot (load values go wild) but only because > it's missing scale_load_down(). After adding > scale_load_down(), it doesn't do much. For this to work, it > needs to be always propagated,

Re: [PATCH v2 1/2] sched/fair: Fix how load gets propagated from cfs_rq to its sched_entity

On Wed, May 03, 2017 at 05:45:46PM -0400, Tejun Heo wrote: > FUDGE2: Changes things a lot (load values go wild) but only because > it's missing scale_load_down(). After adding > scale_load_down(), it doesn't do much. For this to work, it > needs to be always propagated,

Re: [PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver

On Wed 03 May 02:55 PDT 2017, Jassi Brar wrote: > Loic, thanks for adding me. > > On Wed, May 3, 2017 at 2:58 PM, Loic PALLARDY wrote: > > > > > >> -Original Message- > >> From: linux-remoteproc-ow...@vger.kernel.org [mailto:linux-remoteproc- > >>

Re: [PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver

On Wed 03 May 02:55 PDT 2017, Jassi Brar wrote: > Loic, thanks for adding me. > > On Wed, May 3, 2017 at 2:58 PM, Loic PALLARDY wrote: > > > > > >> -Original Message- > >> From: linux-remoteproc-ow...@vger.kernel.org [mailto:linux-remoteproc- > >> ow...@vger.kernel.org] On Behalf Of

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

On Wed, May 3, 2017 at 6:17 PM, Eric Anholt wrote: > Laurent Pinchart writes: > >> Hi Daniel, >> >> On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote: >>> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote: >>> > On Wednesday

Re: [PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

On Wed, May 3, 2017 at 6:17 PM, Eric Anholt wrote: > Laurent Pinchart writes: > >> Hi Daniel, >> >> On Wednesday 03 May 2017 16:28:56 Daniel Vetter wrote: >>> On Wed, May 03, 2017 at 12:36:06PM +0300, Laurent Pinchart wrote: >>> > On Wednesday 03 May 2017 11:32:17 Daniel Vetter wrote: >>> >> On

Re: [GIT PULL] locking fixes

On Wed, May 03, 2017 at 04:21:01PM -0700, Linus Torvalds wrote: > This is from last merge window, and the reason I react now is that > nobody noticed or cared until we had a release.. > > On Mon, Feb 27, 2017 at 11:57 PM, Ingo Molnar wrote: > > > > Peter Zijlstra (1): > >

Re: [GIT PULL] locking fixes

On Wed, May 03, 2017 at 04:21:01PM -0700, Linus Torvalds wrote: > This is from last merge window, and the reason I react now is that > nobody noticed or cared until we had a release.. > > On Mon, Feb 27, 2017 at 11:57 PM, Ingo Molnar wrote: > > > > Peter Zijlstra (1): > >

[PATCH v6 6/8] dt-bindings: mfd: Add TI tps6105x chip bindings

There are Device Tree source files defining a device node for the tps61050/61052 I2C chip but there isn't a binding document for it. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Tony Lindgren --- Changes in

[PATCH v6 6/8] dt-bindings: mfd: Add TI tps6105x chip bindings

There are Device Tree source files defining a device node for the tps61050/61052 I2C chip but there isn't a binding document for it. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Tony Lindgren --- Changes in v6: None Changes in v5: - Add Rob Herring's Acked-by tag.

[PATCH v6 7/8] mfd: tps6105x: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v6 8/8] ARM: ux500: Add vendor prefix to tps61052 node

The tps61052 device node doesn't have a vendor prefix in its compatible string, fix it by adding one. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Tony Lindgren --- Changes in v6: None Changes in v5: - Add Rob

[PATCH v6 7/8] mfd: tps6105x: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v6 8/8] ARM: ux500: Add vendor prefix to tps61052 node

The tps61052 device node doesn't have a vendor prefix in its compatible string, fix it by adding one. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Tony Lindgren --- Changes in v6: None Changes in v5: - Add Rob Herring's Acked-by tag. - Add Acked-by: Tony Lindgren

[PATCH v6 4/8] ARM: dts: n8x0: Add vendor prefix to retu node

The retu device node doesn't have a vendor prefix in its compatible string, fix it by adding one. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen Acked-by: Tony Lindgren

[PATCH v6 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings

There are Device Tree source files defining a device node for the retu/tahvo I2C chip, but there isn't a DT binding document for it. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen Acked-by: Tony

[PATCH v6 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example

The example contains a device node for a retu device, but its compatible string doesn't have a vendor prefix. While being there, drop the -mfd suffix since isn't correct. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen

[PATCH v6 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings

There are Device Tree source files defining a device node for the retu/tahvo I2C chip, but there isn't a DT binding document for it. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen Acked-by: Tony Lindgren Acked-by: Lee Jones --- Changes in v6: -

[PATCH v6 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example

The example contains a device node for a retu device, but its compatible string doesn't have a vendor prefix. While being there, drop the -mfd suffix since isn't correct. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen Acked-by: Tony Lindgren

[PATCH v6 4/8] ARM: dts: n8x0: Add vendor prefix to retu node

The retu device node doesn't have a vendor prefix in its compatible string, fix it by adding one. Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen Acked-by: Tony Lindgren Reviewed-by: Wolfram Sang --- Changes in v6: - Add Wolfram Sang's Reviewed-by tag.

[PATCH v6 3/8] mfd: retu: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v6 2/8] mfd: retu: Drop -mfd suffix from I2C device ID name

It's not correct to encode the subsystem in the I2C device name, so drop the -mfd suffix. To maintain bisect-ability, change driver and platform code / DTS users in the same patch. Suggested-by: Lee Jones Signed-off-by: Javier Martinez Canillas

[PATCH v6 3/8] mfd: retu: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH v6 2/8] mfd: retu: Drop -mfd suffix from I2C device ID name

It's not correct to encode the subsystem in the I2C device name, so drop the -mfd suffix. To maintain bisect-ability, change driver and platform code / DTS users in the same patch. Suggested-by: Lee Jones Signed-off-by: Javier Martinez Canillas Acked-by: Rob Herring Acked-by: Aaro Koskinen

[PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to mfd I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

[PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

Hello, This series add OF device ID tables to mfd I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a

[PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

Avoid stuck and hacking jiffies for a long time and using msleep() for certatin numeber of cylces without the factor of safety but using the the long delay considering the factor of safety with the while loop such that after msleep for a short period of time we check the msg if it's OK, breaking

[PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.

Avoid stuck and hacking jiffies for a long time and using msleep() for certatin numeber of cylces without the factor of safety but using the the long delay considering the factor of safety with the while loop such that after msleep for a short period of time we check the msg if it's OK, breaking

Re: [lkp-robot] [rcuperf] 87c458e630: WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule

On 05/03, Paul E. McKenney wrote: >On Thu, May 04, 2017 at 10:59:26AM +0800, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: 87c458e6304c6a1b37bf856e88c70fc37f08851f ("rcuperf: Set more >> user-friendly defaults") >>

Re: [lkp-robot] [rcuperf] 87c458e630: WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule

On 05/03, Paul E. McKenney wrote: >On Thu, May 04, 2017 at 10:59:26AM +0800, kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: 87c458e6304c6a1b37bf856e88c70fc37f08851f ("rcuperf: Set more >> user-friendly defaults") >>

Re: [kernel-hardening] Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

On Wed, May 03, 2017 at 01:19:41PM -0700, Kees Cook wrote: > On Wed, May 3, 2017 at 1:02 PM, Matt Brown wrote: > > On 05/03/2017 03:45 PM, Greg KH wrote: > >> > >> On Wed, May 03, 2017 at 12:32:07PM -0700, Kees Cook wrote: > >>> > >>> On Mon, Apr 24, 2017 at 6:57 AM, Serge E.

Re: [kernel-hardening] Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

On Wed, May 03, 2017 at 01:19:41PM -0700, Kees Cook wrote: > On Wed, May 3, 2017 at 1:02 PM, Matt Brown wrote: > > On 05/03/2017 03:45 PM, Greg KH wrote: > >> > >> On Wed, May 03, 2017 at 12:32:07PM -0700, Kees Cook wrote: > >>> > >>> On Mon, Apr 24, 2017 at 6:57 AM, Serge E. Hallyn > >>> wrote:

Re: rlimits: Print more information when CPU/RT limits are exceeded

On Tue, 2 May 2017, at 08:42 AM, Dave Jones wrote: > On Mon, May 01, 2017 at 11:21:52PM +, Linux Kernel wrote: > > Web: > https://git.kernel.org/torvalds/c/e7ea7c9806a2681807257ea89085339d33f7fa0b > > Commit: e7ea7c9806a2681807257ea89085339d33f7fa0b > > Parent:

Re: rlimits: Print more information when CPU/RT limits are exceeded

On Tue, 2 May 2017, at 08:42 AM, Dave Jones wrote: > On Mon, May 01, 2017 at 11:21:52PM +, Linux Kernel wrote: > > Web: > https://git.kernel.org/torvalds/c/e7ea7c9806a2681807257ea89085339d33f7fa0b > > Commit: e7ea7c9806a2681807257ea89085339d33f7fa0b > > Parent:

[RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

The Samsung email address will stop working soon, so use my personal email address instead. Also, there used to be a MFD and RTC drivers for max77802 but now these have been merged with the max77686 MFD and RTC drivers. The only driver that's still max77802 specific is the regulator one since

[RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

The Samsung email address will stop working soon, so use my personal email address instead. Also, there used to be a MFD and RTC drivers for max77802 but now these have been merged with the max77686 MFD and RTC drivers. The only driver that's still max77802 specific is the regulator one since

Re: new warning at net/wireless/util.c:1236

Linus Torvalds writes: > So my Dell XPS 13 seems to have grown a new warning as of the > networking merge yesterday. > > Things still work, but when it starts warning, it generates a *lot* of > noise (I got 36 of these within about ten minutes). > > I have no idea

Re: new warning at net/wireless/util.c:1236

Linus Torvalds writes: > So my Dell XPS 13 seems to have grown a new warning as of the > networking merge yesterday. > > Things still work, but when it starts warning, it generates a *lot* of > noise (I got 36 of these within about ten minutes). > > I have no idea what triggered it, because when

linux-next: Tree for May 4

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170503: The f2fs tree gained a conflict against the fscrypt tree. The spi-nor tree gained a build failure so I used the version from next-20170503

linux-next: Tree for May 4

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170503: The f2fs tree gained a conflict against the fscrypt tree. The spi-nor tree gained a build failure so I used the version from next-20170503

Re: net/ipv6: GPF in rt6_device_match

On 5/3/17 9:55 PM, Cong Wang wrote: > Why not add a printk and play with my patch to see the difference? I have other things to do. If you believe your patch fixes the problem, send it and let Andrey verify.

Re: net/ipv6: GPF in rt6_device_match

On 5/3/17 9:55 PM, Cong Wang wrote: > Why not add a printk and play with my patch to see the difference? I have other things to do. If you believe your patch fixes the problem, send it and let Andrey verify.

Re: [PATCH v2 15/20] drm/sun4i: Ignore the generic connectors for components

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The generic connectors such as hdmi-connector doesn't have any driver in, > so if they are added to the component list, we will be waiting forever for > a non-existing driver to probe. > > Add a list of the

Re: [PATCH v2 15/20] drm/sun4i: Ignore the generic connectors for components

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The generic connectors such as hdmi-connector doesn't have any driver in, > so if they are added to the component list, we will be waiting forever for > a non-existing driver to probe. > > Add a list of the connectors we want to ignore when

Re: [PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > It appears that the total vertical resolution needs to be doubled when > we're not in interlaced. Make sure that is the case. I think the total vertical resolution needs to be doubled in all cases. It just

Re: [PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > It appears that the total vertical resolution needs to be doubled when > we're not in interlaced. Make sure that is the case. I think the total vertical resolution needs to be doubled in all cases. It just happens that you should've been

Re: [PATCH v2 13/20] drm/sun4i: tcon: Change vertical total size computation inconsistency

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > Both TCON channels need to have the resolution doubled, since the size the > hardware is going to use is whatever we put in the register divided by two. > > However, we handle it differently for the two

Re: [PATCH v2 13/20] drm/sun4i: tcon: Change vertical total size computation inconsistency

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > Both TCON channels need to have the resolution doubled, since the size the > hardware is going to use is whatever we put in the register divided by two. > > However, we handle it differently for the two channels: in the channel 0, > our

Re: [PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > Even though that mux is undocumented, it seems like it needs to be set to 1 > when using composite, and 0 when using HDMI. > > Signed-off-by: Maxime Ripard Acked-by:

Re: [PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > Even though that mux is undocumented, it seems like it needs to be set to 1 > when using composite, and 0 when using HDMI. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai

Re: net/ipv6: GPF in rt6_device_match

On Wed, May 3, 2017 at 7:43 PM, David Ahern wrote: > On 5/3/17 5:35 PM, Cong Wang wrote: >> Ah, we need: >> >> @@ -4024,7 +4027,7 @@ static struct pernet_operations ip6_route_net_late_ops >> = { >> >> static struct notifier_block ip6_route_dev_notifier = { >>

Re: net/ipv6: GPF in rt6_device_match

On Wed, May 3, 2017 at 7:43 PM, David Ahern wrote: > On 5/3/17 5:35 PM, Cong Wang wrote: >> Ah, we need: >> >> @@ -4024,7 +4027,7 @@ static struct pernet_operations ip6_route_net_late_ops >> = { >> >> static struct notifier_block ip6_route_dev_notifier = { >> .notifier_call =

Re: [PATCH v2 10/20] drm/sun4i: tcon: Move the muxing out of the mode set function

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The muxing can actually happen on both channels on some SoCs, so it makes > more sense to just move it out of the sun4i_tcon1_mode_set function and > create a separate function that needs to be called by the

Re: [PATCH v2 10/20] drm/sun4i: tcon: Move the muxing out of the mode set function

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The muxing can actually happen on both channels on some SoCs, so it makes > more sense to just move it out of the sun4i_tcon1_mode_set function and > create a separate function that needs to be called by the encoders. > > Let's do that and

Re: [linux-sunxi] Designware UART bug

On Wed, May 3, 2017 at 8:40 AM, Olliver Schinagl wrote: > Hey Tim, > > Ok, so as far as I understand (from the datasheet) the intended way to do > this would be to check for the BUSY IRQ & USR[0] IRQ and if it is busy, > (re-write) the LCR. We no longer do this because it did

Re: [linux-sunxi] Designware UART bug

On Wed, May 3, 2017 at 8:40 AM, Olliver Schinagl wrote: > Hey Tim, > > Ok, so as far as I understand (from the datasheet) the intended way to do > this would be to check for the BUSY IRQ & USR[0] IRQ and if it is busy, > (re-write) the LCR. We no longer do this because it did not work due to the

Re: Future of liblockdep

On Wed, May 03, 2017 at 10:19:55PM +0100, Ben Hutchings wrote: > On Wed, 2017-05-03 at 21:00 +, alexander.le...@verizon.com wrote: > > On Wed, May 03, 2017 at 09:13:57PM +0100, Ben Hutchings wrote: > > > liblockdep hasn't been buildable since (I think) Linux 4.6.  I sent > > > Sasha fixes for

Re: Future of liblockdep

On Wed, May 03, 2017 at 10:19:55PM +0100, Ben Hutchings wrote: > On Wed, 2017-05-03 at 21:00 +, alexander.le...@verizon.com wrote: > > On Wed, May 03, 2017 at 09:13:57PM +0100, Ben Hutchings wrote: > > > liblockdep hasn't been buildable since (I think) Linux 4.6.  I sent > > > Sasha fixes for

Re: [PATCH 0/7] KVM: MMU: fast write protect

On 05/03/2017 10:57 PM, Paolo Bonzini wrote: On 03/05/2017 16:50, Xiao Guangrong wrote: Furthermore, userspace has no knowledge about if PML is enable (it can be required from sysfs, but it is a good way in QEMU), so it is difficult for the usespace to know when to use write-protect-all.

Re: [PATCH 0/7] KVM: MMU: fast write protect

On 05/03/2017 10:57 PM, Paolo Bonzini wrote: On 03/05/2017 16:50, Xiao Guangrong wrote: Furthermore, userspace has no knowledge about if PML is enable (it can be required from sysfs, but it is a good way in QEMU), so it is difficult for the usespace to know when to use write-protect-all.

Re: [PATCH v2 8/20] clk: sunxi-ng: sun5i: Export video PLLs

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The video PLLs are used directly by the HDMI controller. Export them so > that we can use them in our DT node. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai

Re: [PATCH v2 8/20] clk: sunxi-ng: sun5i: Export video PLLs

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The video PLLs are used directly by the HDMI controller. Export them so > that we can use them in our DT node. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai

Re: [PATCH v2 7/20] clk: sunxi-ng: mux: Re-adjust parent rate

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > Currently, the parent rate given back to the clock framework in our > request is the original parent rate we calculated before trying to round > the rate of our clock. > > This works fine unless our clock

Re: [PATCH v2 7/20] clk: sunxi-ng: mux: Re-adjust parent rate

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > Currently, the parent rate given back to the clock framework in our > request is the original parent rate we calculated before trying to round > the rate of our clock. > > This works fine unless our clock also changes its parent rate, in

Re: [PATCH v2 6/20] clk: sunxi-ng: mux: Change pre-divider application function prototype

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The current function name is a bit confusing, and doesn't really allow to > create an explicit function to reverse the operation. > > We also for now change the parent rate through a pointer, while we don't >

Re: [PATCH v2 6/20] clk: sunxi-ng: mux: Change pre-divider application function prototype

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The current function name is a bit confusing, and doesn't really allow to > create an explicit function to reverse the operation. > > We also for now change the parent rate through a pointer, while we don't > return anything. > > In order to

Re: [PATCH v2 5/20] clk: sunxi-ng: mux: split out the pre-divider computation code

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The pre-divider retrieval code was merged into the function to apply the > current pre-divider onto the parent clock rate so that we can use that > adjusted value to do our factors computation. > > However,

Re: [PATCH v2 5/20] clk: sunxi-ng: mux: split out the pre-divider computation code

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The pre-divider retrieval code was merged into the function to apply the > current pre-divider onto the parent clock rate so that we can use that > adjusted value to do our factors computation. > > However, since we'll need to do the reverse

Re: [PATCH v2 4/20] clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The current code only rely on the parent to change its rate in the case > where CLK_SET_RATE_PARENT is set. > > However, some clock rates might be obtained only through a modification of > the parent and the

Re: [PATCH v2 4/20] clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The current code only rely on the parent to change its rate in the case > where CLK_SET_RATE_PARENT is set. > > However, some clock rates might be obtained only through a modification of > the parent and the clock divider. Just rely on the

Re: [PATCH v2 3/20] clk: sunxi-ng: div: Switch to divider_round_rate

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > divider_round_rate already evaluates changing the parent rate if ^^^ Might want to update this, as you are now using the new function you added in patch 1. > CLK_SET_RATE_PARENT is set. Now that we

Re: [PATCH v2 3/20] clk: sunxi-ng: div: Switch to divider_round_rate

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > divider_round_rate already evaluates changing the parent rate if ^^^ Might want to update this, as you are now using the new function you added in patch 1. > CLK_SET_RATE_PARENT is set. Now that we can do that on muxes too, let's >

Re: [PATCH v2 2/20] clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The clocks might need to modify their parent clocks. In order to make that > possible, give them access to the parent clock being evaluated, and to a > pointer to the parent rate so that they can modify it if

Re: [PATCH v2 2/20] clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard wrote: > The clocks might need to modify their parent clocks. In order to make that > possible, give them access to the parent clock being evaluated, and to a > pointer to the parent rate so that they can modify it if needed. > > Signed-off-by: Maxime

Re: [lkp-robot] [rcuperf] 87c458e630: WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule

On Thu, May 04, 2017 at 10:59:26AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 87c458e6304c6a1b37bf856e88c70fc37f08851f ("rcuperf: Set more > user-friendly defaults") > https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git >

Re: [lkp-robot] [rcuperf] 87c458e630: WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule

On Thu, May 04, 2017 at 10:59:26AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 87c458e6304c6a1b37bf856e88c70fc37f08851f ("rcuperf: Set more > user-friendly defaults") > https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git >

RE: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

Hi Chis, do you have any comments for this problem? >> +static struct sg_table * >> +intel_vgpu_create_sg_pages(struct drm_device *dev, u32 start, u32 >> +num_pages) { >> +struct drm_i915_private *dev_priv = dev->dev_private; >> +struct sg_table *st; >> +struct scatterlist *sg; >> +

RE: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

Hi Chis, do you have any comments for this problem? >> +static struct sg_table * >> +intel_vgpu_create_sg_pages(struct drm_device *dev, u32 start, u32 >> +num_pages) { >> +struct drm_i915_private *dev_priv = dev->dev_private; >> +struct sg_table *st; >> +struct scatterlist *sg; >> +

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

Hi Alex, do you have any comments for this interface? >-Original Message- >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >Behalf Of Chen, Xiaoguang >Sent: Wednesday, May 03, 2017 9:39 AM >To: Gerd Hoffmann >Cc: Tian, Kevin

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

Hi Alex, do you have any comments for this interface? >-Original Message- >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >Behalf Of Chen, Xiaoguang >Sent: Wednesday, May 03, 2017 9:39 AM >To: Gerd Hoffmann >Cc: Tian, Kevin ; intel-...@lists.freedesktop.org;

Re: [PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

Hi, On Thu, May 4, 2017 at 4:34 AM, Maxime Ripard wrote: > Hi, > > On Wed, May 03, 2017 at 11:16:53AM +0800, Chen-Yu Tsai wrote: >> The MMC clocks on newer SoCs, such as the A83T and H3, support the >> "new timing mode". Under this mode, the output of the clock

Re: [PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

Hi, On Thu, May 4, 2017 at 4:34 AM, Maxime Ripard wrote: > Hi, > > On Wed, May 03, 2017 at 11:16:53AM +0800, Chen-Yu Tsai wrote: >> The MMC clocks on newer SoCs, such as the A83T and H3, support the >> "new timing mode". Under this mode, the output of the clock is divided >> by 2, and the clock

[lkp-robot] [rcuperf] 87c458e630: WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule

FYI, we noticed the following commit: commit: 87c458e6304c6a1b37bf856e88c70fc37f08851f ("rcuperf: Set more user-friendly defaults") https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2017.04.21a in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -cpu host

[lkp-robot] [rcuperf] 87c458e630: WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule

FYI, we noticed the following commit: commit: 87c458e6304c6a1b37bf856e88c70fc37f08851f ("rcuperf: Set more user-friendly defaults") https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2017.04.21a in testcase: boot on test machine: qemu-system-x86_64 -enable-kvm -cpu host

Re: net/ipv6: GPF in rt6_device_match

On 5/3/17 5:35 PM, Cong Wang wrote: > Ah, we need: > > @@ -4024,7 +4027,7 @@ static struct pernet_operations ip6_route_net_late_ops > = { > > static struct notifier_block ip6_route_dev_notifier = { > .notifier_call = ip6_route_dev_notify, > - .priority = 0, > + .priority =

Re: net/ipv6: GPF in rt6_device_match

On 5/3/17 5:35 PM, Cong Wang wrote: > Ah, we need: > > @@ -4024,7 +4027,7 @@ static struct pernet_operations ip6_route_net_late_ops > = { > > static struct notifier_block ip6_route_dev_notifier = { > .notifier_call = ip6_route_dev_notify, > - .priority = 0, > + .priority =

[lkp-robot] [fw_cfg] 9f0f3ea314: BUG:KASAN:null-ptr-deref_on_address

FYI, we noticed the following commit: commit: 9f0f3ea31419e56d861441b2d863e992d13f19d7 ("fw_cfg: do DMA read operation") url: https://github.com/0day-ci/linux/commits/marcandre-lureau-redhat-com/fw_cfg-add-DMA-operations/20170429-202925 in testcase: boot on test machine: qemu-system-x86_64

[lkp-robot] [fw_cfg] 9f0f3ea314: BUG:KASAN:null-ptr-deref_on_address

FYI, we noticed the following commit: commit: 9f0f3ea31419e56d861441b2d863e992d13f19d7 ("fw_cfg: do DMA read operation") url: https://github.com/0day-ci/linux/commits/marcandre-lureau-redhat-com/fw_cfg-add-DMA-operations/20170429-202925 in testcase: boot on test machine: qemu-system-x86_64

deadlock due to circular dependency between threads

Hi all, I am working on a platform, which is using the Linux version 4.4. I have observed a DEADLOCK between couple of threads and looking for suggestions/comments. Here is my understanding from the call stacks of these blocked tasks. 0) CPU3 is getting hot plugged from a kthread and which

deadlock due to circular dependency between threads

Hi all, I am working on a platform, which is using the Linux version 4.4. I have observed a DEADLOCK between couple of threads and looking for suggestions/comments. Here is my understanding from the call stacks of these blocked tasks. 0) CPU3 is getting hot plugged from a kthread and which

[PATCH] perf/x86/intel/cqm: Make sure the head event of cache_groups always has valid RMID

It is assumed that the head of cache_groups always has valid RMID, which isn't true. When we deallocate RMID from conflicting events currently we don't move them to the tail, and one of those events can happen to be in the head. Another case is we allocate RMIDs for all the events except the head

[PATCH] perf/x86/intel/cqm: Make sure the head event of cache_groups always has valid RMID

It is assumed that the head of cache_groups always has valid RMID, which isn't true. When we deallocate RMID from conflicting events currently we don't move them to the tail, and one of those events can happen to be in the head. Another case is we allocate RMIDs for all the events except the head

Re: [PATCH v3] x86/mm: Fix incorrect for loop count calculation in sync_global_pgds

On Wed, May 3, 2017 at 7:25 PM, Baoquan He wrote: > Jeff Moyer reported that on his system with two memory regions 0~64G and > 1T~1T+192G, and kernel option "memmap=192G!1024G" added, enabling kaslr > will make system hang intermittently during boot. While adding 'nokaslr' >

Re: [PATCH v3] x86/mm: Fix incorrect for loop count calculation in sync_global_pgds

On Wed, May 3, 2017 at 7:25 PM, Baoquan He wrote: > Jeff Moyer reported that on his system with two memory regions 0~64G and > 1T~1T+192G, and kernel option "memmap=192G!1024G" added, enabling kaslr > will make system hang intermittently during boot. While adding 'nokaslr' > won't. > > This is

Re: I'd like to donate a MacBook Pro

2017-05-03 8:58 GMT-06:00 Joerg Roedel : > On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: >> 2017-05-03 5:58 GMT-06:00 Greg KH : >> > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> >> Today I ran a regression test to

Re: I'd like to donate a MacBook Pro

2017-05-03 8:58 GMT-06:00 Joerg Roedel : > On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: >> 2017-05-03 5:58 GMT-06:00 Greg KH : >> > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> >> Today I ran a regression test to determine which commit made the >> >> keyboard

Re: [PATCH] nvme-core: add apst_override param to force APST if controller does not report APSTA=1

On Wed, May 03, 2017 at 07:02:07PM -0700, Alexander Kappner wrote: > Some buggy NVMe controllers support APST (autonomous power > state transitions), but do not report APSTA=1. On these controllers, the NVMe > driver does not enable APST support. I have verified this problem occurring > on >

Re: [PATCH] nvme-core: add apst_override param to force APST if controller does not report APSTA=1

On Wed, May 03, 2017 at 07:02:07PM -0700, Alexander Kappner wrote: > Some buggy NVMe controllers support APST (autonomous power > state transitions), but do not report APSTA=1. On these controllers, the NVMe > driver does not enable APST support. I have verified this problem occurring > on >

Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem

On 2017/5/4 2:46, Rik van Riel wrote: > On Tue, 2017-05-02 at 13:54 -0700, David Rientjes wrote: > >>> diff --git a/drivers/char/mem.c b/drivers/char/mem.c >>> index 7e4a9d1..3a765e02 100644 >>> --- a/drivers/char/mem.c >>> +++ b/drivers/char/mem.c >>> @@ -55,7 +55,7 @@ static inline int >>

Re: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem

On 2017/5/4 2:46, Rik van Riel wrote: > On Tue, 2017-05-02 at 13:54 -0700, David Rientjes wrote: > >>> diff --git a/drivers/char/mem.c b/drivers/char/mem.c >>> index 7e4a9d1..3a765e02 100644 >>> --- a/drivers/char/mem.c >>> +++ b/drivers/char/mem.c >>> @@ -55,7 +55,7 @@ static inline int >>

  1   2   3   4   5   6   7   8   9   10   >