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

[Peter Zijlstra]

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, which btw shouldn't be
> prohibitively expensive given other operations which are
> performed at the same time.

Urgh, and my numbers were so pretty :/

Maybe I need to wake up, but I'm not immediately seeing where the
scale_load_down() went missing for FUDGE2.

FUDGE does indeed appear to have one missing.

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

[Peter Zijlstra]

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, which btw shouldn't be
> prohibitively expensive given other operations which are
> performed at the same time.

Urgh, and my numbers were so pretty :/

Maybe I need to wake up, but I'm not immediately seeing where the
scale_load_down() went missing for FUDGE2.

FUDGE does indeed appear to have one missing.

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

[Bjorn Andersson]

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 Bjorn Andersson
> >> Sent: Wednesday, May 03, 2017 7:29 AM
> >> To: Andy Gross ; Rob Herring
> >> ; Mark Rutland ; Ohad Ben-
> >> Cohen 
> >> Cc: linux-arm-...@vger.kernel.org; linux-...@vger.kernel.org;
> >> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> >> remotep...@vger.kernel.org
> >> Subject: [PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver
> >>
> >> This implements a driver that exposes the IPC bits found in the APCS Global
> >> block in various Qualcomm platforms. The bits are used to signal inter-
> >> processor communication signals from the application CPU to other masters.
> >>
> >> The driver implements the "doorbell" binding and could be used as basis 
> >> for a
> >> new Linux framework, if found useful outside Qualcomm.
> >>
> > Hi Bjorn,
> >
> > Even if Qualcom APCS IPC is limited, why don't you rely on existing mailbox 
> > framework.
> > It is there to gather all IPC management under the same interface.
> > No need to create a new one from my pov.
> > If you don't provide message data, mailbox framework behaves as doorbell.
> >
> QCOM RPM reinvented the wheel for what mailbox framework already did,
> despite my pointing it out =>
> http://lkml.iu.edu/hypermail//linux/kernel/1406.2/03918.html
> 

The RPM interface works by writing various information in shared DRAM
and then invoking an interrupt on the remote processor. What this patch
does is introduce an abstraction for the invocation of that interrupt.

My argumentation against using the mailbox framework for the RPM case
was that the message model is a software construct and doesn't fit the
mailbox framework.


But the single step of invoking the remote interrupt is essentially a
non-message mailbox. Perhaps this part of the RPM driver is what you're
referring to in your comments on the RPM.

Before "inventing" the function for acquiring a handle to a doorbell I
did look at making this a mailbox controller, but as each mailbox
channel related to a single bit and 1 is the only value we'll ever write
it didn't feel like it matches the mailbox expectations. But as you seem
to object I'll attempt to rewrite it using the mailbox framework
instead.


But which one of these would be appropriate for a "mailbox channel" that
doesn't have any actual messages?

  mbox_send_message(chan, NULL)
or 
  const int one = 1;
  mbox_send_message(chan, (void*));

> The driver bypassed mailbox framework and was pushed via another tree.
> Same is being attempted now, only now it is more expensive to switch
> to generic mailbox framework having spent so much time on QCOM
> specific implementation of controller and protocol drivers inside
> drivers/soc/qcom/

I'm not sure I follow this, there's no extensive rework going on here -
all I'm trying to do is abstract the "writel(BIT(x), ipc_reg)" line of
the RPM driver, because it's being used in other clients as well.

Regards,
Bjorn

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

[Bjorn Andersson]

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 Bjorn Andersson
> >> Sent: Wednesday, May 03, 2017 7:29 AM
> >> To: Andy Gross ; Rob Herring
> >> ; Mark Rutland ; Ohad Ben-
> >> Cohen 
> >> Cc: linux-arm-...@vger.kernel.org; linux-...@vger.kernel.org;
> >> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> >> remotep...@vger.kernel.org
> >> Subject: [PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver
> >>
> >> This implements a driver that exposes the IPC bits found in the APCS Global
> >> block in various Qualcomm platforms. The bits are used to signal inter-
> >> processor communication signals from the application CPU to other masters.
> >>
> >> The driver implements the "doorbell" binding and could be used as basis 
> >> for a
> >> new Linux framework, if found useful outside Qualcomm.
> >>
> > Hi Bjorn,
> >
> > Even if Qualcom APCS IPC is limited, why don't you rely on existing mailbox 
> > framework.
> > It is there to gather all IPC management under the same interface.
> > No need to create a new one from my pov.
> > If you don't provide message data, mailbox framework behaves as doorbell.
> >
> QCOM RPM reinvented the wheel for what mailbox framework already did,
> despite my pointing it out =>
> http://lkml.iu.edu/hypermail//linux/kernel/1406.2/03918.html
> 

The RPM interface works by writing various information in shared DRAM
and then invoking an interrupt on the remote processor. What this patch
does is introduce an abstraction for the invocation of that interrupt.

My argumentation against using the mailbox framework for the RPM case
was that the message model is a software construct and doesn't fit the
mailbox framework.


But the single step of invoking the remote interrupt is essentially a
non-message mailbox. Perhaps this part of the RPM driver is what you're
referring to in your comments on the RPM.

Before "inventing" the function for acquiring a handle to a doorbell I
did look at making this a mailbox controller, but as each mailbox
channel related to a single bit and 1 is the only value we'll ever write
it didn't feel like it matches the mailbox expectations. But as you seem
to object I'll attempt to rewrite it using the mailbox framework
instead.


But which one of these would be appropriate for a "mailbox channel" that
doesn't have any actual messages?

  mbox_send_message(chan, NULL)
or 
  const int one = 1;
  mbox_send_message(chan, (void*));

> The driver bypassed mailbox framework and was pushed via another tree.
> Same is being attempted now, only now it is more expensive to switch
> to generic mailbox framework having spent so much time on QCOM
> specific implementation of controller and protocol drivers inside
> drivers/soc/qcom/

I'm not sure I follow this, there's no extensive rework going on here -
all I'm trying to do is abstract the "writel(BIT(x), ipc_reg)" line of
the RPM driver, because it's being used in other clients as well.

Regards,
Bjorn

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

[Daniel Vetter]

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 Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
>>> >>> +panel/bridge reviewers.
>>> >>>
>>> >>> This does make things much cleaner, but it seems a bit strange to
>>> >>> create a drm_bridge when there isn't really a HW bridge in the display
>>> >>> chain (i.e, when the DSI encoder is directly connected to a DSI panel).
>>> >>>
>>> >>> There are kms drivers that use drm_panel, but don't have simple stub
>>> >>> connectors that wrap around a drm_panel. They have more complicated
>>> >>> connector ops, and may call drm_panel_prepare() and related functions
>>> >>> a bit differently. We won't be able to use drm_panel_bridge for those
>>> >>> drivers.
>>> >>>
>>> >>> For msm, we check whether the DSI encoder is connected directly to a
>>> >>> panel or an external bridge. If it's connected to an external bridge,
>>> >>> we skip the creation of the stub connector, and rely on the external
>>> >>> bridge driver to create the connector:
>>> >>>
>>> >>> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L22
>>> >>> 7
>>> >>>
>>> >>> The msm solution isn't very neat, but it avoids the need to create
>>> >>> another bridge to glue things together.
>>> >>
>>> >> Since I suggested this, yes I like it. And I think just unconditionally
>>> >> creating the panel bridge is probably even simpler, after all bridges
>>> >> are supposed to be chainable. I guess there's always going to be drivers
>>> >> where we need special handling, but I'm kinda hoping that for most cases
>>> >> simply plugging in a panel bridge is all that's need to glue drm_panel
>>> >> support into a driver. The simple pipe helpers do support bridges, and
>>> >> part of the goal there very much was to make it easy to glue in panel
>>> >> drivers.
>>> >
>>> > As I've just explained in another reply, I don't see the point in doing
>>> > this when we can instead refactor the bridge and panel operations to
>>> > expose a common base object that will then be easy to handle in core
>>> > code. This isn't just for panels, as connectors should have DT nodes, it
>>> > makes sense to instantiate an object for them that can be handled by the
>>> > DRM core, without having to push connector handling in all bridge
>>> > drivers.
>>>
>>> Imo you're aiming too high. We have 21 bridge drivers and 11 panel
>>> drivers. Asking someone to refactor them all (plus all the callers and
>>> everything) means it won't happen. At least I personally will definitely
>>> not block a contribution on this happening, that's a totally outsized
>>> demand.
>>
>> I think you're aiming too low. When the atomic update API was introduced I
>> could have told you that converting all drivers was an impossible task ;-)

We still have non-atomic drivers. We will have non-atomic drivers for
a _very_ long time. Heck, we still have non-kms drivers in drm. And
especially with atomic we've started out with some helpers to glue the
new world into the old one, not by refactoring existing interfaces.
That's somewhat starting to happen now, 2 years and 20+ drivers later.
You've just proven my point I think :-)

>> Jokes aside, I believe it might be possible to implement something simple. 
>> I'm
>> flexible about the naming, so instead of creating a new base structure and
>> refactor drm_bridge and drm_panel to embed it, we could as a first step use
>> drm_bridge as that base structure. We would only need to embed a drm_bridge
>> instance in drm_panel and add a few connector-related operations to the 
>> bridge
>> ops structure. As existing bridge drivers wouldn't need to provide those new
>> ops, they wouldn't need to be touched.
>
> I think drm_bridge itself should be the base structure, as it is today.
> It's got the entrypoints we want, connected in at the right level in the
> modeset chain.  You could call it the "drm_display_chain_link" or
> something, but "bridge" is short and I don't think renaming is worth the
> trouble.  This helper just makes it easy to make one of these display
> chain links for the endpoint of your display chain when it's a
> drm_panel.
>
> One of the followons I'd like to see after this is to make a helper that
> drivers get to use that does the "grab a bridge?  no?  grab a panel?
> Ok? wrap it in a bridge" pattern.  Then the drm_panel/drm_connector are
> an implementation detail of whatever is at the end of the chain, and not
> something that the middle of the chain needs to know about.
>
> The alternative to that that I see would be to have panel drivers call
> this code to advertise themselves through the list of bridges.

Yeah, I do believe that Eric's series here is actual the right (first,
among a 

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

[Daniel Vetter]

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 Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
>>> >>> +panel/bridge reviewers.
>>> >>>
>>> >>> This does make things much cleaner, but it seems a bit strange to
>>> >>> create a drm_bridge when there isn't really a HW bridge in the display
>>> >>> chain (i.e, when the DSI encoder is directly connected to a DSI panel).
>>> >>>
>>> >>> There are kms drivers that use drm_panel, but don't have simple stub
>>> >>> connectors that wrap around a drm_panel. They have more complicated
>>> >>> connector ops, and may call drm_panel_prepare() and related functions
>>> >>> a bit differently. We won't be able to use drm_panel_bridge for those
>>> >>> drivers.
>>> >>>
>>> >>> For msm, we check whether the DSI encoder is connected directly to a
>>> >>> panel or an external bridge. If it's connected to an external bridge,
>>> >>> we skip the creation of the stub connector, and rely on the external
>>> >>> bridge driver to create the connector:
>>> >>>
>>> >>> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L22
>>> >>> 7
>>> >>>
>>> >>> The msm solution isn't very neat, but it avoids the need to create
>>> >>> another bridge to glue things together.
>>> >>
>>> >> Since I suggested this, yes I like it. And I think just unconditionally
>>> >> creating the panel bridge is probably even simpler, after all bridges
>>> >> are supposed to be chainable. I guess there's always going to be drivers
>>> >> where we need special handling, but I'm kinda hoping that for most cases
>>> >> simply plugging in a panel bridge is all that's need to glue drm_panel
>>> >> support into a driver. The simple pipe helpers do support bridges, and
>>> >> part of the goal there very much was to make it easy to glue in panel
>>> >> drivers.
>>> >
>>> > As I've just explained in another reply, I don't see the point in doing
>>> > this when we can instead refactor the bridge and panel operations to
>>> > expose a common base object that will then be easy to handle in core
>>> > code. This isn't just for panels, as connectors should have DT nodes, it
>>> > makes sense to instantiate an object for them that can be handled by the
>>> > DRM core, without having to push connector handling in all bridge
>>> > drivers.
>>>
>>> Imo you're aiming too high. We have 21 bridge drivers and 11 panel
>>> drivers. Asking someone to refactor them all (plus all the callers and
>>> everything) means it won't happen. At least I personally will definitely
>>> not block a contribution on this happening, that's a totally outsized
>>> demand.
>>
>> I think you're aiming too low. When the atomic update API was introduced I
>> could have told you that converting all drivers was an impossible task ;-)

We still have non-atomic drivers. We will have non-atomic drivers for
a _very_ long time. Heck, we still have non-kms drivers in drm. And
especially with atomic we've started out with some helpers to glue the
new world into the old one, not by refactoring existing interfaces.
That's somewhat starting to happen now, 2 years and 20+ drivers later.
You've just proven my point I think :-)

>> Jokes aside, I believe it might be possible to implement something simple. 
>> I'm
>> flexible about the naming, so instead of creating a new base structure and
>> refactor drm_bridge and drm_panel to embed it, we could as a first step use
>> drm_bridge as that base structure. We would only need to embed a drm_bridge
>> instance in drm_panel and add a few connector-related operations to the 
>> bridge
>> ops structure. As existing bridge drivers wouldn't need to provide those new
>> ops, they wouldn't need to be touched.
>
> I think drm_bridge itself should be the base structure, as it is today.
> It's got the entrypoints we want, connected in at the right level in the
> modeset chain.  You could call it the "drm_display_chain_link" or
> something, but "bridge" is short and I don't think renaming is worth the
> trouble.  This helper just makes it easy to make one of these display
> chain links for the endpoint of your display chain when it's a
> drm_panel.
>
> One of the followons I'd like to see after this is to make a helper that
> drivers get to use that does the "grab a bridge?  no?  grab a panel?
> Ok? wrap it in a bridge" pattern.  Then the drm_panel/drm_connector are
> an implementation detail of whatever is at the end of the chain, and not
> something that the middle of the chain needs to know about.
>
> The alternative to that that I see would be to have panel drivers call
> this code to advertise themselves through the list of bridges.

Yeah, I do believe that Eric's series here is actual the right (first,
among a lot more) steps into the direction of unifying 

Re: [GIT PULL] locking fixes

[Peter Zijlstra]

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):
> >   locking/refcounts: Out-of-line everything
> 
> This one is all good generally, but it has one really stupid side
> effect: it makes refcounting GPL-only.
> 
> That's just silly. These are functions that atomically add and
> subtract one. The only thing that making them GPL-only can possibly do
> is to make people hack around it, and lose the overflow handling
> debugging in the process.

These people are out-of-tree dubious licensed modules, right? I really
_really_ don't care about those.

> It also breaks any kref uses. Which is what drivers etc are supposed to use.

Greg KH had this to say:

"As all of the previous kref functions were in a GPL-only header file,
and included directly that way, they were already GPL-only symbols, so
there really was no change here except now the linker checks them.  If
you have questions about using inline GPL-only functions from a .h file,
in a non-GPL codebase, please consult your corporate lawyer to get
clarification."

 https://lkml.kernel.org/r/20170308094810.gb30...@kroah.com

> So that "move from inline to out-of-line" had a big subtle semantic
> change that was probably not intentional, and certainly not
> documented.

I'll take the not documented bit.

Re: [GIT PULL] locking fixes

[Peter Zijlstra]

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):
> >   locking/refcounts: Out-of-line everything
> 
> This one is all good generally, but it has one really stupid side
> effect: it makes refcounting GPL-only.
> 
> That's just silly. These are functions that atomically add and
> subtract one. The only thing that making them GPL-only can possibly do
> is to make people hack around it, and lose the overflow handling
> debugging in the process.

These people are out-of-tree dubious licensed modules, right? I really
_really_ don't care about those.

> It also breaks any kref uses. Which is what drivers etc are supposed to use.

Greg KH had this to say:

"As all of the previous kref functions were in a GPL-only header file,
and included directly that way, they were already GPL-only symbols, so
there really was no change here except now the linker checks them.  If
you have questions about using inline GPL-only functions from a .h file,
in a non-GPL codebase, please consult your corporate lawyer to get
clarification."

 https://lkml.kernel.org/r/20170308094810.gb30...@kroah.com

> So that "move from inline to out-of-line" had a big subtle semantic
> change that was probably not intentional, and certainly not
> documented.

I'll take the not documented bit.

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

[Javier Martinez Canillas]

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.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt

diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt 
b/Documentation/devicetree/bindings/mfd/tps6105x.txt
new file mode 100644
index ..93602c7a19c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for TI TPS61050/61052 Boost Converters
+
+The TP61050/TPS61052 is a high-power "white LED driver". The
+device provides LED, GPIO and regulator functionalities.
+
+Required properties:
+- compatible:  "ti,tps61050" or "ti,tps61052"
+- reg: Specifies the I2C slave address
+
+Example:
+
+i2c0 {
+   tps61052@33 {
+   compatible = "ti,tps61052";
+   reg = <0x33>;
+   };
+};
-- 
2.9.3

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

[Javier Martinez Canillas]

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.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt

diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt 
b/Documentation/devicetree/bindings/mfd/tps6105x.txt
new file mode 100644
index ..93602c7a19c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
@@ -0,0 +1,17 @@
+* Device tree bindings for TI TPS61050/61052 Boost Converters
+
+The TP61050/TPS61052 is a high-power "white LED driver". The
+device provides LED, GPIO and regulator functionalities.
+
+Required properties:
+- compatible:  "ti,tps61050" or "ti,tps61052"
+- reg: Specifies the I2C slave address
+
+Example:
+
+i2c0 {
+   tps61052@33 {
+   compatible = "ti,tps61052";
+   reg = <0x33>;
+   };
+};
-- 
2.9.3

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

[Javier Martinez Canillas]

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 change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Rob Herring 
Acked-by: Tony Lindgren 
Acked-by: Lee Jones 

---

Changes in v6: None
Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.

Changes in v4: None
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).

Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.

 drivers/mfd/tps6105x.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
index baa12ea666fb..187848c93779 100644
--- a/drivers/mfd/tps6105x.c
+++ b/drivers/mfd/tps6105x.c
@@ -173,9 +173,17 @@ static const struct i2c_device_id tps6105x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tps6105x_id);
 
+static const struct of_device_id tps6105x_of_match[] = {
+   { .compatible = "ti,tps61050" },
+   { .compatible = "ti,tps61052" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, tps6105x_of_match);
+
 static struct i2c_driver tps6105x_driver = {
.driver = {
.name   = "tps6105x",
+   .of_match_table = tps6105x_of_match,
},
.probe  = tps6105x_probe,
.remove = tps6105x_remove,
-- 
2.9.3

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

[Javier Martinez Canillas]

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 's Acked-by tag.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/ste-hrefprev60.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ste-hrefprev60.dtsi 
b/arch/arm/boot/dts/ste-hrefprev60.dtsi
index 5882a2606ac3..3f14b4df69b4 100644
--- a/arch/arm/boot/dts/ste-hrefprev60.dtsi
+++ b/arch/arm/boot/dts/ste-hrefprev60.dtsi
@@ -30,7 +30,7 @@
 
i2c@80004000 {
tps61052@33 {
-   compatible = "tps61052";
+   compatible = "ti,tps61052";
reg = <0x33>;
};
 
-- 
2.9.3

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

[Javier Martinez Canillas]

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 change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Rob Herring 
Acked-by: Tony Lindgren 
Acked-by: Lee Jones 

---

Changes in v6: None
Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.

Changes in v4: None
Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).

Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.

 drivers/mfd/tps6105x.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
index baa12ea666fb..187848c93779 100644
--- a/drivers/mfd/tps6105x.c
+++ b/drivers/mfd/tps6105x.c
@@ -173,9 +173,17 @@ static const struct i2c_device_id tps6105x_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, tps6105x_id);
 
+static const struct of_device_id tps6105x_of_match[] = {
+   { .compatible = "ti,tps61050" },
+   { .compatible = "ti,tps61052" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, tps6105x_of_match);
+
 static struct i2c_driver tps6105x_driver = {
.driver = {
.name   = "tps6105x",
+   .of_match_table = tps6105x_of_match,
},
.probe  = tps6105x_probe,
.remove = tps6105x_remove,
-- 
2.9.3

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

[Javier Martinez Canillas]

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 's Acked-by tag.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/ste-hrefprev60.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ste-hrefprev60.dtsi 
b/arch/arm/boot/dts/ste-hrefprev60.dtsi
index 5882a2606ac3..3f14b4df69b4 100644
--- a/arch/arm/boot/dts/ste-hrefprev60.dtsi
+++ b/arch/arm/boot/dts/ste-hrefprev60.dtsi
@@ -30,7 +30,7 @@
 
i2c@80004000 {
tps61052@33 {
-   compatible = "tps61052";
+   compatible = "ti,tps61052";
reg = <0x33>;
};
 
-- 
2.9.3

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

[Javier Martinez Canillas]

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.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 1b06430c8013..91886231e5a8 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -16,7 +16,7 @@
#address-cells = <1>;
#size-cells = <0>;
retu: retu@1 {
-   compatible = "retu";
+   compatible = "nokia,retu";
interrupt-parent = <>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
-- 
2.9.3

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

[Javier Martinez Canillas]

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:
- Mention CBUS address instead of I2C since that's the bus used (Wolfram Sang).
- Add a "i2c-cbus-gpio" comptible and use cbus0 for parent node (Wolfram Sang).

Changes in v5:
- Add missing properties for interrupts to DT binding doc (Rob Herring).
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.

Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/mfd/retu.txt | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt

diff --git a/Documentation/devicetree/bindings/mfd/retu.txt 
b/Documentation/devicetree/bindings/mfd/retu.txt
new file mode 100644
index ..876242394a16
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/retu.txt
@@ -0,0 +1,25 @@
+* Device tree bindings for Nokia Retu and Tahvo multi-function device
+
+Retu and Tahvo are a multi-function devices found on Nokia Internet
+Tablets (770, N800 and N810). The Retu chip provides watchdog timer
+and power button control functionalities while Tahvo chip provides
+USB transceiver functionality.
+
+Required properties:
+- compatible:  "nokia,retu" or "nokia,tahvo"
+- reg: Specifies the CBUS slave address of the ASIC chip
+- interrupts:  The interrupt line the device is connected to
+- interrupt-parent:The parent interrupt controller
+
+Example:
+
+cbus0 {
+   compatible = "i2c-cbus-gpio";
+   ...
+   retu: retu@1 {
+   compatible = "nokia,retu";
+   interrupt-parent = <>;
+   interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+   reg = <0x1>;
+   };
+};
-- 
2.9.3

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

[Javier Martinez Canillas]

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 
Reviewed-by: Wolfram Sang 

---

Changes in v6:
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4:
- Avoid using MFD in Device Tree (Lee Jones).

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt 
b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
index 8ce9cd2855b5..c143948b2a37 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
@@ -20,8 +20,8 @@ i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
 
-   retu-mfd: retu@1 {
-   compatible = "retu-mfd";
+   retu: retu@1 {
+   compatible = "nokia,retu";
reg = <0x1>;
};
 };
-- 
2.9.3

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

[Javier Martinez Canillas]

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:
- Mention CBUS address instead of I2C since that's the bus used (Wolfram Sang).
- Add a "i2c-cbus-gpio" comptible and use cbus0 for parent node (Wolfram Sang).

Changes in v5:
- Add missing properties for interrupts to DT binding doc (Rob Herring).
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.

Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/mfd/retu.txt | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt

diff --git a/Documentation/devicetree/bindings/mfd/retu.txt 
b/Documentation/devicetree/bindings/mfd/retu.txt
new file mode 100644
index ..876242394a16
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/retu.txt
@@ -0,0 +1,25 @@
+* Device tree bindings for Nokia Retu and Tahvo multi-function device
+
+Retu and Tahvo are a multi-function devices found on Nokia Internet
+Tablets (770, N800 and N810). The Retu chip provides watchdog timer
+and power button control functionalities while Tahvo chip provides
+USB transceiver functionality.
+
+Required properties:
+- compatible:  "nokia,retu" or "nokia,tahvo"
+- reg: Specifies the CBUS slave address of the ASIC chip
+- interrupts:  The interrupt line the device is connected to
+- interrupt-parent:The parent interrupt controller
+
+Example:
+
+cbus0 {
+   compatible = "i2c-cbus-gpio";
+   ...
+   retu: retu@1 {
+   compatible = "nokia,retu";
+   interrupt-parent = <>;
+   interrupts = <12 IRQ_TYPE_EDGE_RISING>;
+   reg = <0x1>;
+   };
+};
-- 
2.9.3

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

[Javier Martinez Canillas]

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 
Reviewed-by: Wolfram Sang 

---

Changes in v6:
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4:
- Avoid using MFD in Device Tree (Lee Jones).

Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt 
b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
index 8ce9cd2855b5..c143948b2a37 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
@@ -20,8 +20,8 @@ i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
 
-   retu-mfd: retu@1 {
-   compatible = "retu-mfd";
+   retu: retu@1 {
+   compatible = "nokia,retu";
reg = <0x1>;
};
 };
-- 
2.9.3

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

[Javier Martinez Canillas]

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.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 1b06430c8013..91886231e5a8 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -16,7 +16,7 @@
#address-cells = <1>;
#size-cells = <0>;
retu: retu@1 {
-   compatible = "retu";
+   compatible = "nokia,retu";
interrupt-parent = <>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
-- 
2.9.3

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

[Javier Martinez Canillas]

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 change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Rob Herring 
Acked-by: Aaro Koskinen 
Acked-by: Tony Lindgren 
Acked-by: Lee Jones 
Reviewed-by: Wolfram Sang 

---

Changes in v6:
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.

Changes in v4:
- Drop -mfd suffix in compatible string (Lee Jones).

Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).

Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.

 drivers/mfd/retu-mfd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 53e1d386d2c0..e7d27b7861c1 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -308,9 +308,17 @@ static const struct i2c_device_id retu_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, retu_id);
 
+static const struct of_device_id retu_of_match[] = {
+   { .compatible = "nokia,retu" },
+   { .compatible = "nokia,tahvo" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, retu_of_match);
+
 static struct i2c_driver retu_driver = {
.driver = {
.name = "retu-mfd",
+   .of_match_table = retu_of_match,
},
.probe  = retu_probe,
.remove = retu_remove,
-- 
2.9.3

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

[Javier Martinez Canillas]

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 
Acked-by: Tony Lindgren 
Reviewed-by: Wolfram Sang 

---

Changes in v6:
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Tony Lindgren's Acked-by tag.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
 arch/arm/mach-omap1/board-nokia770.c| 4 ++--
 drivers/mfd/retu-mfd.c  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 7e5ffc583c90..1b06430c8013 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -15,8 +15,8 @@
>;
#address-cells = <1>;
#size-cells = <0>;
-   retu_mfd: retu@1 {
-   compatible = "retu-mfd";
+   retu: retu@1 {
+   compatible = "retu";
interrupt-parent = <>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index ee8d9f553db4..06243c0b12d2 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -233,10 +233,10 @@ static struct platform_device nokia770_cbus_device = {
 
 static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
{
-   I2C_BOARD_INFO("retu-mfd", 0x01),
+   I2C_BOARD_INFO("retu", 0x01),
},
{
-   I2C_BOARD_INFO("tahvo-mfd", 0x02),
+   I2C_BOARD_INFO("tahvo", 0x02),
},
 };
 
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index d4c114abeb75..53e1d386d2c0 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -302,8 +302,8 @@ static int retu_remove(struct i2c_client *i2c)
 }
 
 static const struct i2c_device_id retu_id[] = {
-   { "retu-mfd", 0 },
-   { "tahvo-mfd", 0 },
+   { "retu", 0 },
+   { "tahvo", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, retu_id);
-- 
2.9.3

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

[Javier Martinez Canillas]

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 change in the future so the correct approach is to have a
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Rob Herring 
Acked-by: Aaro Koskinen 
Acked-by: Tony Lindgren 
Acked-by: Lee Jones 
Reviewed-by: Wolfram Sang 

---

Changes in v6:
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.

Changes in v4:
- Drop -mfd suffix in compatible string (Lee Jones).

Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).

Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.

 drivers/mfd/retu-mfd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 53e1d386d2c0..e7d27b7861c1 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -308,9 +308,17 @@ static const struct i2c_device_id retu_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, retu_id);
 
+static const struct of_device_id retu_of_match[] = {
+   { .compatible = "nokia,retu" },
+   { .compatible = "nokia,tahvo" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, retu_of_match);
+
 static struct i2c_driver retu_driver = {
.driver = {
.name = "retu-mfd",
+   .of_match_table = retu_of_match,
},
.probe  = retu_probe,
.remove = retu_remove,
-- 
2.9.3

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

[Javier Martinez Canillas]

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 
Acked-by: Tony Lindgren 
Reviewed-by: Wolfram Sang 

---

Changes in v6:
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Tony Lindgren's Acked-by tag.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
 arch/arm/mach-omap1/board-nokia770.c| 4 ++--
 drivers/mfd/retu-mfd.c  | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 7e5ffc583c90..1b06430c8013 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -15,8 +15,8 @@
>;
#address-cells = <1>;
#size-cells = <0>;
-   retu_mfd: retu@1 {
-   compatible = "retu-mfd";
+   retu: retu@1 {
+   compatible = "retu";
interrupt-parent = <>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
reg = <0x1>;
diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index ee8d9f553db4..06243c0b12d2 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -233,10 +233,10 @@ static struct platform_device nokia770_cbus_device = {
 
 static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
{
-   I2C_BOARD_INFO("retu-mfd", 0x01),
+   I2C_BOARD_INFO("retu", 0x01),
},
{
-   I2C_BOARD_INFO("tahvo-mfd", 0x02),
+   I2C_BOARD_INFO("tahvo", 0x02),
},
 };
 
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index d4c114abeb75..53e1d386d2c0 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -302,8 +302,8 @@ static int retu_remove(struct i2c_client *i2c)
 }
 
 static const struct i2c_device_id retu_id[] = {
-   { "retu-mfd", 0 },
-   { "tahvo-mfd", 0 },
+   { "retu", 0 },
+   { "tahvo", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, retu_id);
-- 
2.9.3

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

[Javier Martinez Canillas]

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 MODALIAS=i2c: regardless if
a device was registered via DT or using the legacy platform data mechanism.

So these patches will make sure that mfd I2C drivers modules will continue
to be autoloaded once the I2C core is changed to report proper OF modalias.

Users didn't have a vendor prefix in the used compatible strings, but since
there wasn't a DT binding document for these drivers, it can be said that
were working for mere luck and so this series fixes the users and add a DT
binding doc for the drivers.

Most patches can be applied independently, with the exception of patches
2 to 4 that should be applied in the same tree to keep bisect-ability. I
suggest these to go through the MFD subsystem tree.

Best regards,
Javier

Changes in v6:
- Mention CBUS address instead of I2C since that's the bus used (Wolfram Sang).
- Add a "i2c-cbus-gpio" comptible and use cbus0 for parent node (Wolfram Sang).
- Add Wolfram Sang's Reviewed-by tag.
- Add Wolfram Sang's Reviewed-by tag.
- Add Wolfram Sang's Reviewed-by tag.
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add missing properties for interrupts to DT binding doc (Rob Herring).
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Tony Lindgren's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Drop -mfd suffix in compatible string (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).

Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
- Add a vendor prefix to the compatible string (Rob Herring).

Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.

Javier Martinez Canillas (8):
  dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
  mfd: retu: Drop -mfd suffix from I2C device ID name
  mfd: retu: Add OF device ID table
  ARM: dts: n8x0: Add vendor prefix to retu node
  i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
  dt-bindings: mfd: Add TI tps6105x chip bindings
  mfd: tps6105x: Add OF device ID table
  ARM: ux500: Add vendor prefix to tps61052 node

 .../devicetree/bindings/i2c/i2c-cbus-gpio.txt  |  4 ++--
 Documentation/devicetree/bindings/mfd/retu.txt | 25 ++
 Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +++
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi|  4 ++--
 arch/arm/boot/dts/ste-hrefprev60.dtsi  |  2 +-
 arch/arm/mach-omap1/board-nokia770.c   |  4 ++--
 drivers/mfd/retu-mfd.c | 12 +--
 drivers/mfd/tps6105x.c |  8 +++
 8 files changed, 67 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt

-- 
2.9.3

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

[Javier Martinez Canillas]

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 MODALIAS=i2c: regardless if
a device was registered via DT or using the legacy platform data mechanism.

So these patches will make sure that mfd I2C drivers modules will continue
to be autoloaded once the I2C core is changed to report proper OF modalias.

Users didn't have a vendor prefix in the used compatible strings, but since
there wasn't a DT binding document for these drivers, it can be said that
were working for mere luck and so this series fixes the users and add a DT
binding doc for the drivers.

Most patches can be applied independently, with the exception of patches
2 to 4 that should be applied in the same tree to keep bisect-ability. I
suggest these to go through the MFD subsystem tree.

Best regards,
Javier

Changes in v6:
- Mention CBUS address instead of I2C since that's the bus used (Wolfram Sang).
- Add a "i2c-cbus-gpio" comptible and use cbus0 for parent node (Wolfram Sang).
- Add Wolfram Sang's Reviewed-by tag.
- Add Wolfram Sang's Reviewed-by tag.
- Add Wolfram Sang's Reviewed-by tag.
- Add Wolfram Sang's Reviewed-by tag.

Changes in v5:
- Add missing properties for interrupts to DT binding doc (Rob Herring).
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Tony Lindgren's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Aaro Koskinen's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.
- Add Lee Jones 's Acked-by tag.
- Add Rob Herring's Acked-by tag.
- Add Acked-by: Tony Lindgren 's Acked-by tag.

Changes in v4:
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Drop -mfd suffix in compatible string (Lee Jones).
- Avoid using MFD in Device Tree (Lee Jones).
- Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
- Add information about what functions the device serve (Lee Jones).

Changes in v3:
- Add a vendor prefix to the compatible string (Rob Herring).
- Add a vendor prefix to the compatible string (Rob Herring).

Changes in v2:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.

Javier Martinez Canillas (8):
  dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
  mfd: retu: Drop -mfd suffix from I2C device ID name
  mfd: retu: Add OF device ID table
  ARM: dts: n8x0: Add vendor prefix to retu node
  i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
  dt-bindings: mfd: Add TI tps6105x chip bindings
  mfd: tps6105x: Add OF device ID table
  ARM: ux500: Add vendor prefix to tps61052 node

 .../devicetree/bindings/i2c/i2c-cbus-gpio.txt  |  4 ++--
 Documentation/devicetree/bindings/mfd/retu.txt | 25 ++
 Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +++
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi|  4 ++--
 arch/arm/boot/dts/ste-hrefprev60.dtsi  |  2 +-
 arch/arm/mach-omap1/board-nokia770.c   |  4 ++--
 drivers/mfd/retu-mfd.c | 12 +--
 drivers/mfd/tps6105x.c |  8 +++
 8 files changed, 67 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt

-- 
2.9.3

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

[Karim Eshapa]

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 the big loop delay.

Signed-off-by: Karim Eshapa 
---
 drivers/soc/fsl/qbman/qman.c | 47 ++--
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 6f509f6..4f99298 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1067,32 +1067,33 @@ static irqreturn_t portal_isr(int irq, void *ptr)
 static int drain_mr_fqrni(struct qm_portal *p)
 {
const union qm_mr_entry *msg;
+   unsigned long stop;
+   unsigned int timeout = jiffies_to_msecs(1000);
 loop:
msg = qm_mr_current(p);
-   if (!msg) {
-   /*
-* if MR was full and h/w had other FQRNI entries to produce, we
-* need to allow it time to produce those entries once the
-* existing entries are consumed. A worst-case situation
-* (fully-loaded system) means h/w sequencers may have to do 3-4
-* other things before servicing the portal's MR pump, each of
-* which (if slow) may take ~50 qman cycles (which is ~200
-* processor cycles). So rounding up and then multiplying this
-* worst-case estimate by a factor of 10, just to be
-* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
-* one entry at a time, so h/w has an opportunity to produce new
-* entries well before the ring has been fully consumed, so
-* we're being *really* paranoid here.
-*/
-   u64 now, then = jiffies;
-
-   do {
-   now = jiffies;
-   } while ((then + 1) > now);
+   stop = jiffies + 1;
+   /*
+* if MR was full and h/w had other FQRNI entries to produce, we
+* need to allow it time to produce those entries once the
+* existing entries are consumed. A worst-case situation
+* (fully-loaded system) means h/w sequencers may have to do 3-4
+* other things before servicing the portal's MR pump, each of
+* which (if slow) may take ~50 qman cycles (which is ~200
+* processor cycles). So rounding up and then multiplying this
+* worst-case estimate by a factor of 10, just to be
+* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
+* one entry at a time, so h/w has an opportunity to produce new
+* entries well before the ring has been fully consumed, so
+* we're being *really* paranoid here.
+*/
+   do {
+   if (msg)
+   break;
+   msleep(timeout);
msg = qm_mr_current(p);
-   if (!msg)
-   return 0;
-   }
+   } while (time_before(jiffies, stop));
+   if (!msg)
+   return 0;
if ((msg->verb & QM_MR_VERB_TYPE_MASK) != QM_MR_VERB_FQRNI) {
/* We aren't draining anything but FQRNIs */
pr_err("Found verb 0x%x in MR\n", msg->verb);
-- 
2.7.4

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

[Karim Eshapa]

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 the big loop delay.

Signed-off-by: Karim Eshapa 
---
 drivers/soc/fsl/qbman/qman.c | 47 ++--
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 6f509f6..4f99298 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1067,32 +1067,33 @@ static irqreturn_t portal_isr(int irq, void *ptr)
 static int drain_mr_fqrni(struct qm_portal *p)
 {
const union qm_mr_entry *msg;
+   unsigned long stop;
+   unsigned int timeout = jiffies_to_msecs(1000);
 loop:
msg = qm_mr_current(p);
-   if (!msg) {
-   /*
-* if MR was full and h/w had other FQRNI entries to produce, we
-* need to allow it time to produce those entries once the
-* existing entries are consumed. A worst-case situation
-* (fully-loaded system) means h/w sequencers may have to do 3-4
-* other things before servicing the portal's MR pump, each of
-* which (if slow) may take ~50 qman cycles (which is ~200
-* processor cycles). So rounding up and then multiplying this
-* worst-case estimate by a factor of 10, just to be
-* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
-* one entry at a time, so h/w has an opportunity to produce new
-* entries well before the ring has been fully consumed, so
-* we're being *really* paranoid here.
-*/
-   u64 now, then = jiffies;
-
-   do {
-   now = jiffies;
-   } while ((then + 1) > now);
+   stop = jiffies + 1;
+   /*
+* if MR was full and h/w had other FQRNI entries to produce, we
+* need to allow it time to produce those entries once the
+* existing entries are consumed. A worst-case situation
+* (fully-loaded system) means h/w sequencers may have to do 3-4
+* other things before servicing the portal's MR pump, each of
+* which (if slow) may take ~50 qman cycles (which is ~200
+* processor cycles). So rounding up and then multiplying this
+* worst-case estimate by a factor of 10, just to be
+* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
+* one entry at a time, so h/w has an opportunity to produce new
+* entries well before the ring has been fully consumed, so
+* we're being *really* paranoid here.
+*/
+   do {
+   if (msg)
+   break;
+   msleep(timeout);
msg = qm_mr_current(p);
-   if (!msg)
-   return 0;
-   }
+   } while (time_before(jiffies, stop));
+   if (!msg)
+   return 0;
if ((msg->verb & QM_MR_VERB_TYPE_MASK) != QM_MR_VERB_FQRNI) {
/* We aren't draining anything but FQRNIs */
pr_err("Found verb 0x%x in MR\n", msg->verb);
-- 
2.7.4

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

[Ye Xiaolong]

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")
>> 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 -smp 2 -m 1G
>> 
>> caused below changes (please refer to attached dmesg/kmsg for entire 
>> log/backtrace):
>
>This is expected behavior.  When you build rcuperf into the kernel (as
>was the case here with CONFIG_RCU_PERF_TEST=y), it runs the test and
>then shuts down the kernel.  The test only takes less than a minute,
>so this will look like a boot failure.  (I run it from some scripts
>that expect the shutdown and collect performance data either from
>dmesg or from event tracing, so this auto-shutdown feature is indeed
>a feature rather than a bug.)
>
>There are several ways to avoid this:
>
>1. Exclude CONFIG_RCU_PERF_TEST=y from your testing.  In other words,
>   build with either CONFIG_RCU_PERF_TEST=n or CONFIG_RCU_PERF_TEST=m,
>   thus avoiding the auto-shutdown functionality.
>
>2. If you want to run CONFIG_RCU_PERF_TEST=y anyway, then boot such
>   kernels with rcuperf.shutdown=0 to override the auto-shutdown
>   default.
>
>3. As in #2, but instead boot with rcuperf.holdoff=7200 (assuming that
>   your tests run for less than two hours).

Thanks for the detailed explanation.

Thanks,
Xiaolong
>
>There are probably some other approaches, so please let me know if none of
>the above work for you.
>
>   Thanx, Paul
>
>> +--+++
>> |
>>   | 7984237c13 | 87c458e630 |
>> +--+++
>> | boot_successes 
>>   | 0  | 6  |
>> | boot_failures  
>>   | 30 | 24 |
>> | invoked_oom-killer:gfp_mask=0x 
>>   | 30 ||
>> | Mem-Info   
>>   | 30 ||
>> | Out_of_memory:Kill_process 
>>   | 30 ||
>> | 
>> page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY),nodemask=(null)
>>  | 7  ||
>> | BUG:kernel_hang_in_test_stage  
>>   | 0  | 18 |
>> | WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule   
>>   | 0  | 14 |
>> +--+++
>> 
>> 
>> 
>> [   15.553978] WARNING: CPU: 0 PID: 9 at arch/x86/kernel/smp.c:127 
>> native_smp_send_reschedule+0x4f/0x68
>> [   15.556230] Modules linked in:
>> [   15.556868] CPU: 0 PID: 9 Comm: migration/0 Not tainted 
>> 4.11.0-rc2-00091-g87c458e #1
>> [   15.558408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>> 1.9.3-20161025_171302-gandalf 04/01/2014
>> [   15.560409] Call Trace:
>> [   15.560937]  dump_stack+0x61/0x7e
>> [   15.561604]  __warn+0xc2/0xdd
>> [   15.562219]  warn_slowpath_null+0x1d/0x1f
>> [   15.563027]  native_smp_send_reschedule+0x4f/0x68
>> [   15.564061]  resched_curr+0x9e/0x168
>> [   15.564792]  check_preempt_curr+0x4a/0x92
>> [   15.565592]  move_queued_task+0x1cc/0x1d6
>> [   15.566415]  __migrate_task+0x88/0x97
>> [   15.567158]  migration_cpu_stop+0x77/0xa4
>> [   15.567968]  ? sched_ttwu_pending+0xbd/0xbd
>> [   15.568815]  cpu_stopper_thread+0x84/0xf3
>> [   15.569613]  ? sort_range+0x22/0x22
>> [   15.570326]  smpboot_thread_fn+0x1cc/0x1e3
>> [   15.571164]  kthread+0x12d/0x135
>> [   15.571825]  ? kthread_create_on_node+0x3f/0x3f
>> [   15.572742]  ret_from_fork+0x2c/0x40
>> [   15.573468] ---[ end trace ce70cc5403b8b2a1 ]---
>> 
>> 
>> To reproduce:
>> 
>> git clone https://github.com/01org/lkp-tests.git
>> cd lkp-tests
>> bin/lkp qemu -k  job-script  # job-script is attached in 
>> this email
>> 
>> 
>> 
>> Thanks,
>> Xiaolong
>
>> #
>> # Automatically generated file; DO NOT EDIT.
>> # Linux/x86_64 4.11.0-rc2 Kernel Configuration
>> #
>> CONFIG_64BIT=y
>> CONFIG_X86_64=y
>> CONFIG_X86=y
>> CONFIG_INSTRUCTION_DECODER=y
>> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
>> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
>> CONFIG_LOCKDEP_SUPPORT=y
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_MMU=y
>> 

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

[Ye Xiaolong]

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")
>> 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 -smp 2 -m 1G
>> 
>> caused below changes (please refer to attached dmesg/kmsg for entire 
>> log/backtrace):
>
>This is expected behavior.  When you build rcuperf into the kernel (as
>was the case here with CONFIG_RCU_PERF_TEST=y), it runs the test and
>then shuts down the kernel.  The test only takes less than a minute,
>so this will look like a boot failure.  (I run it from some scripts
>that expect the shutdown and collect performance data either from
>dmesg or from event tracing, so this auto-shutdown feature is indeed
>a feature rather than a bug.)
>
>There are several ways to avoid this:
>
>1. Exclude CONFIG_RCU_PERF_TEST=y from your testing.  In other words,
>   build with either CONFIG_RCU_PERF_TEST=n or CONFIG_RCU_PERF_TEST=m,
>   thus avoiding the auto-shutdown functionality.
>
>2. If you want to run CONFIG_RCU_PERF_TEST=y anyway, then boot such
>   kernels with rcuperf.shutdown=0 to override the auto-shutdown
>   default.
>
>3. As in #2, but instead boot with rcuperf.holdoff=7200 (assuming that
>   your tests run for less than two hours).

Thanks for the detailed explanation.

Thanks,
Xiaolong
>
>There are probably some other approaches, so please let me know if none of
>the above work for you.
>
>   Thanx, Paul
>
>> +--+++
>> |
>>   | 7984237c13 | 87c458e630 |
>> +--+++
>> | boot_successes 
>>   | 0  | 6  |
>> | boot_failures  
>>   | 30 | 24 |
>> | invoked_oom-killer:gfp_mask=0x 
>>   | 30 ||
>> | Mem-Info   
>>   | 30 ||
>> | Out_of_memory:Kill_process 
>>   | 30 ||
>> | 
>> page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY),nodemask=(null)
>>  | 7  ||
>> | BUG:kernel_hang_in_test_stage  
>>   | 0  | 18 |
>> | WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule   
>>   | 0  | 14 |
>> +--+++
>> 
>> 
>> 
>> [   15.553978] WARNING: CPU: 0 PID: 9 at arch/x86/kernel/smp.c:127 
>> native_smp_send_reschedule+0x4f/0x68
>> [   15.556230] Modules linked in:
>> [   15.556868] CPU: 0 PID: 9 Comm: migration/0 Not tainted 
>> 4.11.0-rc2-00091-g87c458e #1
>> [   15.558408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>> 1.9.3-20161025_171302-gandalf 04/01/2014
>> [   15.560409] Call Trace:
>> [   15.560937]  dump_stack+0x61/0x7e
>> [   15.561604]  __warn+0xc2/0xdd
>> [   15.562219]  warn_slowpath_null+0x1d/0x1f
>> [   15.563027]  native_smp_send_reschedule+0x4f/0x68
>> [   15.564061]  resched_curr+0x9e/0x168
>> [   15.564792]  check_preempt_curr+0x4a/0x92
>> [   15.565592]  move_queued_task+0x1cc/0x1d6
>> [   15.566415]  __migrate_task+0x88/0x97
>> [   15.567158]  migration_cpu_stop+0x77/0xa4
>> [   15.567968]  ? sched_ttwu_pending+0xbd/0xbd
>> [   15.568815]  cpu_stopper_thread+0x84/0xf3
>> [   15.569613]  ? sort_range+0x22/0x22
>> [   15.570326]  smpboot_thread_fn+0x1cc/0x1e3
>> [   15.571164]  kthread+0x12d/0x135
>> [   15.571825]  ? kthread_create_on_node+0x3f/0x3f
>> [   15.572742]  ret_from_fork+0x2c/0x40
>> [   15.573468] ---[ end trace ce70cc5403b8b2a1 ]---
>> 
>> 
>> To reproduce:
>> 
>> git clone https://github.com/01org/lkp-tests.git
>> cd lkp-tests
>> bin/lkp qemu -k  job-script  # job-script is attached in 
>> this email
>> 
>> 
>> 
>> Thanks,
>> Xiaolong
>
>> #
>> # Automatically generated file; DO NOT EDIT.
>> # Linux/x86_64 4.11.0-rc2 Kernel Configuration
>> #
>> CONFIG_64BIT=y
>> CONFIG_X86_64=y
>> CONFIG_X86=y
>> CONFIG_INSTRUCTION_DECODER=y
>> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
>> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
>> CONFIG_LOCKDEP_SUPPORT=y
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_MMU=y
>> 

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

[Serge E. Hallyn]

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:
> 
>  Quoting Matt Brown (m...@nmatt.com):
> >
> > This patch adds struct user_namespace *owner_user_ns to the tty_struct.
> > Then it is set to current_user_ns() in the alloc_tty_struct function.
> >
> > This is done to facilitate capability checks against the original user
> > namespace that allocated the tty.
> >
> > E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)
> >
> > This combined with the use of user namespace's will allow hardening
> > protections to be built to mitigate container escapes that utilize TTY
> > ioctls such as TIOCSTI.
> >
> > See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256
> >
> > Signed-off-by: Matt Brown 
> 
> 
>  Acked-by: Serge Hallyn 
> >>>
> >>>
> >>> This Ack didn't end up in the v5, but I think it stands, yes?
> >>>
> >>> Greg, is the v5 okay to pull for you or would a v6 with Acks/Reviews
> >>> included be preferred?
> >>
> >>
> >> v6 would be great, and we are dropping patch 2 from the series, right?
> >> I was expecting this to be resent.  I'll start looking at new patches
> >> like this after 4.12-rc1 is out.
> >>
> >
> > I will create a v6 with the Acks/Reviews. I'd like to keep patch 2 in
> > since that got acked by at least Serge. (Kees also? or just patch 1?)
> 
> Sorry, I meant that patch 2's ack from serge got dropped accidentally.
> i.e. he Acked v4, but it wasn't in v5.
> 
> Serge, just to double-check, does your Ack stand?

Yes.

thanks,
-serge

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

[Serge E. Hallyn]

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:
> 
>  Quoting Matt Brown (m...@nmatt.com):
> >
> > This patch adds struct user_namespace *owner_user_ns to the tty_struct.
> > Then it is set to current_user_ns() in the alloc_tty_struct function.
> >
> > This is done to facilitate capability checks against the original user
> > namespace that allocated the tty.
> >
> > E.g. ns_capable(tty->owner_user_ns,CAP_SYS_ADMIN)
> >
> > This combined with the use of user namespace's will allow hardening
> > protections to be built to mitigate container escapes that utilize TTY
> > ioctls such as TIOCSTI.
> >
> > See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256
> >
> > Signed-off-by: Matt Brown 
> 
> 
>  Acked-by: Serge Hallyn 
> >>>
> >>>
> >>> This Ack didn't end up in the v5, but I think it stands, yes?
> >>>
> >>> Greg, is the v5 okay to pull for you or would a v6 with Acks/Reviews
> >>> included be preferred?
> >>
> >>
> >> v6 would be great, and we are dropping patch 2 from the series, right?
> >> I was expecting this to be resent.  I'll start looking at new patches
> >> like this after 4.12-rc1 is out.
> >>
> >
> > I will create a v6 with the Acks/Reviews. I'd like to keep patch 2 in
> > since that got acked by at least Serge. (Kees also? or just patch 1?)
> 
> Sorry, I meant that patch 2's ack from serge got dropped accidentally.
> i.e. he Acked v4, but it wasn't in v5.
> 
> Serge, just to double-check, does your Ack stand?

Yes.

thanks,
-serge

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

[Arun Raghavan]

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: 4495c08e84729385774601b5146d51d9e5849f81
>  > Refname:refs/heads/master
>  > Author: Arun Raghavan 
>  > AuthorDate: Wed Mar 1 20:23:09 2017 +0530
>  > Committer:  Thomas Gleixner 
>  > CommitDate: Mon Mar 13 21:32:15 2017 +0100
>  > 
>  > rlimits: Print more information when CPU/RT limits are exceeded
>  > 
>  > When a process is sent a SIGKILL because it exceeded CPU or RT limits,
>  > the cause may not be obvious in userspace -- daemonised processes just
>  > get killed, and even foreground process just see a 'Killed' message. 
> The
>  > lack of any information on why this might be happening in logs can be
>  > confusing to users who are not aware of this mechanism.
>  > 
>  > Add messages which dump the process name and tid in dmesg when a 
> process
>  > exceeds its CPU or RT limits (soft and hard) in order to make it 
> clearer to
>  > people debugging such issues.
>  > 
>  > Signed-off-by: Arun Raghavan 
>  > Link: 
> http://lkml.kernel.org/r/20170301145309.27214-1-a...@arunraghavan.net
>  > Signed-off-by: Thomas Gleixner 
> 
> This needs to be configurable, because this is really obnoxious..

Is there an example of hos this is done elsewhere that I can work off?

Thanks,
Arun

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

[Arun Raghavan]

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: 4495c08e84729385774601b5146d51d9e5849f81
>  > Refname:refs/heads/master
>  > Author: Arun Raghavan 
>  > AuthorDate: Wed Mar 1 20:23:09 2017 +0530
>  > Committer:  Thomas Gleixner 
>  > CommitDate: Mon Mar 13 21:32:15 2017 +0100
>  > 
>  > rlimits: Print more information when CPU/RT limits are exceeded
>  > 
>  > When a process is sent a SIGKILL because it exceeded CPU or RT limits,
>  > the cause may not be obvious in userspace -- daemonised processes just
>  > get killed, and even foreground process just see a 'Killed' message. 
> The
>  > lack of any information on why this might be happening in logs can be
>  > confusing to users who are not aware of this mechanism.
>  > 
>  > Add messages which dump the process name and tid in dmesg when a 
> process
>  > exceeds its CPU or RT limits (soft and hard) in order to make it 
> clearer to
>  > people debugging such issues.
>  > 
>  > Signed-off-by: Arun Raghavan 
>  > Link: 
> http://lkml.kernel.org/r/20170301145309.27214-1-a...@arunraghavan.net
>  > Signed-off-by: Thomas Gleixner 
> 
> This needs to be configurable, because this is really obnoxious..

Is there an example of hos this is done elsewhere that I can work off?

Thanks,
Arun

[RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

[Javier Martinez Canillas]

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 there are too
many differences with max77686 there to justify merging the two drivers.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Lee Jones 
Acked-by: Mark Brown 

---
Resending the patch so that Mark can apply it through the regulator tree.

 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e35370a0c04c..5e19e6913682 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8069,11 +8069,11 @@ S:  Supported
 F: drivers/power/supply/max14577_charger.c
 F: drivers/power/supply/max77693_charger.c
 
-MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS
-M: Javier Martinez Canillas 
+MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER
+M: Javier Martinez Canillas 
 L: linux-kernel@vger.kernel.org
 S: Supported
-F: drivers/*/*max77802*.c
+F: drivers/regulator/max77802-regulator.c
 F: Documentation/devicetree/bindings/*/*max77802.txt
 F: include/dt-bindings/*/*max77802.h
 
-- 
2.9.3

[RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

[Javier Martinez Canillas]

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 there are too
many differences with max77686 there to justify merging the two drivers.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Lee Jones 
Acked-by: Mark Brown 

---
Resending the patch so that Mark can apply it through the regulator tree.

 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e35370a0c04c..5e19e6913682 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8069,11 +8069,11 @@ S:  Supported
 F: drivers/power/supply/max14577_charger.c
 F: drivers/power/supply/max77693_charger.c
 
-MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS
-M: Javier Martinez Canillas 
+MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER
+M: Javier Martinez Canillas 
 L: linux-kernel@vger.kernel.org
 S: Supported
-F: drivers/*/*max77802*.c
+F: drivers/regulator/max77802-regulator.c
 F: Documentation/devicetree/bindings/*/*max77802.txt
 F: include/dt-bindings/*/*max77802.h
 
-- 
2.9.3

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

[Kalle Valo]

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 I rebooted (not because
> of this issue, but just to reboot into a newer kernel) I don't see it
> again.
>
> This is all pretty regular wireless - it's intel 8260 wireless in a
> fairly normal laptop.
>
> Things still seem to *work* ok, so the only problem here is the overly
> verbose and useless WARN_ON. It doesn't even print out *which* rate it
> is warning about, it just does that stupid unconditional WARN_ON()
> without ever shutting up about it..
>
> The WARN_ON() seems to be old, but my logs don't seem to have any
> mention of this until today, so there's something that has changed
> that now triggers it.
>
> Ideas?
>
>   Linus
>
> ---
>
> WARNING: CPU: 3 PID: 1138 at net/wireless/util.c:1236
> cfg80211_calculate_bitrate+0x139/0x170 [cfg80211]

As this is with iwlwifi adding also Luca. There were some rate handling
changes in iwlwifi, like commit 77e409455f41, but don't know if that
could cause this.

-- 
Kalle Valo

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

[Kalle Valo]

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 I rebooted (not because
> of this issue, but just to reboot into a newer kernel) I don't see it
> again.
>
> This is all pretty regular wireless - it's intel 8260 wireless in a
> fairly normal laptop.
>
> Things still seem to *work* ok, so the only problem here is the overly
> verbose and useless WARN_ON. It doesn't even print out *which* rate it
> is warning about, it just does that stupid unconditional WARN_ON()
> without ever shutting up about it..
>
> The WARN_ON() seems to be old, but my logs don't seem to have any
> mention of this until today, so there's something that has changed
> that now triggers it.
>
> Ideas?
>
>   Linus
>
> ---
>
> WARNING: CPU: 3 PID: 1138 at net/wireless/util.c:1236
> cfg80211_calculate_bitrate+0x139/0x170 [cfg80211]

As this is with iwlwifi adding also Luca. There were some rate handling
changes in iwlwifi, like commit 77e409455f41, but don't know if that
could cause this.

-- 
Kalle Valo

linux-next: Tree for May 4

[Stephen Rothwell]

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.

Non-merge commits (relative to Linus' tree): 5569
 5838 files changed, 527380 insertions(+), 94813 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1684096b1ed8 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (36b5a5152119 arc: axs10x: Fix ARC PGU default 
clock frequency)
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (8c64415cc1f5 sparc: Remove redundant tests in 
boot_flags_init().)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (f411af682218 Merge branch 
'ibmvnic-Updated-reset-handler-andcode-fixes')
Merging ipsec/master (89c9fea3c803 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial)
Merging netfilter/master (9744a6fcefcb netfilter: nf_tables: check if same 
extensions are set when adding elements)
Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (a351e9b9fc24 Linux 4.11)
Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (0337966d121e Merge branch 'next' into 
for-linus)
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (96297aee8bce ide: palm_bk3710: add __initdata to 
palm_bk3710_port_info)
Merging vfio-fixes/for-linus (39da7c509acf 

linux-next: Tree for May 4

[Stephen Rothwell]

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.

Non-merge commits (relative to Linus' tree): 5569
 5838 files changed, 527380 insertions(+), 94813 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1684096b1ed8 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (36b5a5152119 arc: axs10x: Fix ARC PGU default 
clock frequency)
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (8c64415cc1f5 sparc: Remove redundant tests in 
boot_flags_init().)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (f411af682218 Merge branch 
'ibmvnic-Updated-reset-handler-andcode-fixes')
Merging ipsec/master (89c9fea3c803 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial)
Merging netfilter/master (9744a6fcefcb netfilter: nf_tables: check if same 
extensions are set when adding elements)
Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (a351e9b9fc24 Linux 4.11)
Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (0337966d121e Merge branch 'next' into 
for-linus)
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF module alias 
information)
Merging ide/master (96297aee8bce ide: palm_bk3710: add __initdata to 
palm_bk3710_port_info)
Merging vfio-fixes/for-linus (39da7c509acf 

Re: net/ipv6: GPF in rt6_device_match

[David Ahern]

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

[David Ahern]

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

[Chen-Yu Tsai]

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 building our component
> list.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 8ddd72cd5873..8c9d2e36be55 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -164,6 +164,11 @@ static const struct component_master_ops 
> sun4i_drv_master_ops = {
> .unbind = sun4i_drv_unbind,
>  };
>
> +static bool sun4i_drv_node_is_connector(struct device_node *node)
> +{
> +   return of_device_is_compatible(node, "hdmi-connector");
> +}
> +
>  static bool sun4i_drv_node_is_frontend(struct device_node *node)
>  {
> return of_device_is_compatible(node, 
> "allwinner,sun5i-a13-display-frontend") ||
> @@ -204,7 +209,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> !of_device_is_available(node))
> return 0;
>
> -   if (!sun4i_drv_node_is_frontend(node)) {
> +   if (!sun4i_drv_node_is_connector(node) &&

I think it's better to just bail out (return 0) if the current node
is a connector. The connector is the end of the pipeline anyway.
Nothing after it should be considered for the component graph.
The way you currently have it, traversal will continue beyond
the connector node.

ChenYu

> +   !sun4i_drv_node_is_frontend(node)) {
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %s\n",
>  of_node_full_name(node));
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 building our component
> list.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 8ddd72cd5873..8c9d2e36be55 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -164,6 +164,11 @@ static const struct component_master_ops 
> sun4i_drv_master_ops = {
> .unbind = sun4i_drv_unbind,
>  };
>
> +static bool sun4i_drv_node_is_connector(struct device_node *node)
> +{
> +   return of_device_is_compatible(node, "hdmi-connector");
> +}
> +
>  static bool sun4i_drv_node_is_frontend(struct device_node *node)
>  {
> return of_device_is_compatible(node, 
> "allwinner,sun5i-a13-display-frontend") ||
> @@ -204,7 +209,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> !of_device_is_available(node))
> return 0;
>
> -   if (!sun4i_drv_node_is_frontend(node)) {
> +   if (!sun4i_drv_node_is_connector(node) &&

I think it's better to just bail out (return 0) if the current node
is a connector. The connector is the end of the pipeline anyway.
Nothing after it should be considered for the component graph.
The way you currently have it, traversal will continue beyond
the connector node.

ChenYu

> +   !sun4i_drv_node_is_frontend(node)) {
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %s\n",
>  of_node_full_name(node));
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 using mode->crtc_vtotal, which
is halved when the mode is interlaced. Instead you used mode->vtotal,
which is double the actual scan resolution in interlaced mode.

ChenYu

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 0f91ec8a4b26..efa079c1a3f5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> /* Set vertical display timings */
> bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> -mode->vtotal, bp);
> +mode->crtc_vtotal, bp);
> regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
> -SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
> +SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
>  SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
>
> /* Set Hsync and Vsync length */
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 using mode->crtc_vtotal, which
is halved when the mode is interlaced. Instead you used mode->vtotal,
which is double the actual scan resolution in interlaced mode.

ChenYu

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 0f91ec8a4b26..efa079c1a3f5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> /* Set vertical display timings */
> bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> -mode->vtotal, bp);
> +mode->crtc_vtotal, bp);
> regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
> -SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
> +SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
>  SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
>
> /* Set Hsync and Vsync length */
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 register access macro does the multiplication of the value passed as
> paremeter, while in the channel 1, the macro doesn't do this, and we need
> to do it before calling it.
>
> Make this consistent by aligning the channel 0 with the channel 1
> behaviour.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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 register access macro does the multiplication of the value passed as
> paremeter, while in the channel 1, the macro doesn't do this, and we need
> to do it before calling it.
>
> Make this consistent by aligning the channel 0 with the channel 1
> behaviour.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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: [PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite

[Chen-Yu Tsai]

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

[Cong Wang]

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 = ip6_route_dev_notify,
>> -   .priority = 0,
>> +   .priority = -10, /* Must be called after addrconf_notify!! */
>>  };
>>
>
>
> It's not a notifier problem; the null_entry is created in ip6_route_init
> which is an init function.

Only init_net's null entry is created here.

>
> For network namespaces other than init_net, it is never initialized. See
> ip6_route_net_init.

I don't understand what you are talking about...

It is obviously initialized in 3 places:

1) The template itself, as we use memdup()
2) Code around dst_init_metrics() in ip6_route_net_init()
3) ip6_route_dev_notify(), which is supposed to initialize it after
loopback registers (the order needs to fix, as shown in my patch)

Why not add a printk and play with my patch to see the difference?

Re: net/ipv6: GPF in rt6_device_match

[Cong Wang]

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 = ip6_route_dev_notify,
>> -   .priority = 0,
>> +   .priority = -10, /* Must be called after addrconf_notify!! */
>>  };
>>
>
>
> It's not a notifier problem; the null_entry is created in ip6_route_init
> which is an init function.

Only init_net's null entry is created here.

>
> For network namespaces other than init_net, it is never initialized. See
> ip6_route_net_init.

I don't understand what you are talking about...

It is obviously initialized in 3 places:

1) The template itself, as we use memdup()
2) Code around dst_init_metrics() in ip6_route_net_init()
3) ip6_route_dev_notify(), which is supposed to initialize it after
loopback registers (the order needs to fix, as shown in my patch)

Why not add a printk and play with my patch to see the difference?

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

[Chen-Yu Tsai]

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 convert the existing drivers.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_rgb.c  |  1 +
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 --
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
>  drivers/gpu/drm/sun4i/sun4i_tv.c   |  1 +
>  4 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index 67f0b91a99de..3003d290c635 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -175,6 +175,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
> *encoder,
> struct sun4i_tcon *tcon = rgb->tcon;
>
> sun4i_tcon0_mode_set(tcon, mode);
> +   sun4i_tcon_set_mux(tcon, 0, encoder);
>
> clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 66a5bb9b85e9..0204d9fadb66 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -108,6 +108,22 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable)
>  }
>  EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> +   struct drm_encoder *encoder)

The channel doesn't really matter. What is needed is which TCON and encoder
are supposed to be muxed together. This is going to be per SoC type anyway.

I have something in the works, though it's not finished yet.
I think this works for now.

Acked-by: Chen-Yu Tsai 

> +{
> +   if (!tcon->quirks->has_unknown_mux)
> +   return;
> +
> +   if (channel != 1)
> +   return;
> +
> +   /*
> +* FIXME: Undocumented bits
> +*/
> +   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
> +}
> +EXPORT_SYMBOL(sun4i_tcon_set_mux);
> +
>  static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
> int channel)
>  {
> @@ -266,12 +282,6 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
>SUN4I_TCON_GCTL_IOMAP_TCON1);
> -
> -   /*
> -* FIXME: Undocumented bits
> -*/
> -   if (tcon->quirks->has_unknown_mux)
> -   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
>  }
>  EXPORT_SYMBOL(sun4i_tcon1_mode_set);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index f636343a935d..0350936b413c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -190,6 +190,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable);
>  /* Mode Related Controls */
>  void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
>  bool enable);
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> +   struct drm_encoder *encoder);
>  void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
>   struct drm_display_mode *mode);
>  void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c 
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 49c49431a053..03c494b8159c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -393,6 +393,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
> const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
>
> sun4i_tcon1_mode_set(tcon, mode);
> +   sun4i_tcon_set_mux(tcon, 1, encoder);
>
> /* Enable and map the DAC to the output */
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 convert the existing drivers.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_rgb.c  |  1 +
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 --
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
>  drivers/gpu/drm/sun4i/sun4i_tv.c   |  1 +
>  4 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index 67f0b91a99de..3003d290c635 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -175,6 +175,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
> *encoder,
> struct sun4i_tcon *tcon = rgb->tcon;
>
> sun4i_tcon0_mode_set(tcon, mode);
> +   sun4i_tcon_set_mux(tcon, 0, encoder);
>
> clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 66a5bb9b85e9..0204d9fadb66 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -108,6 +108,22 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable)
>  }
>  EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> +   struct drm_encoder *encoder)

The channel doesn't really matter. What is needed is which TCON and encoder
are supposed to be muxed together. This is going to be per SoC type anyway.

I have something in the works, though it's not finished yet.
I think this works for now.

Acked-by: Chen-Yu Tsai 

> +{
> +   if (!tcon->quirks->has_unknown_mux)
> +   return;
> +
> +   if (channel != 1)
> +   return;
> +
> +   /*
> +* FIXME: Undocumented bits
> +*/
> +   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
> +}
> +EXPORT_SYMBOL(sun4i_tcon_set_mux);
> +
>  static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
> int channel)
>  {
> @@ -266,12 +282,6 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
>SUN4I_TCON_GCTL_IOMAP_TCON1);
> -
> -   /*
> -* FIXME: Undocumented bits
> -*/
> -   if (tcon->quirks->has_unknown_mux)
> -   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
>  }
>  EXPORT_SYMBOL(sun4i_tcon1_mode_set);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index f636343a935d..0350936b413c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -190,6 +190,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable);
>  /* Mode Related Controls */
>  void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
>  bool enable);
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> +   struct drm_encoder *encoder);
>  void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
>   struct drm_display_mode *mode);
>  void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c 
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 49c49431a053..03c494b8159c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -393,6 +393,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
> const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
>
> sun4i_tcon1_mode_set(tcon, mode);
> +   sun4i_tcon_set_mux(tcon, 1, encoder);
>
> /* Enable and map the DAC to the output */
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> --
> git-series 0.8.11

Re: [linux-sunxi] Designware UART bug

[Tim Kryger]

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
> delayed interrupt.
>
> So one question is, why are we not checking the USR[0] reg whilst doing the
> loop? Is that register not there for exactly that purpose? But I guess
> brute-forcing it works more reliable I suppose then.

That status bit isn't particularly helpful since even if it reports
the UART is idle, there is no guarantee it won't become busy before
the attempted write of the LCR happens.

> But secondly, when is the UART_IIR_BUSY interrupt handled? And it not being
> handled, could that be the actual reason things where failing? (Or as I read
> somewhere a silicon bug?)
>
> Right now, we have serial8250_handle_irq() and if that returns 0, we check
> if we (still) have an unhandled UART_IIR_BUSY interrupt.
> But the only way for serial8250_handle_irq() to return 0, is if it has set
> UART_NO_INT.
>
> If we do not have an IRQ, i'm pretty sure, UART_IIR_BUSY can't be triggered
> right? And if it IS the interrupt that caused us to go into the interrupt
> handler, well, handle_irq does its thing and then returns 1 for finishing
> it, which in turn causes the UART_IIR_BUSY check to be skipped.
>
> So we never clear the UART_IIR_BUSY interrupt if we manage to trigger that.
> (Please do correct me if I'm wrong.

Note that the LSB is set in each of the following defines.

#define UART_IIR_NO_INT 0x01 /* No interrupts pending */
#define UART_IIR_BUSY   0x07 /* DesignWare APB Busy Detect */

Thus, when iir is UART_IIR_BUSY, serial8250_handle_irq bails out and
returns zero such that the interrupt gets cleared by the read of USR
in dw8250_handle_irq.

> I'm changing things in the interrupt handler a bit now to first check for
> the busy interrupt first and if that is triggered do the dummy return (clear
> it) and return (since LCR is handled alternativly.
>
> Olliver

Re: [linux-sunxi] Designware UART bug

[Tim Kryger]

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
> delayed interrupt.
>
> So one question is, why are we not checking the USR[0] reg whilst doing the
> loop? Is that register not there for exactly that purpose? But I guess
> brute-forcing it works more reliable I suppose then.

That status bit isn't particularly helpful since even if it reports
the UART is idle, there is no guarantee it won't become busy before
the attempted write of the LCR happens.

> But secondly, when is the UART_IIR_BUSY interrupt handled? And it not being
> handled, could that be the actual reason things where failing? (Or as I read
> somewhere a silicon bug?)
>
> Right now, we have serial8250_handle_irq() and if that returns 0, we check
> if we (still) have an unhandled UART_IIR_BUSY interrupt.
> But the only way for serial8250_handle_irq() to return 0, is if it has set
> UART_NO_INT.
>
> If we do not have an IRQ, i'm pretty sure, UART_IIR_BUSY can't be triggered
> right? And if it IS the interrupt that caused us to go into the interrupt
> handler, well, handle_irq does its thing and then returns 1 for finishing
> it, which in turn causes the UART_IIR_BUSY check to be skipped.
>
> So we never clear the UART_IIR_BUSY interrupt if we manage to trigger that.
> (Please do correct me if I'm wrong.

Note that the LSB is set in each of the following defines.

#define UART_IIR_NO_INT 0x01 /* No interrupts pending */
#define UART_IIR_BUSY   0x07 /* DesignWare APB Busy Detect */

Thus, when iir is UART_IIR_BUSY, serial8250_handle_irq bails out and
returns zero such that the interrupt gets cleared by the read of USR
in dw8250_handle_irq.

> I'm changing things in the interrupt handler a bit now to first check for
> the busy interrupt first and if that is triggered do the dummy return (clear
> it) and return (since LCR is handled alternativly.
>
> Olliver

Re: Future of liblockdep

[alexander . levin]

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 that last June and he included these in a pull request
> > > to Ingo, but somehow they never reached mainline.  Linux 4.8 broke
> > > liblockdep further, and I gave up packaging it for Debian.
> > > 
> > > There have been no other changes to liblockdep since then, other than a
> > > general change in the tools/ directory.  Sasha's address in MAINTAINERS
> > > is also out-of-date.
> > > 
> > > Please either maintain liblockdep properly or delete it.  We shouldn't
> > > keep code in the tree in a broken state.
> > 
> > Hi Ben,
> > 
> > I indeed received those patches and forwarded them on:
> > 
> > https://lkml.org/lkml/2016/6/17/1044
> > 
> > As well as an updated maintainers entry:
> > 
> > https://lkml.org/lkml/2016/7/29/431
> > 
> > But I failed to follow up on that and it seems to have fallen through the
> > cracks.
> > 
> > I'll get it back into shape, sorry.
> > 
> > I also don't expect many changes to liblockdep other than keeping it 
> > buildable,
> > if there are any missing features or bugs you'd like to discuss I'd be 
> > happy to
> > look into those.
> 
> I had some other fixes that I was waiting to send:
> 
> https://sources.debian.net/src/linux/4.9.25-1/debian/patches/bugfix/all/lockdep-fix-oot-build.patch/
> https://sources.debian.net/src/linux/4.9.25-1/debian/patches/bugfix/all/lockdep-fix-soname.patch/
> https://sources.debian.net/src/linux/4.9.25-1/debian/patches/bugfix/all/tools-lib-lockdep-use-ldflags.patch/

Thanks Ben. I got it building again on 4.11, will run a few more tests in the
morning and will send a pull request.


-- 

Thanks,
Sasha

Re: Future of liblockdep

[alexander . levin]

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 that last June and he included these in a pull request
> > > to Ingo, but somehow they never reached mainline.  Linux 4.8 broke
> > > liblockdep further, and I gave up packaging it for Debian.
> > > 
> > > There have been no other changes to liblockdep since then, other than a
> > > general change in the tools/ directory.  Sasha's address in MAINTAINERS
> > > is also out-of-date.
> > > 
> > > Please either maintain liblockdep properly or delete it.  We shouldn't
> > > keep code in the tree in a broken state.
> > 
> > Hi Ben,
> > 
> > I indeed received those patches and forwarded them on:
> > 
> > https://lkml.org/lkml/2016/6/17/1044
> > 
> > As well as an updated maintainers entry:
> > 
> > https://lkml.org/lkml/2016/7/29/431
> > 
> > But I failed to follow up on that and it seems to have fallen through the
> > cracks.
> > 
> > I'll get it back into shape, sorry.
> > 
> > I also don't expect many changes to liblockdep other than keeping it 
> > buildable,
> > if there are any missing features or bugs you'd like to discuss I'd be 
> > happy to
> > look into those.
> 
> I had some other fixes that I was waiting to send:
> 
> https://sources.debian.net/src/linux/4.9.25-1/debian/patches/bugfix/all/lockdep-fix-oot-build.patch/
> https://sources.debian.net/src/linux/4.9.25-1/debian/patches/bugfix/all/lockdep-fix-soname.patch/
> https://sources.debian.net/src/linux/4.9.25-1/debian/patches/bugfix/all/tools-lib-lockdep-use-ldflags.patch/

Thanks Ben. I got it building again on 4.11, will run a few more tests in the
morning and will send a pull request.


-- 

Thanks,
Sasha

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

[Xiao Guangrong]

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.
Maybe we can make KVM_CAP_X86_WRITE_PROTECT_ALL_MEM return false if
PML is enabled?


Yes, that's a good idea.  Though it's a pity that, with PML, setting the
dirty bit will still do the massive walk of the rmap.  At least with
reset_dirty_pages it's done a little bit at a time.


Also, I wonder how the alternative write protection mechanism would
affect performance of the dirty page ring buffer patches.  You would do
the write protection of all memory at the end of
kvm_vm_ioctl_reset_dirty_pages.  You wouldn't even need a separate
ioctl, which is nice.  On the other hand, checkpoints would be more
frequent and most pages would be write-protected, so it would be more
expensive to rebuild the shadow page tables...


Yup, write-protect-all can improve reset_dirty_pages indeed, i will
apply your idea after reset_dirty_pages is merged.

However, we still prefer to have a separate ioctl for write-protect-all
which cooperates with KVM_GET_DIRTY_LOG to improve live migration that
should not always depend on checkpoint.


Ok, I plan to merge the dirty ring pages early in 4.13 development.


Great.

As there is no conflict between these two patchsets except dirty
ring pages takes benefit from write-protect-all, i think they
can be developed and iterated independently, right?

Or you prefer to merge dirty ring pages first then review the
new version of this patchset later?

Thanks!

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

[Xiao Guangrong]

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.
Maybe we can make KVM_CAP_X86_WRITE_PROTECT_ALL_MEM return false if
PML is enabled?


Yes, that's a good idea.  Though it's a pity that, with PML, setting the
dirty bit will still do the massive walk of the rmap.  At least with
reset_dirty_pages it's done a little bit at a time.


Also, I wonder how the alternative write protection mechanism would
affect performance of the dirty page ring buffer patches.  You would do
the write protection of all memory at the end of
kvm_vm_ioctl_reset_dirty_pages.  You wouldn't even need a separate
ioctl, which is nice.  On the other hand, checkpoints would be more
frequent and most pages would be write-protected, so it would be more
expensive to rebuild the shadow page tables...


Yup, write-protect-all can improve reset_dirty_pages indeed, i will
apply your idea after reset_dirty_pages is merged.

However, we still prefer to have a separate ioctl for write-protect-all
which cooperates with KVM_GET_DIRTY_LOG to improve live migration that
should not always depend on checkpoint.


Ok, I plan to merge the dirty ring pages early in 4.13 development.


Great.

As there is no conflict between these two patchsets except dirty
ring pages takes benefit from write-protect-all, i think they
can be developed and iterated independently, right?

Or you prefer to merge dirty ring pages first then review the
new version of this patchset later?

Thanks!

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

[Chen-Yu Tsai]

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

[Chen-Yu Tsai]

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

[Chen-Yu Tsai]

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 which
> case we will simply ignore that change and still use the previous parent
> rate.
>
> Create a new function to re-adjust the parent rate to take the pre-dividers
> into account, and give that back to the clock framework.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/clk/sunxi-ng/ccu_mux.c | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
> index c33210972581..1ce62cc23f8a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mux.c
> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
> @@ -64,6 +64,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct 
> ccu_common *common,
> return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
>  }
>
> +unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
> +   struct ccu_mux_internal *cm,
> +   int parent_index,
> +   unsigned long parent_rate)
> +{
> +   return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
> +}
> +
>  int ccu_mux_helper_determine_rate(struct ccu_common *common,
>   struct ccu_mux_internal *cm,
>   struct clk_rate_request *req,
> @@ -89,22 +97,37 @@ int ccu_mux_helper_determine_rate(struct ccu_common 
> *common,
> best_rate = round(cm, best_parent, _parent_rate,
>   req->rate, data);
>
> +   /*
> +* parent_rate might have been modified by our clock.
> +* Re-apply the pre-divider if there's one, and give

Might want to reword the comments to match the new name.

> +* the actual frequency the parent needs to run at.
> +*/
> +   best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, 
> -1,
> +
> adj_parent_rate);
> +
> goto out;
> }
>
> for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
> -   unsigned long tmp_rate, parent_rate, adj_parent_rate;
> +   unsigned long tmp_rate, parent_rate;
> struct clk_hw *parent;
>
> parent = clk_hw_get_parent_by_index(hw, i);
> if (!parent)
> continue;
>
> -   parent_rate = clk_hw_get_rate(parent);
> -   adj_parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> - parent_rate);
> +   parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> + 
> clk_hw_get_rate(parent));
> +
> +   tmp_rate = round(cm, parent, _rate, req->rate, data);
>
> -   tmp_rate = round(cm, parent, _parent_rate, req->rate, 
> data);
> +   /*
> +* parent_rate might have been modified by our clock.
> +* Re-apply the pre-divider if there's one, and give

Same here. Otherwise,

Acked-by: Chen-Yu Tsai 

> +* the actual frequency the parent needs to run at.
> +*/
> +   parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
> +   parent_rate);
> if (tmp_rate == req->rate) {
> best_parent = parent;
> best_parent_rate = parent_rate;
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 which
> case we will simply ignore that change and still use the previous parent
> rate.
>
> Create a new function to re-adjust the parent rate to take the pre-dividers
> into account, and give that back to the clock framework.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/clk/sunxi-ng/ccu_mux.c | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
> index c33210972581..1ce62cc23f8a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mux.c
> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
> @@ -64,6 +64,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct 
> ccu_common *common,
> return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
>  }
>
> +unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
> +   struct ccu_mux_internal *cm,
> +   int parent_index,
> +   unsigned long parent_rate)
> +{
> +   return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
> +}
> +
>  int ccu_mux_helper_determine_rate(struct ccu_common *common,
>   struct ccu_mux_internal *cm,
>   struct clk_rate_request *req,
> @@ -89,22 +97,37 @@ int ccu_mux_helper_determine_rate(struct ccu_common 
> *common,
> best_rate = round(cm, best_parent, _parent_rate,
>   req->rate, data);
>
> +   /*
> +* parent_rate might have been modified by our clock.
> +* Re-apply the pre-divider if there's one, and give

Might want to reword the comments to match the new name.

> +* the actual frequency the parent needs to run at.
> +*/
> +   best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, 
> -1,
> +
> adj_parent_rate);
> +
> goto out;
> }
>
> for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
> -   unsigned long tmp_rate, parent_rate, adj_parent_rate;
> +   unsigned long tmp_rate, parent_rate;
> struct clk_hw *parent;
>
> parent = clk_hw_get_parent_by_index(hw, i);
> if (!parent)
> continue;
>
> -   parent_rate = clk_hw_get_rate(parent);
> -   adj_parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> - parent_rate);
> +   parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> + 
> clk_hw_get_rate(parent));
> +
> +   tmp_rate = round(cm, parent, _rate, req->rate, data);
>
> -   tmp_rate = round(cm, parent, _parent_rate, req->rate, 
> data);
> +   /*
> +* parent_rate might have been modified by our clock.
> +* Re-apply the pre-divider if there's one, and give

Same here. Otherwise,

Acked-by: Chen-Yu Tsai 

> +* the actual frequency the parent needs to run at.
> +*/
> +   parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
> +   parent_rate);
> if (tmp_rate == req->rate) {
> best_parent = parent;
> best_parent_rate = parent_rate;
> --
> git-series 0.8.11

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

[Chen-Yu Tsai]

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 be less confusing, and easier to use for downstream users,
> change the function name to something hopefully clearer, and return the
> adjusted rate instead of changing the pointer.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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 be less confusing, and easier to use for downstream users,
> change the function name to something hopefully clearer, and return the
> adjusted rate instead of changing the pointer.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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 operation, we need to split out
> that code into a function that will be shared.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Seems this would conflict with my "clk: sunxi-ng: Support multiple variable
pre-dividers" patch though. We'll see how this works out.

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

[Chen-Yu Tsai]

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 operation, we need to split out
> that code into a function that will be shared.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Seems this would conflict with my "clk: sunxi-ng: Support multiple variable
pre-dividers" patch though. We'll see how this works out.

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

[Chen-Yu Tsai]

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 round rate of the clocks
> to give us the best computation that might be achieved for a given rate.
>
> round_rate functions now need to honor CLK_SET_RATE_PARENT, but either the
> functions already do that if they modify the parent, or don't modify the
> praents at all.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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 round rate of the clocks
> to give us the best computation that might be achieved for a given rate.
>
> round_rate functions now need to honor CLK_SET_RATE_PARENT, but either the
> functions already do that if they modify the parent, or don't modify the
> praents at all.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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
> just use it.
>
> Signed-off-by: Maxime Ripard 

Otherwise,

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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
> just use it.
>
> Signed-off-by: Maxime Ripard 

Otherwise,

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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 Ripard 

Acked-by: Chen-Yu Tsai 

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

[Chen-Yu Tsai]

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 Ripard 

Acked-by: Chen-Yu Tsai 

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

[Paul E. McKenney]

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 
> dev.2017.04.21a
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

This is expected behavior.  When you build rcuperf into the kernel (as
was the case here with CONFIG_RCU_PERF_TEST=y), it runs the test and
then shuts down the kernel.  The test only takes less than a minute,
so this will look like a boot failure.  (I run it from some scripts
that expect the shutdown and collect performance data either from
dmesg or from event tracing, so this auto-shutdown feature is indeed
a feature rather than a bug.)

There are several ways to avoid this:

1.  Exclude CONFIG_RCU_PERF_TEST=y from your testing.  In other words,
build with either CONFIG_RCU_PERF_TEST=n or CONFIG_RCU_PERF_TEST=m,
thus avoiding the auto-shutdown functionality.

2.  If you want to run CONFIG_RCU_PERF_TEST=y anyway, then boot such
kernels with rcuperf.shutdown=0 to override the auto-shutdown
default.

3.  As in #2, but instead boot with rcuperf.holdoff=7200 (assuming that
your tests run for less than two hours).

There are probably some other approaches, so please let me know if none of
the above work for you.

Thanx, Paul

> +--+++
> | 
>  | 7984237c13 | 87c458e630 |
> +--+++
> | boot_successes  
>  | 0  | 6  |
> | boot_failures   
>  | 30 | 24 |
> | invoked_oom-killer:gfp_mask=0x  
>  | 30 ||
> | Mem-Info
>  | 30 ||
> | Out_of_memory:Kill_process  
>  | 30 ||
> | 
> page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY),nodemask=(null)
>  | 7  ||
> | BUG:kernel_hang_in_test_stage   
>  | 0  | 18 |
> | WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule
>  | 0  | 14 |
> +--+++
> 
> 
> 
> [   15.553978] WARNING: CPU: 0 PID: 9 at arch/x86/kernel/smp.c:127 
> native_smp_send_reschedule+0x4f/0x68
> [   15.556230] Modules linked in:
> [   15.556868] CPU: 0 PID: 9 Comm: migration/0 Not tainted 
> 4.11.0-rc2-00091-g87c458e #1
> [   15.558408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [   15.560409] Call Trace:
> [   15.560937]  dump_stack+0x61/0x7e
> [   15.561604]  __warn+0xc2/0xdd
> [   15.562219]  warn_slowpath_null+0x1d/0x1f
> [   15.563027]  native_smp_send_reschedule+0x4f/0x68
> [   15.564061]  resched_curr+0x9e/0x168
> [   15.564792]  check_preempt_curr+0x4a/0x92
> [   15.565592]  move_queued_task+0x1cc/0x1d6
> [   15.566415]  __migrate_task+0x88/0x97
> [   15.567158]  migration_cpu_stop+0x77/0xa4
> [   15.567968]  ? sched_ttwu_pending+0xbd/0xbd
> [   15.568815]  cpu_stopper_thread+0x84/0xf3
> [   15.569613]  ? sort_range+0x22/0x22
> [   15.570326]  smpboot_thread_fn+0x1cc/0x1e3
> [   15.571164]  kthread+0x12d/0x135
> [   15.571825]  ? kthread_create_on_node+0x3f/0x3f
> [   15.572742]  ret_from_fork+0x2c/0x40
> [   15.573468] ---[ end trace ce70cc5403b8b2a1 ]---
> 
> 
> To reproduce:
> 
> git clone https://github.com/01org/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k  job-script  # job-script is attached in 
> this email
> 
> 
> 
> Thanks,
> Xiaolong

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.11.0-rc2 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> 

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

[Paul E. McKenney]

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 
> dev.2017.04.21a
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m 1G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

This is expected behavior.  When you build rcuperf into the kernel (as
was the case here with CONFIG_RCU_PERF_TEST=y), it runs the test and
then shuts down the kernel.  The test only takes less than a minute,
so this will look like a boot failure.  (I run it from some scripts
that expect the shutdown and collect performance data either from
dmesg or from event tracing, so this auto-shutdown feature is indeed
a feature rather than a bug.)

There are several ways to avoid this:

1.  Exclude CONFIG_RCU_PERF_TEST=y from your testing.  In other words,
build with either CONFIG_RCU_PERF_TEST=n or CONFIG_RCU_PERF_TEST=m,
thus avoiding the auto-shutdown functionality.

2.  If you want to run CONFIG_RCU_PERF_TEST=y anyway, then boot such
kernels with rcuperf.shutdown=0 to override the auto-shutdown
default.

3.  As in #2, but instead boot with rcuperf.holdoff=7200 (assuming that
your tests run for less than two hours).

There are probably some other approaches, so please let me know if none of
the above work for you.

Thanx, Paul

> +--+++
> | 
>  | 7984237c13 | 87c458e630 |
> +--+++
> | boot_successes  
>  | 0  | 6  |
> | boot_failures   
>  | 30 | 24 |
> | invoked_oom-killer:gfp_mask=0x  
>  | 30 ||
> | Mem-Info
>  | 30 ||
> | Out_of_memory:Kill_process  
>  | 30 ||
> | 
> page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY),nodemask=(null)
>  | 7  ||
> | BUG:kernel_hang_in_test_stage   
>  | 0  | 18 |
> | WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule
>  | 0  | 14 |
> +--+++
> 
> 
> 
> [   15.553978] WARNING: CPU: 0 PID: 9 at arch/x86/kernel/smp.c:127 
> native_smp_send_reschedule+0x4f/0x68
> [   15.556230] Modules linked in:
> [   15.556868] CPU: 0 PID: 9 Comm: migration/0 Not tainted 
> 4.11.0-rc2-00091-g87c458e #1
> [   15.558408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [   15.560409] Call Trace:
> [   15.560937]  dump_stack+0x61/0x7e
> [   15.561604]  __warn+0xc2/0xdd
> [   15.562219]  warn_slowpath_null+0x1d/0x1f
> [   15.563027]  native_smp_send_reschedule+0x4f/0x68
> [   15.564061]  resched_curr+0x9e/0x168
> [   15.564792]  check_preempt_curr+0x4a/0x92
> [   15.565592]  move_queued_task+0x1cc/0x1d6
> [   15.566415]  __migrate_task+0x88/0x97
> [   15.567158]  migration_cpu_stop+0x77/0xa4
> [   15.567968]  ? sched_ttwu_pending+0xbd/0xbd
> [   15.568815]  cpu_stopper_thread+0x84/0xf3
> [   15.569613]  ? sort_range+0x22/0x22
> [   15.570326]  smpboot_thread_fn+0x1cc/0x1e3
> [   15.571164]  kthread+0x12d/0x135
> [   15.571825]  ? kthread_create_on_node+0x3f/0x3f
> [   15.572742]  ret_from_fork+0x2c/0x40
> [   15.573468] ---[ end trace ce70cc5403b8b2a1 ]---
> 
> 
> To reproduce:
> 
> git clone https://github.com/01org/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k  job-script  # job-script is attached in 
> this email
> 
> 
> 
> Thanks,
> Xiaolong

> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.11.0-rc2 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> 

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

[Chen, Xiaoguang]

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;
>> +int i;
>> +gen8_pte_t __iomem *gtt_entries;
>> +
>> +st = kmalloc(sizeof(*st), GFP_KERNEL);
>> +if (st == NULL)
>> +return NULL;
>> +
>> +if (sg_alloc_table(st, num_pages, GFP_KERNEL)) {
>> +kfree(st);
>> +return NULL;
>> +}
>> +
>> +gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
>> +(start >> PAGE_SHIFT);
>> +for_each_sg(st->sgl, sg, num_pages, i) {
>> +sg->offset = 0;
>> +sg->length = PAGE_SIZE;
>> +sg_dma_address(sg) =
>> +GEN8_DECODE_PTE(readq(_entries[i]));
>> +sg_dma_len(sg) = PAGE_SIZE;
>> +}
>
>This should be get_pages.
The reason that I did not alloc pages to the gem obj in get_pages callback is 
that there may be sync problems:
1) decode the vgpu's current frambuffer.
2) save the decoded information(we will use size and address of the framebuffer 
later)
3) create a gem obj the size of the gem obj is the above framebuffer size. 
4) associate the gem obj to a dmabuf and export the dmabuf.
..
5) while user access the gem obj get_pages callback of the gem obj will be 
called to alloc pages for the gem obj.
6) use saved frambuffer's address to look up the gtt table to get the pages of 
the frambuffer. Assign the pages to gem obj.

There may be interval between step 4 and step 5. The framebuffer may have 
changed in step 5 but we are still using the old framebuffer's address(decoded 
in step 1) in step 5.

>
>> +return st;
>> +}

>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Chen, Xiaoguang
>Sent: Tuesday, May 02, 2017 3:40 PM
>To: Chris Wilson 
>Cc: Tian, Kevin ; intel-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; alex.william...@redhat.com;
>kra...@redhat.com; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>; Lv, Zhiyuan 
>Subject: RE: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g
>
>
>
>>-Original Message-
>>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>>Sent: Friday, April 28, 2017 6:09 PM
>>To: Chen, Xiaoguang 
>>Cc: kra...@redhat.com; alex.william...@redhat.com; intel-
>>g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; Wang,
>>Zhi A ; zhen...@linux.intel.com; linux-
>>ker...@vger.kernel.org; Lv, Zhiyuan ; Tian, Kevin
>>
>>Subject: Re: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support
>>for GVT-g
>>
>>On Fri, Apr 28, 2017 at 05:35:29PM +0800, Xiaoguang Chen wrote:
>>> dmabuf for GVT-g can be exported to users who can use the dmabuf to
>>> show the desktop of vm which use intel vgpu.
>>>
>>> Currently we provide query and create new dmabuf operations.
>>>
>>> Users of dmabuf can cache some created dmabufs and related
>>> information such as the framebuffer's address, size, tiling mode,
>>> width, height etc. When refresh the screen first query the currnet
>>> vgpu's frambuffer and compare with the cached ones(address, size,
>>> tiling, width, height
>>> etc) if found one then reuse the found dmabuf to gain performance
>>improvment.
>>>
>>> If there is no dmabuf created yet or not found in the cached dmabufs
>>> then need to create a new dmabuf. To create a dmabuf first a gem
>>> object will be created and the backing storage of this gem object is
>>> the vgpu's framebuffer(primary/cursor). Then associate this gem
>>> object to a dmabuf and export this dmabuf. A file descriptor will be
>>> generated for this dmabuf and this file descriptor can be sent to
>>> user space to
>>do display.
>>>
>>> Signed-off-by: Xiaoguang Chen 
>>> ---
>>>  drivers/gpu/drm/i915/gvt/Makefile |   2 +-
>>>  drivers/gpu/drm/i915/gvt/dmabuf.c | 268
>>> ++
>>>  drivers/gpu/drm/i915/gvt/dmabuf.h |  50 +++
>>>  drivers/gpu/drm/i915/gvt/gvt.h|   1 +
>>>  4 files changed, 320 insertions(+), 1 deletion(-)  create mode
>>> 100644 drivers/gpu/drm/i915/gvt/dmabuf.c  create mode 100644
>>> drivers/gpu/drm/i915/gvt/dmabuf.h
>>>
>>> diff --git a/drivers/gpu/drm/i915/gvt/Makefile
>>> b/drivers/gpu/drm/i915/gvt/Makefile
>>> index 192ca26..e480f7d 100644
>>> --- a/drivers/gpu/drm/i915/gvt/Makefile
>>> +++ b/drivers/gpu/drm/i915/gvt/Makefile
>>> @@ -2,7 +2,7 @@ GVT_DIR := gvt
>>>  GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o
>>firmware.o \
>>> interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>>> 

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

[Chen, Xiaoguang]

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;
>> +int i;
>> +gen8_pte_t __iomem *gtt_entries;
>> +
>> +st = kmalloc(sizeof(*st), GFP_KERNEL);
>> +if (st == NULL)
>> +return NULL;
>> +
>> +if (sg_alloc_table(st, num_pages, GFP_KERNEL)) {
>> +kfree(st);
>> +return NULL;
>> +}
>> +
>> +gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
>> +(start >> PAGE_SHIFT);
>> +for_each_sg(st->sgl, sg, num_pages, i) {
>> +sg->offset = 0;
>> +sg->length = PAGE_SIZE;
>> +sg_dma_address(sg) =
>> +GEN8_DECODE_PTE(readq(_entries[i]));
>> +sg_dma_len(sg) = PAGE_SIZE;
>> +}
>
>This should be get_pages.
The reason that I did not alloc pages to the gem obj in get_pages callback is 
that there may be sync problems:
1) decode the vgpu's current frambuffer.
2) save the decoded information(we will use size and address of the framebuffer 
later)
3) create a gem obj the size of the gem obj is the above framebuffer size. 
4) associate the gem obj to a dmabuf and export the dmabuf.
..
5) while user access the gem obj get_pages callback of the gem obj will be 
called to alloc pages for the gem obj.
6) use saved frambuffer's address to look up the gtt table to get the pages of 
the frambuffer. Assign the pages to gem obj.

There may be interval between step 4 and step 5. The framebuffer may have 
changed in step 5 but we are still using the old framebuffer's address(decoded 
in step 1) in step 5.

>
>> +return st;
>> +}

>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Chen, Xiaoguang
>Sent: Tuesday, May 02, 2017 3:40 PM
>To: Chris Wilson 
>Cc: Tian, Kevin ; intel-...@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; alex.william...@redhat.com;
>kra...@redhat.com; intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
>; Lv, Zhiyuan 
>Subject: RE: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g
>
>
>
>>-Original Message-
>>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>>Sent: Friday, April 28, 2017 6:09 PM
>>To: Chen, Xiaoguang 
>>Cc: kra...@redhat.com; alex.william...@redhat.com; intel-
>>g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; Wang,
>>Zhi A ; zhen...@linux.intel.com; linux-
>>ker...@vger.kernel.org; Lv, Zhiyuan ; Tian, Kevin
>>
>>Subject: Re: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support
>>for GVT-g
>>
>>On Fri, Apr 28, 2017 at 05:35:29PM +0800, Xiaoguang Chen wrote:
>>> dmabuf for GVT-g can be exported to users who can use the dmabuf to
>>> show the desktop of vm which use intel vgpu.
>>>
>>> Currently we provide query and create new dmabuf operations.
>>>
>>> Users of dmabuf can cache some created dmabufs and related
>>> information such as the framebuffer's address, size, tiling mode,
>>> width, height etc. When refresh the screen first query the currnet
>>> vgpu's frambuffer and compare with the cached ones(address, size,
>>> tiling, width, height
>>> etc) if found one then reuse the found dmabuf to gain performance
>>improvment.
>>>
>>> If there is no dmabuf created yet or not found in the cached dmabufs
>>> then need to create a new dmabuf. To create a dmabuf first a gem
>>> object will be created and the backing storage of this gem object is
>>> the vgpu's framebuffer(primary/cursor). Then associate this gem
>>> object to a dmabuf and export this dmabuf. A file descriptor will be
>>> generated for this dmabuf and this file descriptor can be sent to
>>> user space to
>>do display.
>>>
>>> Signed-off-by: Xiaoguang Chen 
>>> ---
>>>  drivers/gpu/drm/i915/gvt/Makefile |   2 +-
>>>  drivers/gpu/drm/i915/gvt/dmabuf.c | 268
>>> ++
>>>  drivers/gpu/drm/i915/gvt/dmabuf.h |  50 +++
>>>  drivers/gpu/drm/i915/gvt/gvt.h|   1 +
>>>  4 files changed, 320 insertions(+), 1 deletion(-)  create mode
>>> 100644 drivers/gpu/drm/i915/gvt/dmabuf.c  create mode 100644
>>> drivers/gpu/drm/i915/gvt/dmabuf.h
>>>
>>> diff --git a/drivers/gpu/drm/i915/gvt/Makefile
>>> b/drivers/gpu/drm/i915/gvt/Makefile
>>> index 192ca26..e480f7d 100644
>>> --- a/drivers/gpu/drm/i915/gvt/Makefile
>>> +++ b/drivers/gpu/drm/i915/gvt/Makefile
>>> @@ -2,7 +2,7 @@ GVT_DIR := gvt
>>>  GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o
>>firmware.o \
>>> interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>>> execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
>>> -   fb_decoder.o
>>> +   fb_decoder.o dmabuf.o
>>>
>>>  ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR) -Wall
>>>  i915-y

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

[Chen, Xiaoguang]

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; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; alex.william...@redhat.com;
>Lv, Zhiyuan ; intel-gvt-...@lists.freedesktop.org; Wang,
>Zhi A 
>Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>
>
>>-Original Message-
>>From: Gerd Hoffmann [mailto:kra...@redhat.com]
>>Sent: Tuesday, May 02, 2017 5:51 PM
>>To: Chen, Xiaoguang 
>>Cc: alex.william...@redhat.com; intel-...@lists.freedesktop.org;
>>intel-gvt- d...@lists.freedesktop.org; Wang, Zhi A
>>; zhen...@linux.intel.com;
>>linux-kernel@vger.kernel.org; Lv, Zhiyuan ; Tian,
>>Kevin 
>>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the
>>dmabuf
>>
>>On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote:
>>> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char
>>> *buf,
>>> +   size_t count, loff_t *ppos, bool iswrite) {
>>> +   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
>>> +   VFIO_PCI_NUM_REGIONS;
>>> +   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>>> +   int fd;
>>> +
>>> +   if (pos >= vgpu->vdev.region[i].size || iswrite) {
>>> +   gvt_vgpu_err("invalid op or offset for Intel vgpu fd
>>> region\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   fd = anon_inode_getfd("gvtg", _vgpu_gvtg_ops, vgpu,
>>> +   O_RDWR | O_CLOEXEC);
>>> +   if (fd < 0) {
>>> +   gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
>>> +   memcpy(buf, , count);
>>> +
>>> +   return count;
>>> +}
>>
>>Hmm, that looks like a rather strange way to return a file descriptor.
>>
>>What is the reason to not use ioctls on the vfio file handle, like
>>older version of these patches did?
>If I understood correctly that Alex prefer not to change the ioctls on the 
>vfio file
>handle like the old version.
>So I used this way the smallest change to general vfio framework only adding a
>subregion definition.
>
>>
>>cheers,
>>  Gerd
>
>___
>intel-gvt-dev mailing list
>intel-gvt-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

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

[Chen, Xiaoguang]

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; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; alex.william...@redhat.com;
>Lv, Zhiyuan ; intel-gvt-...@lists.freedesktop.org; Wang,
>Zhi A 
>Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>
>
>>-Original Message-
>>From: Gerd Hoffmann [mailto:kra...@redhat.com]
>>Sent: Tuesday, May 02, 2017 5:51 PM
>>To: Chen, Xiaoguang 
>>Cc: alex.william...@redhat.com; intel-...@lists.freedesktop.org;
>>intel-gvt- d...@lists.freedesktop.org; Wang, Zhi A
>>; zhen...@linux.intel.com;
>>linux-kernel@vger.kernel.org; Lv, Zhiyuan ; Tian,
>>Kevin 
>>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the
>>dmabuf
>>
>>On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote:
>>> +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char
>>> *buf,
>>> +   size_t count, loff_t *ppos, bool iswrite) {
>>> +   unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
>>> +   VFIO_PCI_NUM_REGIONS;
>>> +   loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>>> +   int fd;
>>> +
>>> +   if (pos >= vgpu->vdev.region[i].size || iswrite) {
>>> +   gvt_vgpu_err("invalid op or offset for Intel vgpu fd
>>> region\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   fd = anon_inode_getfd("gvtg", _vgpu_gvtg_ops, vgpu,
>>> +   O_RDWR | O_CLOEXEC);
>>> +   if (fd < 0) {
>>> +   gvt_vgpu_err("create intel vgpu fd failed:%d\n", fd);
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
>>> +   memcpy(buf, , count);
>>> +
>>> +   return count;
>>> +}
>>
>>Hmm, that looks like a rather strange way to return a file descriptor.
>>
>>What is the reason to not use ioctls on the vfio file handle, like
>>older version of these patches did?
>If I understood correctly that Alex prefer not to change the ioctls on the 
>vfio file
>handle like the old version.
>So I used this way the smallest change to general vfio framework only adding a
>subregion definition.
>
>>
>>cheers,
>>  Gerd
>
>___
>intel-gvt-dev mailing list
>intel-gvt-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

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

[Chen-Yu Tsai]

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 delays no longer apply.
>>
>> Due to how the clock tree is modeled and setup, we need to model
>> this function in two places, the master mmc clock and the two
>> child phase clocks. In the mmc clock, we can easily model the
>> mode bit as an extra variable post-divider. In the phase clocks,
>> we check the bit and return -ENOTSUPP if the bit is set, signaling
>> that the phase clocks are not to be used.
>>
>> This patch introduces a class of phase clocks that checks the
>> timing mode bit.
>
> We've been over this quite some times already...
>
> How do you retrieve the mode used in the clock so that you can also
> switch the MMC driver in the new mode?

This part is covered. As mentioned above, the phase clks will return
-ENOTSUPP if the mmc clk is set in the new timing mode. The MMC driver
would try getting the current phase, check if it fails, and if it does,
realizes the clk is in new timing mode, and will switch the mmc controller
to it as well. I think this semantic fits the hardware well enough,
though it might be confusing without the accompanying comments.

See this commit for an example on how it should work.
https://github.com/wens/linux/commit/41e386f1f945a0a135a20a00601b977a001353da

> And do you prevent that from happening on the DT we already have that
> use the old clock drivers that do not support this new timing at all?

I admit this is not taken care of in this patch. Mostly because there
is no existing DT for the A83T to cater to. For the H3 and other SoCs
that do, we need some way of asking the CCU to switch the mode.

IIRC the output and sample clocks do not support a phase delay of 0.
So what if we design the semantic for this class of clocks as, if
phase == 0, switch to new timing mode, otherwise use old timing mode?
That would allow us to support this without adding extra functions,
and kind of matches what the hardware does. If you're using the new
timing mode, the delays in the mmc clk are bypassed.

Regards
ChenYu

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

[Chen-Yu Tsai]

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 delays no longer apply.
>>
>> Due to how the clock tree is modeled and setup, we need to model
>> this function in two places, the master mmc clock and the two
>> child phase clocks. In the mmc clock, we can easily model the
>> mode bit as an extra variable post-divider. In the phase clocks,
>> we check the bit and return -ENOTSUPP if the bit is set, signaling
>> that the phase clocks are not to be used.
>>
>> This patch introduces a class of phase clocks that checks the
>> timing mode bit.
>
> We've been over this quite some times already...
>
> How do you retrieve the mode used in the clock so that you can also
> switch the MMC driver in the new mode?

This part is covered. As mentioned above, the phase clks will return
-ENOTSUPP if the mmc clk is set in the new timing mode. The MMC driver
would try getting the current phase, check if it fails, and if it does,
realizes the clk is in new timing mode, and will switch the mmc controller
to it as well. I think this semantic fits the hardware well enough,
though it might be confusing without the accompanying comments.

See this commit for an example on how it should work.
https://github.com/wens/linux/commit/41e386f1f945a0a135a20a00601b977a001353da

> And do you prevent that from happening on the DT we already have that
> use the old clock drivers that do not support this new timing at all?

I admit this is not taken care of in this patch. Mostly because there
is no existing DT for the A83T to cater to. For the H3 and other SoCs
that do, we need some way of asking the CCU to switch the mode.

IIRC the output and sample clocks do not support a phase delay of 0.
So what if we design the semantic for this class of clocks as, if
phase == 0, switch to new timing mode, otherwise use old timing mode?
That would allow us to support this without adding extra functions,
and kind of matches what the hardware does. If you're using the new
timing mode, the delays in the mmc clk are bypassed.

Regards
ChenYu

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

[kernel test robot]

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 -smp 2 -m 1G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|   
   | 7984237c13 | 87c458e630 |
+--+++
| boot_successes
   | 0  | 6  |
| boot_failures 
   | 30 | 24 |
| invoked_oom-killer:gfp_mask=0x
   | 30 ||
| Mem-Info  
   | 30 ||
| Out_of_memory:Kill_process
   | 30 ||
| 
page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY),nodemask=(null)
 | 7  ||
| BUG:kernel_hang_in_test_stage 
   | 0  | 18 |
| WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule  
   | 0  | 14 |
+--+++



[   15.553978] WARNING: CPU: 0 PID: 9 at arch/x86/kernel/smp.c:127 
native_smp_send_reschedule+0x4f/0x68
[   15.556230] Modules linked in:
[   15.556868] CPU: 0 PID: 9 Comm: migration/0 Not tainted 
4.11.0-rc2-00091-g87c458e #1
[   15.558408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   15.560409] Call Trace:
[   15.560937]  dump_stack+0x61/0x7e
[   15.561604]  __warn+0xc2/0xdd
[   15.562219]  warn_slowpath_null+0x1d/0x1f
[   15.563027]  native_smp_send_reschedule+0x4f/0x68
[   15.564061]  resched_curr+0x9e/0x168
[   15.564792]  check_preempt_curr+0x4a/0x92
[   15.565592]  move_queued_task+0x1cc/0x1d6
[   15.566415]  __migrate_task+0x88/0x97
[   15.567158]  migration_cpu_stop+0x77/0xa4
[   15.567968]  ? sched_ttwu_pending+0xbd/0xbd
[   15.568815]  cpu_stopper_thread+0x84/0xf3
[   15.569613]  ? sort_range+0x22/0x22
[   15.570326]  smpboot_thread_fn+0x1cc/0x1e3
[   15.571164]  kthread+0x12d/0x135
[   15.571825]  ? kthread_create_on_node+0x3f/0x3f
[   15.572742]  ret_from_fork+0x2c/0x40
[   15.573468] ---[ end trace ce70cc5403b8b2a1 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.11.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y

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

[kernel test robot]

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 -smp 2 -m 1G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|   
   | 7984237c13 | 87c458e630 |
+--+++
| boot_successes
   | 0  | 6  |
| boot_failures 
   | 30 | 24 |
| invoked_oom-killer:gfp_mask=0x
   | 30 ||
| Mem-Info  
   | 30 ||
| Out_of_memory:Kill_process
   | 30 ||
| 
page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY),nodemask=(null)
 | 7  ||
| BUG:kernel_hang_in_test_stage 
   | 0  | 18 |
| WARNING:at_arch/x86/kernel/smp.c:#native_smp_send_reschedule  
   | 0  | 14 |
+--+++



[   15.553978] WARNING: CPU: 0 PID: 9 at arch/x86/kernel/smp.c:127 
native_smp_send_reschedule+0x4f/0x68
[   15.556230] Modules linked in:
[   15.556868] CPU: 0 PID: 9 Comm: migration/0 Not tainted 
4.11.0-rc2-00091-g87c458e #1
[   15.558408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   15.560409] Call Trace:
[   15.560937]  dump_stack+0x61/0x7e
[   15.561604]  __warn+0xc2/0xdd
[   15.562219]  warn_slowpath_null+0x1d/0x1f
[   15.563027]  native_smp_send_reschedule+0x4f/0x68
[   15.564061]  resched_curr+0x9e/0x168
[   15.564792]  check_preempt_curr+0x4a/0x92
[   15.565592]  move_queued_task+0x1cc/0x1d6
[   15.566415]  __migrate_task+0x88/0x97
[   15.567158]  migration_cpu_stop+0x77/0xa4
[   15.567968]  ? sched_ttwu_pending+0xbd/0xbd
[   15.568815]  cpu_stopper_thread+0x84/0xf3
[   15.569613]  ? sort_range+0x22/0x22
[   15.570326]  smpboot_thread_fn+0x1cc/0x1e3
[   15.571164]  kthread+0x12d/0x135
[   15.571825]  ? kthread_create_on_node+0x3f/0x3f
[   15.572742]  ret_from_fork+0x2c/0x40
[   15.573468] ---[ end trace ce70cc5403b8b2a1 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.11.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y

Re: net/ipv6: GPF in rt6_device_match

[David Ahern]

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 = -10, /* Must be called after addrconf_notify!! */
>  };
> 


It's not a notifier problem; the null_entry is created in ip6_route_init
which is an init function.

For network namespaces other than init_net, it is never initialized. See
ip6_route_net_init.

Re: net/ipv6: GPF in rt6_device_match

[David Ahern]

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 = -10, /* Must be called after addrconf_notify!! */
>  };
> 


It's not a notifier problem; the null_entry is created in ip6_route_init
which is an init function.

For network namespaces other than init_net, it is never initialized. See
ip6_route_net_init.

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

[kernel test robot]

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 -enable-kvm -cpu host -smp 2 -m 4G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | c0bbc7cf8b 
| 9f0f3ea314 |
+--+++
| boot_successes   | 6  
| 0  |
| boot_failures| 2  
| 8  |
| invoked_oom-killer:gfp_mask=0x   | 2  
| 2  |
| Mem-Info | 2  
| 2  |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 2  
| 2  |
| BUG:kernel_hang_in_test_stage| 0  
| 2  |
| BUG:KASAN:null-ptr-deref_on_address  | 0  
| 4  |
| BUG:unable_to_handle_kernel  | 0  
| 4  |
| Oops:#[##]   | 0  
| 4  |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 4  |
+--+++



[  276.979741] BUG: KASAN: null-ptr-deref on address 0390
[  276.979741] BUG: KASAN: null-ptr-deref on address 0390
[  276.979778] Read of size 8 by task swapper/1
[  276.979778] Read of size 8 by task swapper/1
[  276.979841] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.11.0-rc8-00089-g9f0f3ea #2
[  276.979841] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.11.0-rc8-00089-g9f0f3ea #2
[  276.979878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  276.979878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  276.979910] Call Trace:
[  276.979910] Call Trace:
[  276.980004]  dump_stack+0x19/0x1b
[  276.980004]  dump_stack+0x19/0x1b
[  276.980131]  kasan_report+0x467/0x560
[  276.980131]  kasan_report+0x467/0x560
[  276.980197]  ? swiotlb_map_page+0x54/0x248
[  276.980197]  ? swiotlb_map_page+0x54/0x248
[  276.980260]  ? kasan_unpoison_shadow+0x35/0x43
[  276.980260]  ? kasan_unpoison_shadow+0x35/0x43
[  276.980324]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980324]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980387]  __asan_load8+0x5e/0x6f
[  276.980387]  __asan_load8+0x5e/0x6f
[  276.980428]  swiotlb_map_page+0x54/0x248
[  276.980428]  swiotlb_map_page+0x54/0x248
[  276.980493]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980493]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980581]  fw_cfg_dma_transfer+0xb9/0x39c
[  276.980581]  fw_cfg_dma_transfer+0xb9/0x39c
[  276.980649]  fw_cfg_read_blob+0xf0/0x201
[  276.980649]  fw_cfg_read_blob+0xf0/0x201
[  276.980715]  ? fw_cfg_dma_transfer+0x39c/0x39c
[  276.980715]  ? fw_cfg_dma_transfer+0x39c/0x39c
[  276.980782]  ? __kmalloc+0x15f/0x304
[  276.980782]  ? __kmalloc+0x15f/0x304
[  276.980844]  ? fw_cfg_sysfs_probe+0x2c9/0x84a
[  276.980844]  ? fw_cfg_sysfs_probe+0x2c9/0x84a
[  276.980911]  fw_cfg_sysfs_probe+0x2f4/0x84a
[  276.980911]  fw_cfg_sysfs_probe+0x2f4/0x84a
[  276.980980]  ? fw_cfg_sysfs_read_raw+0x70/0x70
[  276.980980]  ? fw_cfg_sysfs_read_raw+0x70/0x70
[  276.981104]  ? acpi_device_wakeup+0x3d/0x110
[  276.981104]  ? acpi_device_wakeup+0x3d/0x110
[  276.981172]  ? acpi_dev_pm_attach+0xf0/0x12e
[  276.981172]  ? acpi_dev_pm_attach+0xf0/0x12e
[  276.981239]  platform_drv_probe+0x54/0xd2
[  276.981239]  platform_drv_probe+0x54/0xd2
[  276.981330]  driver_probe_device+0x2b1/0x730
[  276.981330]  driver_probe_device+0x2b1/0x730
[  276.981401]  ? driver_probe_device+0x730/0x730
[  276.981401]  ? driver_probe_device+0x730/0x730
[  276.981488]  __driver_attach+0x121/0x123
[  276.981488]  __driver_attach+0x121/0x123
[  276.981556]  bus_for_each_dev+0xeb/0x147
[  276.981556]  bus_for_each_dev+0xeb/0x147
[  276.981623]  ? store_drivers_autoprobe+0x80/0x80
[  276.981623]  ? store_drivers_autoprobe+0x80/0x80
[  276.981688]  ? _raw_spin_unlock+0x27/0x3a
[  276.981688]  ? _raw_spin_unlock+0x27/0x3a
[  276.981756]  driver_attach+0x2b/0x2e
[  276.981756]  driver_attach+0x2b/0x2e
[  276.981823]  bus_add_driver+0x27e/0x39c
[  276.981823]  bus_add_driver+0x27e/0x39c
[  276.981887]  driver_register+0xd3/0x193
[  276.981887]  driver_register+0xd3/0x193
[  276.981975]  ? firmware_map_add_early+0x5b/0x5b
[  276.981975]  ? 

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

[kernel test robot]

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 -enable-kvm -cpu host -smp 2 -m 4G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | c0bbc7cf8b 
| 9f0f3ea314 |
+--+++
| boot_successes   | 6  
| 0  |
| boot_failures| 2  
| 8  |
| invoked_oom-killer:gfp_mask=0x   | 2  
| 2  |
| Mem-Info | 2  
| 2  |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 2  
| 2  |
| BUG:kernel_hang_in_test_stage| 0  
| 2  |
| BUG:KASAN:null-ptr-deref_on_address  | 0  
| 4  |
| BUG:unable_to_handle_kernel  | 0  
| 4  |
| Oops:#[##]   | 0  
| 4  |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 4  |
+--+++



[  276.979741] BUG: KASAN: null-ptr-deref on address 0390
[  276.979741] BUG: KASAN: null-ptr-deref on address 0390
[  276.979778] Read of size 8 by task swapper/1
[  276.979778] Read of size 8 by task swapper/1
[  276.979841] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.11.0-rc8-00089-g9f0f3ea #2
[  276.979841] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.11.0-rc8-00089-g9f0f3ea #2
[  276.979878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  276.979878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[  276.979910] Call Trace:
[  276.979910] Call Trace:
[  276.980004]  dump_stack+0x19/0x1b
[  276.980004]  dump_stack+0x19/0x1b
[  276.980131]  kasan_report+0x467/0x560
[  276.980131]  kasan_report+0x467/0x560
[  276.980197]  ? swiotlb_map_page+0x54/0x248
[  276.980197]  ? swiotlb_map_page+0x54/0x248
[  276.980260]  ? kasan_unpoison_shadow+0x35/0x43
[  276.980260]  ? kasan_unpoison_shadow+0x35/0x43
[  276.980324]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980324]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980387]  __asan_load8+0x5e/0x6f
[  276.980387]  __asan_load8+0x5e/0x6f
[  276.980428]  swiotlb_map_page+0x54/0x248
[  276.980428]  swiotlb_map_page+0x54/0x248
[  276.980493]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980493]  ? swiotlb_free_coherent+0x9a/0x9a
[  276.980581]  fw_cfg_dma_transfer+0xb9/0x39c
[  276.980581]  fw_cfg_dma_transfer+0xb9/0x39c
[  276.980649]  fw_cfg_read_blob+0xf0/0x201
[  276.980649]  fw_cfg_read_blob+0xf0/0x201
[  276.980715]  ? fw_cfg_dma_transfer+0x39c/0x39c
[  276.980715]  ? fw_cfg_dma_transfer+0x39c/0x39c
[  276.980782]  ? __kmalloc+0x15f/0x304
[  276.980782]  ? __kmalloc+0x15f/0x304
[  276.980844]  ? fw_cfg_sysfs_probe+0x2c9/0x84a
[  276.980844]  ? fw_cfg_sysfs_probe+0x2c9/0x84a
[  276.980911]  fw_cfg_sysfs_probe+0x2f4/0x84a
[  276.980911]  fw_cfg_sysfs_probe+0x2f4/0x84a
[  276.980980]  ? fw_cfg_sysfs_read_raw+0x70/0x70
[  276.980980]  ? fw_cfg_sysfs_read_raw+0x70/0x70
[  276.981104]  ? acpi_device_wakeup+0x3d/0x110
[  276.981104]  ? acpi_device_wakeup+0x3d/0x110
[  276.981172]  ? acpi_dev_pm_attach+0xf0/0x12e
[  276.981172]  ? acpi_dev_pm_attach+0xf0/0x12e
[  276.981239]  platform_drv_probe+0x54/0xd2
[  276.981239]  platform_drv_probe+0x54/0xd2
[  276.981330]  driver_probe_device+0x2b1/0x730
[  276.981330]  driver_probe_device+0x2b1/0x730
[  276.981401]  ? driver_probe_device+0x730/0x730
[  276.981401]  ? driver_probe_device+0x730/0x730
[  276.981488]  __driver_attach+0x121/0x123
[  276.981488]  __driver_attach+0x121/0x123
[  276.981556]  bus_for_each_dev+0xeb/0x147
[  276.981556]  bus_for_each_dev+0xeb/0x147
[  276.981623]  ? store_drivers_autoprobe+0x80/0x80
[  276.981623]  ? store_drivers_autoprobe+0x80/0x80
[  276.981688]  ? _raw_spin_unlock+0x27/0x3a
[  276.981688]  ? _raw_spin_unlock+0x27/0x3a
[  276.981756]  driver_attach+0x2b/0x2e
[  276.981756]  driver_attach+0x2b/0x2e
[  276.981823]  bus_add_driver+0x27e/0x39c
[  276.981823]  bus_add_driver+0x27e/0x39c
[  276.981887]  driver_register+0xd3/0x193
[  276.981887]  driver_register+0xd3/0x193
[  276.981975]  ? firmware_map_add_early+0x5b/0x5b
[  276.981975]  ? 

deadlock due to circular dependency between threads

[Sodagudi Prasad]

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 is running on 
core5.
1) Cpu hot plug flow needs to flush the work items on hot plugging CPU3, 
with a high priority worker from the corresponding CPU’s(cpu3) worker 
pool.
2) There are no high priority workers on the CPU3 worker pool, so 
create_worker was initiated to create high priority kernel 
thread/worker.
3) This thread creation should be done by kthreadd demon, but kthreadd  
demon have got stuck in some other thread creation. At this point of 
time kthreadd creating a thread and updating cgroup settings and waiting 
on rw semaphore of cgroup subsystem.
4) Cgroup readwrite semaphore is taken by "init" thread and waiting on 
cpuset mutex lock. init task is updating cgroup's based on userspace 
request.
5) Cpuset mutex lock is taken by "kworker:5/1" and it is waiting for 
cpuhotplug lock.

Cpuhotplug mutex is taken by "ABC_XYZ" hotplugging thread. DEADLOCK!

circular dependency between threads:-
"kthread_XYZ" ==> "kthreadd" ==> "init"  ==> "kworker/5:1" ==> 
"kthread_XYZ"



PID: 910TASK: ffc0ee8dd780  CPU: 5   COMMAND: "ABC_XYZ"
 #0 [ffc0ee9cb900] __switch_to at ff800808553c
 #1 [ffc0ee9cb930] __schedule at ff8008d76aa0
 #2 [ffc0ee9cb990] schedule at ff8008d76e04
 #3 [ffc0ee9cb9b0] schedule_timeout at ff8008d7953c
 #4 [ffc0ee9cba60] wait_for_common at ff8008d77888
 #5 [ffc0ee9cbaf0] wait_for_completion at ff8008d778dc
 #6 [ffc0ee9cbb00] flush_work at ff80080b3850
 #7 [ffc0ee9cbb80] workqueue_cpu_down_callback at ff80080b5360
 #8 [ffc0ee9cbbc0] notifier_call_chain at ff80080b9c4c
 #9 [ffc0ee9cbc00] __raw_notifier_call_chain at ff80080b9cb8
#10 [ffc0ee9cbc10] __cpu_notify at ff800809eb50
#11 [ffc0ee9cbc20] _cpu_down at ff800809ee84
#12 [ffc0ee9cbca0] cpu_down at ff800809f124
#13 [ffc0ee9cbcd0] cpu_subsys_offline at ff800856b768
#14 [ffc0ee9cbce0] device_offline at ff8008567040
#15 [ffc0ee9cbd10] update_offline_cores at ff8008d74b54
#16 [ffc0ee9cbda0] do_hotplug at ff8008d75358
#17 [ffc0ee9cbe20] kthread at ff80080b8e3c



PID: 2  TASK: ffc0f9660c80  CPU: 4   COMMAND: "kthreadd"
 #0 [ffc0f9683bf0] __switch_to at ff800808553c
 #1 [ffc0f9683c20] __schedule at ff8008d76aa0
 #2 [ffc0f9683c80] schedule at ff8008d76e04
 #3 [ffc0f9683ca0] rwsem_down_read_failed at ff8008d79144
 #4 [ffc0f9683cf0] __percpu_down_read at ff80080edc4c
 #5 [ffc0f9683d10] copy_process at ff800809cecc
 #6 [ffc0f9683df0] _do_fork at ff800809d5a0
 #7 [ffc0f9683e50] kernel_thread at ff800809d89c
 #8 [ffc0f9683e60] kthreadd at ff80080b9714


PID: 898TASK: ffc0ee91  CPU: 0   COMMAND: "init"
 #0 [ffc06fd93980] __switch_to at ff800808553c
 #1 [ffc06fd939b0] __schedule at ff8008d76aa0
 #2 [ffc06fd93a10] schedule at ff8008d76e04
 #3 [ffc06fd93a30] schedule_preempt_disabled at ff8008d7714c
 #4 [ffc06fd93a50] __mutex_lock_slowpath at ff8008d78684
 #5 [ffc06fd93ab0] mutex_lock at ff8008d78714
 #6 [ffc06fd93ad0] cpuset_can_attach at ff800812d490
 #7 [ffc06fd93b20] cgroup_taskset_migrate at ff8008129194
 #8 [ffc06fd93b70] cgroup_migrate at ff8008129454
 #9 [ffc06fd93bf0] cgroup_attach_task at ff800812950c
#10 [ffc06fd93c50] __cgroup_procs_write at ff8008129884
#11 [ffc06fd93d10] cgroup_tasks_write at ff800812993c
#12 [ffc06fd93d20] cgroup_file_write at ff8008125078
#13 [ffc06fd93d70] kernfs_fop_write at ff800820bef4
#14 [ffc06fd93db0] __vfs_write at ff80081ac6f4
#15 [ffc06fd93e30] vfs_write at ff80081acf28
#16 [ffc06fd93e70] sys_write at ff80081ad6d8
#17 [ffc06fd93ed0] el0_svc_naked at ff800808462



PID: 66 TASK: ffc020dc7080  CPU: 5   COMMAND: "kworker/5:1"
 #0 [ffc0f7ff3a90] __switch_to at ff800808553c
 #1 [ffc0f7ff3ac0] __schedule at ff8008d76aa0
 #2 [ffc0f7ff3b20] schedule at ff8008d76e04
 #3 [ffc0f7ff3b40] schedule_preempt_disabled at ff8008d7714c
 #4 [ffc0f7ff3b60] __mutex_lock_slowpath at ff8008d78684
 #5 [ffc0f7ff3bc0] mutex_lock at ff8008d78714
 #6 [ffc0f7ff3be0] get_online_cpus at ff800809e9bc
 #7 [ffc0f7ff3c00] rebuild_sched_domains_locked at ff800812c960
 #8 [ffc0f7ff3cb0] rebuild_sched_domains at ff800812e7bc
 #9 [ffc0f7ff3cd0] cpuset_hotplug_workfn at ff800812eca8
#10 [ffc0f7ff3d70] process_one_work at ff80080b3cec
#11 [ffc0f7ff3dc0] worker_thread at ff80080b4700
#12 [ffc0f7ff3e20] kthread at ff80080b8e3c

I think, we can avoid this DEADLOCK 

deadlock due to circular dependency between threads

[Sodagudi Prasad]

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 is running on 
core5.
1) Cpu hot plug flow needs to flush the work items on hot plugging CPU3, 
with a high priority worker from the corresponding CPU’s(cpu3) worker 
pool.
2) There are no high priority workers on the CPU3 worker pool, so 
create_worker was initiated to create high priority kernel 
thread/worker.
3) This thread creation should be done by kthreadd demon, but kthreadd  
demon have got stuck in some other thread creation. At this point of 
time kthreadd creating a thread and updating cgroup settings and waiting 
on rw semaphore of cgroup subsystem.
4) Cgroup readwrite semaphore is taken by "init" thread and waiting on 
cpuset mutex lock. init task is updating cgroup's based on userspace 
request.
5) Cpuset mutex lock is taken by "kworker:5/1" and it is waiting for 
cpuhotplug lock.

Cpuhotplug mutex is taken by "ABC_XYZ" hotplugging thread. DEADLOCK!

circular dependency between threads:-
"kthread_XYZ" ==> "kthreadd" ==> "init"  ==> "kworker/5:1" ==> 
"kthread_XYZ"



PID: 910TASK: ffc0ee8dd780  CPU: 5   COMMAND: "ABC_XYZ"
 #0 [ffc0ee9cb900] __switch_to at ff800808553c
 #1 [ffc0ee9cb930] __schedule at ff8008d76aa0
 #2 [ffc0ee9cb990] schedule at ff8008d76e04
 #3 [ffc0ee9cb9b0] schedule_timeout at ff8008d7953c
 #4 [ffc0ee9cba60] wait_for_common at ff8008d77888
 #5 [ffc0ee9cbaf0] wait_for_completion at ff8008d778dc
 #6 [ffc0ee9cbb00] flush_work at ff80080b3850
 #7 [ffc0ee9cbb80] workqueue_cpu_down_callback at ff80080b5360
 #8 [ffc0ee9cbbc0] notifier_call_chain at ff80080b9c4c
 #9 [ffc0ee9cbc00] __raw_notifier_call_chain at ff80080b9cb8
#10 [ffc0ee9cbc10] __cpu_notify at ff800809eb50
#11 [ffc0ee9cbc20] _cpu_down at ff800809ee84
#12 [ffc0ee9cbca0] cpu_down at ff800809f124
#13 [ffc0ee9cbcd0] cpu_subsys_offline at ff800856b768
#14 [ffc0ee9cbce0] device_offline at ff8008567040
#15 [ffc0ee9cbd10] update_offline_cores at ff8008d74b54
#16 [ffc0ee9cbda0] do_hotplug at ff8008d75358
#17 [ffc0ee9cbe20] kthread at ff80080b8e3c



PID: 2  TASK: ffc0f9660c80  CPU: 4   COMMAND: "kthreadd"
 #0 [ffc0f9683bf0] __switch_to at ff800808553c
 #1 [ffc0f9683c20] __schedule at ff8008d76aa0
 #2 [ffc0f9683c80] schedule at ff8008d76e04
 #3 [ffc0f9683ca0] rwsem_down_read_failed at ff8008d79144
 #4 [ffc0f9683cf0] __percpu_down_read at ff80080edc4c
 #5 [ffc0f9683d10] copy_process at ff800809cecc
 #6 [ffc0f9683df0] _do_fork at ff800809d5a0
 #7 [ffc0f9683e50] kernel_thread at ff800809d89c
 #8 [ffc0f9683e60] kthreadd at ff80080b9714


PID: 898TASK: ffc0ee91  CPU: 0   COMMAND: "init"
 #0 [ffc06fd93980] __switch_to at ff800808553c
 #1 [ffc06fd939b0] __schedule at ff8008d76aa0
 #2 [ffc06fd93a10] schedule at ff8008d76e04
 #3 [ffc06fd93a30] schedule_preempt_disabled at ff8008d7714c
 #4 [ffc06fd93a50] __mutex_lock_slowpath at ff8008d78684
 #5 [ffc06fd93ab0] mutex_lock at ff8008d78714
 #6 [ffc06fd93ad0] cpuset_can_attach at ff800812d490
 #7 [ffc06fd93b20] cgroup_taskset_migrate at ff8008129194
 #8 [ffc06fd93b70] cgroup_migrate at ff8008129454
 #9 [ffc06fd93bf0] cgroup_attach_task at ff800812950c
#10 [ffc06fd93c50] __cgroup_procs_write at ff8008129884
#11 [ffc06fd93d10] cgroup_tasks_write at ff800812993c
#12 [ffc06fd93d20] cgroup_file_write at ff8008125078
#13 [ffc06fd93d70] kernfs_fop_write at ff800820bef4
#14 [ffc06fd93db0] __vfs_write at ff80081ac6f4
#15 [ffc06fd93e30] vfs_write at ff80081acf28
#16 [ffc06fd93e70] sys_write at ff80081ad6d8
#17 [ffc06fd93ed0] el0_svc_naked at ff800808462



PID: 66 TASK: ffc020dc7080  CPU: 5   COMMAND: "kworker/5:1"
 #0 [ffc0f7ff3a90] __switch_to at ff800808553c
 #1 [ffc0f7ff3ac0] __schedule at ff8008d76aa0
 #2 [ffc0f7ff3b20] schedule at ff8008d76e04
 #3 [ffc0f7ff3b40] schedule_preempt_disabled at ff8008d7714c
 #4 [ffc0f7ff3b60] __mutex_lock_slowpath at ff8008d78684
 #5 [ffc0f7ff3bc0] mutex_lock at ff8008d78714
 #6 [ffc0f7ff3be0] get_online_cpus at ff800809e9bc
 #7 [ffc0f7ff3c00] rebuild_sched_domains_locked at ff800812c960
 #8 [ffc0f7ff3cb0] rebuild_sched_domains at ff800812e7bc
 #9 [ffc0f7ff3cd0] cpuset_hotplug_workfn at ff800812eca8
#10 [ffc0f7ff3d70] process_one_work at ff80080b3cec
#11 [ffc0f7ff3dc0] worker_thread at ff80080b4700
#12 [ffc0f7ff3e20] kthread at ff80080b8e3c

I think, we can avoid this DEADLOCK 

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

[Zefan Li]

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 event in intel_cqm_sched_in_event().

Besides there's another bug that we retry rotating without resetting
nr_needed and start in __intel_cqm_rmid_rotate().

Those bugs combined together led to the following oops.

WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 
__put_rmid+0x28/0x80()
...
 [] __put_rmid+0x28/0x80
 [] intel_cqm_rmid_rotate+0xba/0x440
 [] process_one_work+0x17b/0x470
 [] worker_thread+0x11b/0x400
...
BUG: unable to handle kernel NULL pointer dereference at   (null)
...
 [] intel_cqm_rmid_rotate+0xba/0x440
 [] process_one_work+0x17b/0x470
 [] worker_thread+0x11b/0x400

Cc: sta...@vger.kernel.org
Signed-off-by: Zefan Li 
---
 arch/x86/events/intel/cqm.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/cqm.c b/arch/x86/events/intel/cqm.c
index 8c00dc0..c06a5ba 100644
--- a/arch/x86/events/intel/cqm.c
+++ b/arch/x86/events/intel/cqm.c
@@ -553,8 +553,13 @@ static bool intel_cqm_sched_in_event(u32 rmid)
 
leader = list_first_entry(_groups, struct perf_event,
  hw.cqm_groups_entry);
-   event = leader;
 
+   if (!list_empty(_groups) && !__rmid_valid(leader->hw.cqm_rmid)) {
+   intel_cqm_xchg_rmid(leader, rmid);
+   return true;
+   }
+
+   event = leader;
list_for_each_entry_continue(event, _groups,
 hw.cqm_groups_entry) {
if (__rmid_valid(event->hw.cqm_rmid))
@@ -721,6 +726,7 @@ static void intel_cqm_sched_out_conflicting_events(struct 
perf_event *event)
 {
struct perf_event *group, *g;
u32 rmid;
+   LIST_HEAD(conflicting_groups);
 
lockdep_assert_held(_mutex);
 
@@ -744,7 +750,11 @@ static void intel_cqm_sched_out_conflicting_events(struct 
perf_event *event)
 
intel_cqm_xchg_rmid(group, INVALID_RMID);
__put_rmid(rmid);
+   list_move_tail(>hw.cqm_groups_entry,
+  _groups);
}
+
+   list_splice_tail(_groups, _groups);
 }
 
 /*
@@ -773,9 +783,9 @@ static void intel_cqm_sched_out_conflicting_events(struct 
perf_event *event)
  */
 static bool __intel_cqm_rmid_rotate(void)
 {
-   struct perf_event *group, *start = NULL;
+   struct perf_event *group, *start;
unsigned int threshold_limit;
-   unsigned int nr_needed = 0;
+   unsigned int nr_needed;
unsigned int nr_available;
bool rotated = false;
 
@@ -789,6 +799,9 @@ static bool __intel_cqm_rmid_rotate(void)
if (list_empty(_groups) && list_empty(_rmid_limbo_lru))
goto out;
 
+   nr_needed = 0;
+   start = NULL;
+
list_for_each_entry(group, _groups, hw.cqm_groups_entry) {
if (!__rmid_valid(group->hw.cqm_rmid)) {
if (!start)
-- 
1.8.2.2

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

[Zefan Li]

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 event in intel_cqm_sched_in_event().

Besides there's another bug that we retry rotating without resetting
nr_needed and start in __intel_cqm_rmid_rotate().

Those bugs combined together led to the following oops.

WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 
__put_rmid+0x28/0x80()
...
 [] __put_rmid+0x28/0x80
 [] intel_cqm_rmid_rotate+0xba/0x440
 [] process_one_work+0x17b/0x470
 [] worker_thread+0x11b/0x400
...
BUG: unable to handle kernel NULL pointer dereference at   (null)
...
 [] intel_cqm_rmid_rotate+0xba/0x440
 [] process_one_work+0x17b/0x470
 [] worker_thread+0x11b/0x400

Cc: sta...@vger.kernel.org
Signed-off-by: Zefan Li 
---
 arch/x86/events/intel/cqm.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/cqm.c b/arch/x86/events/intel/cqm.c
index 8c00dc0..c06a5ba 100644
--- a/arch/x86/events/intel/cqm.c
+++ b/arch/x86/events/intel/cqm.c
@@ -553,8 +553,13 @@ static bool intel_cqm_sched_in_event(u32 rmid)
 
leader = list_first_entry(_groups, struct perf_event,
  hw.cqm_groups_entry);
-   event = leader;
 
+   if (!list_empty(_groups) && !__rmid_valid(leader->hw.cqm_rmid)) {
+   intel_cqm_xchg_rmid(leader, rmid);
+   return true;
+   }
+
+   event = leader;
list_for_each_entry_continue(event, _groups,
 hw.cqm_groups_entry) {
if (__rmid_valid(event->hw.cqm_rmid))
@@ -721,6 +726,7 @@ static void intel_cqm_sched_out_conflicting_events(struct 
perf_event *event)
 {
struct perf_event *group, *g;
u32 rmid;
+   LIST_HEAD(conflicting_groups);
 
lockdep_assert_held(_mutex);
 
@@ -744,7 +750,11 @@ static void intel_cqm_sched_out_conflicting_events(struct 
perf_event *event)
 
intel_cqm_xchg_rmid(group, INVALID_RMID);
__put_rmid(rmid);
+   list_move_tail(>hw.cqm_groups_entry,
+  _groups);
}
+
+   list_splice_tail(_groups, _groups);
 }
 
 /*
@@ -773,9 +783,9 @@ static void intel_cqm_sched_out_conflicting_events(struct 
perf_event *event)
  */
 static bool __intel_cqm_rmid_rotate(void)
 {
-   struct perf_event *group, *start = NULL;
+   struct perf_event *group, *start;
unsigned int threshold_limit;
-   unsigned int nr_needed = 0;
+   unsigned int nr_needed;
unsigned int nr_available;
bool rotated = false;
 
@@ -789,6 +799,9 @@ static bool __intel_cqm_rmid_rotate(void)
if (list_empty(_groups) && list_empty(_rmid_limbo_lru))
goto out;
 
+   nr_needed = 0;
+   start = NULL;
+
list_for_each_entry(group, _groups, hw.cqm_groups_entry) {
if (!__rmid_valid(group->hw.cqm_rmid)) {
if (!start)
-- 
1.8.2.2

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

[Dan Williams]

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 because the for loop count calculation in sync_global_pgds is
> not correct. When a mapping area crosses pgd entries, we should
> calculate the starting address of region which next pgd covers and assign
> it to next for loop count, but not add PGDIR_SIZE directly. The old
> code works right only if the mapping area is times of PGDIR_SIZE,
> otherwize the end region could be skipped so that it can't be synchronized
> to all other processes from kernel pgd init_mm.pgd.
>
> In Jeff's system, emulated pmem area [1024G, 1216G) is smaller than
> PGDIR_SIZE. While 'nokaslr' works because PAGE_OFFSET is 1T aligned, it
> makes this area be mapped inside one pgd entry. With kaslr enabled,
> this area could cross two pgd entries, then the next pgd entry won't
> be synced to all other processes. That is why we saw empty PGD.
>
> Fix it in this patch.
>
> The back trace is pasted as below:
>
> [9.988867] IP: memcpy_erms+0x6/0x10
> [9.988868] PGD 0
> [9.988868]
> [9.988870] Oops:  [#1] SMP
> [9.988871] Modules linked in: isci(E) mgag200(E+) drm_kms_helper(E) 
> syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) igb(E) ahci(E) 
> ttm(E) libsas(E) libahci(E) scsi_transport_sas(E) ptp(E) pps_core(E) 
> nd_pmem(E) dca(E) drm(E) i2c_algo_bit(E) libata(E) crc32c_intel(E) nd_btt(E)
> i2c_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
> [9.96] CPU: 0 PID: 442 Comm: systemd-udevd Tainted: GE   
> 4.11.0-rc5+ #43
> [9.97] Hardware name: Intel Corporation LH Pass/SVRBD-ROW_P, BIOS 
> SE5C600.86B.02.01.SP06.050920141054 05/09/2014
> [9.98] task: 9267dc2f8000 task.stack: ba92c783c000
> [9.988890] RIP: 0010:memcpy_erms+0x6/0x10
> [9.988891] RSP: 0018:ba92c783f9b8 EFLAGS: 00010286
> [9.988892] RAX: 925f19e27000 RBX:  RCX: 
> 1000
> [9.988893] RDX: 1000 RSI: 9387bfff RDI: 
> 925f19e27000
> [9.988893] RBP: ba92c783fa38 R08:  R09: 
> 1780
> [9.988894] R10:  R11: 9387bfff R12: 
> 925fde811ed8
> [9.988895] R13: 002f R14: 1000 R15: 
> 925f19e27000
> [9.988896] FS:  7f1ee18e68c0() GS:925fdec0() 
> knlGS:
> [9.988896] CS:  0010 DS:  ES:  CR0: 80050033
> [9.988897] CR2: 9387bfff CR3: 00081ba28000 CR4: 
> 001406f0
> [9.988897] Call Trace:
> [9.988902]  ? pmem_do_bvec+0x93/0x290 [nd_pmem]
> [9.988904]  ? radix_tree_node_alloc.constprop.20+0x85/0xc0
> [9.988905]  ? radix_tree_node_alloc.constprop.20+0x85/0xc0
> [9.988907]  pmem_rw_page+0x3a/0x60 [nd_pmem]
> [9.988909]  bdev_read_page+0x81/0xb0
> [9.988911]  do_mpage_readpage+0x56f/0x770
> [9.988912]  ? I_BDEV+0x20/0x20
> [9.988915]  ? lru_cache_add+0xe/0x10
> [9.988917]  mpage_readpages+0x148/0x1e0
> [9.988917]  ? I_BDEV+0x20/0x20
> [9.988918]  ? I_BDEV+0x20/0x20
> [9.988921]  ? alloc_pages_current+0x88/0x120
> [9.988923]  blkdev_readpages+0x1d/0x20
> [9.988924]  __do_page_cache_readahead+0x1ce/0x2c0
> [9.988926]  force_page_cache_readahead+0xa2/0x100
> [9.988927]  page_cache_sync_readahead+0x3f/0x50
> [9.988930]  generic_file_read_iter+0x60d/0x8c0
> [9.988931]  blkdev_read_iter+0x37/0x40
> [9.988933]  __vfs_read+0xe0/0x150
> [9.988934]  vfs_read+0x8c/0x130
> [9.988936]  SyS_read+0x55/0xc0
> [9.988939]  entry_SYSCALL_64_fastpath+0x1a/0xa9
> [9.988940] RIP: 0033:0x7f1ee0822480
> [9.988941] RSP: 002b:7ffcf9e741f8 EFLAGS: 0246 ORIG_RAX: 
> 
> [9.988942] RAX: ffda RBX:  RCX: 
> 7f1ee0822480
> [9.988943] RDX: 0040 RSI: 561b7e1aabc8 RDI: 
> 0008
> [9.988943] RBP: 561b7e1a86a0 R08: 0005 R09: 
> 0068
> [9.988944] R10: 7ffcf9e73f80 R11: 0246 R12: 
> 
> [9.988945] R13: 0001 R14: 561b7e1a61b0 R15: 
> 561b7e1a55e0
> [9.988946] Code: ff 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 
> 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1  
> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38
> [9.988962] RIP: memcpy_erms+0x6/0x10 RSP: ba92c783f9b8
> [9.988962] CR2: 9387bfff
> [9.989022] ---[ end trace fe34c0fc0fe685ab ]---
> [9.998690] Kernel panic - not syncing: Fatal exception
> [   10.004708] Kernel Offset: 0x1100 from 0x8100 (relocation 
> range: 0x8000-0xbfff)
>
> 

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

[Dan Williams]

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 because the for loop count calculation in sync_global_pgds is
> not correct. When a mapping area crosses pgd entries, we should
> calculate the starting address of region which next pgd covers and assign
> it to next for loop count, but not add PGDIR_SIZE directly. The old
> code works right only if the mapping area is times of PGDIR_SIZE,
> otherwize the end region could be skipped so that it can't be synchronized
> to all other processes from kernel pgd init_mm.pgd.
>
> In Jeff's system, emulated pmem area [1024G, 1216G) is smaller than
> PGDIR_SIZE. While 'nokaslr' works because PAGE_OFFSET is 1T aligned, it
> makes this area be mapped inside one pgd entry. With kaslr enabled,
> this area could cross two pgd entries, then the next pgd entry won't
> be synced to all other processes. That is why we saw empty PGD.
>
> Fix it in this patch.
>
> The back trace is pasted as below:
>
> [9.988867] IP: memcpy_erms+0x6/0x10
> [9.988868] PGD 0
> [9.988868]
> [9.988870] Oops:  [#1] SMP
> [9.988871] Modules linked in: isci(E) mgag200(E+) drm_kms_helper(E) 
> syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) igb(E) ahci(E) 
> ttm(E) libsas(E) libahci(E) scsi_transport_sas(E) ptp(E) pps_core(E) 
> nd_pmem(E) dca(E) drm(E) i2c_algo_bit(E) libata(E) crc32c_intel(E) nd_btt(E)
> i2c_core(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
> [9.96] CPU: 0 PID: 442 Comm: systemd-udevd Tainted: GE   
> 4.11.0-rc5+ #43
> [9.97] Hardware name: Intel Corporation LH Pass/SVRBD-ROW_P, BIOS 
> SE5C600.86B.02.01.SP06.050920141054 05/09/2014
> [9.98] task: 9267dc2f8000 task.stack: ba92c783c000
> [9.988890] RIP: 0010:memcpy_erms+0x6/0x10
> [9.988891] RSP: 0018:ba92c783f9b8 EFLAGS: 00010286
> [9.988892] RAX: 925f19e27000 RBX:  RCX: 
> 1000
> [9.988893] RDX: 1000 RSI: 9387bfff RDI: 
> 925f19e27000
> [9.988893] RBP: ba92c783fa38 R08:  R09: 
> 1780
> [9.988894] R10:  R11: 9387bfff R12: 
> 925fde811ed8
> [9.988895] R13: 002f R14: 1000 R15: 
> 925f19e27000
> [9.988896] FS:  7f1ee18e68c0() GS:925fdec0() 
> knlGS:
> [9.988896] CS:  0010 DS:  ES:  CR0: 80050033
> [9.988897] CR2: 9387bfff CR3: 00081ba28000 CR4: 
> 001406f0
> [9.988897] Call Trace:
> [9.988902]  ? pmem_do_bvec+0x93/0x290 [nd_pmem]
> [9.988904]  ? radix_tree_node_alloc.constprop.20+0x85/0xc0
> [9.988905]  ? radix_tree_node_alloc.constprop.20+0x85/0xc0
> [9.988907]  pmem_rw_page+0x3a/0x60 [nd_pmem]
> [9.988909]  bdev_read_page+0x81/0xb0
> [9.988911]  do_mpage_readpage+0x56f/0x770
> [9.988912]  ? I_BDEV+0x20/0x20
> [9.988915]  ? lru_cache_add+0xe/0x10
> [9.988917]  mpage_readpages+0x148/0x1e0
> [9.988917]  ? I_BDEV+0x20/0x20
> [9.988918]  ? I_BDEV+0x20/0x20
> [9.988921]  ? alloc_pages_current+0x88/0x120
> [9.988923]  blkdev_readpages+0x1d/0x20
> [9.988924]  __do_page_cache_readahead+0x1ce/0x2c0
> [9.988926]  force_page_cache_readahead+0xa2/0x100
> [9.988927]  page_cache_sync_readahead+0x3f/0x50
> [9.988930]  generic_file_read_iter+0x60d/0x8c0
> [9.988931]  blkdev_read_iter+0x37/0x40
> [9.988933]  __vfs_read+0xe0/0x150
> [9.988934]  vfs_read+0x8c/0x130
> [9.988936]  SyS_read+0x55/0xc0
> [9.988939]  entry_SYSCALL_64_fastpath+0x1a/0xa9
> [9.988940] RIP: 0033:0x7f1ee0822480
> [9.988941] RSP: 002b:7ffcf9e741f8 EFLAGS: 0246 ORIG_RAX: 
> 
> [9.988942] RAX: ffda RBX:  RCX: 
> 7f1ee0822480
> [9.988943] RDX: 0040 RSI: 561b7e1aabc8 RDI: 
> 0008
> [9.988943] RBP: 561b7e1a86a0 R08: 0005 R09: 
> 0068
> [9.988944] R10: 7ffcf9e73f80 R11: 0246 R12: 
> 
> [9.988945] R13: 0001 R14: 561b7e1a61b0 R15: 
> 561b7e1a55e0
> [9.988946] Code: ff 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 
> 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1  
> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38
> [9.988962] RIP: memcpy_erms+0x6/0x10 RSP: ba92c783f9b8
> [9.988962] CR2: 9387bfff
> [9.989022] ---[ end trace fe34c0fc0fe685ab ]---
> [9.998690] Kernel panic - not syncing: Fatal exception
> [   10.004708] Kernel Offset: 0x1100 from 0x8100 (relocation 
> range: 0x8000-0xbfff)
>
> Reported-by: Jeff Moyer 

Re: I'd like to donate a MacBook Pro

[Alex Henrie]

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 stop working entirely. The last commit that worked for me was
>> >> c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long
>> >> series of commits where the screen stays black, and after that, I
>> >> start getting errors like the one above.
>> >
>> > So git bisect said that commit was a good change, what one was the "bad"
>> > commit that git bisect pointed at?
>>
>> The commit right after that, but it's not clear whether the screen
>> blanking problem was part of the same bug or just another bug that was
>> introduced at about the same time.
>
> That would be 39ab9555c24110671f8dc671311a26e5c985b592:
>
> iommu: Add sysfs bindings for struct iommu_device
>
> And it introduced a regression when iommu-sysfs entries are accessed.
> This is fixed in a7fdb6e648fb.
>
> Does that commit fix the screen blanking problem?

At a7fdb6e648fb the screen works but the keyboard is broken. I think
that the screen was actually fixed by an earlier commit, but when I
tried to run a regression test to find when the keyboard problem
appeared after the screen was fixed, I gave up because testing each
revision takes about half an hour and the keyboard problem appears to
be somewhat intermittent.

-Alex

Re: I'd like to donate a MacBook Pro

[Alex Henrie]

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 stop working entirely. The last commit that worked for me was
>> >> c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long
>> >> series of commits where the screen stays black, and after that, I
>> >> start getting errors like the one above.
>> >
>> > So git bisect said that commit was a good change, what one was the "bad"
>> > commit that git bisect pointed at?
>>
>> The commit right after that, but it's not clear whether the screen
>> blanking problem was part of the same bug or just another bug that was
>> introduced at about the same time.
>
> That would be 39ab9555c24110671f8dc671311a26e5c985b592:
>
> iommu: Add sysfs bindings for struct iommu_device
>
> And it introduced a regression when iommu-sysfs entries are accessed.
> This is fixed in a7fdb6e648fb.
>
> Does that commit fix the screen blanking problem?

At a7fdb6e648fb the screen works but the keyboard is broken. I think
that the screen was actually fixed by an earlier commit, but when I
tried to run a regression test to find when the keyboard problem
appeared after the screen was fixed, I gave up because testing each
revision takes about half an hour and the keyboard problem appears to
be somewhat intermittent.

-Alex

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

[Keith Busch]

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
>   - Samsung 960 Pro 2TB (Firmware 2B6QCXP7, current as of 5/4/17) 
>   - Samsung 960 Pro 1TB (Firmware 3L0QCXY7) 
> 
> These disks support APST, but
> assert APSTA=0 and so never get enabled in the driver.
> 
> This patch introduces an apst_override module parameter.
> By booting with nvme_core.apst_override=1, the driver can force using APST
> on disks which claim to not support it. This patch
> successfully enables APST on both Samsung disks.
> 
> This patch also introduces an additional sanity check on the NPSS to mitigate
> the risk of force-enabling APST on disks that genuinely do not support it.

It sounds like you really want to target this to specific devices rather
than on the module. This param potenially does undefined things if you set
it on a system with a mixure of devices. We've at least 27 bits left for
quirks so maybe you want to reserve one for these devices while they're
still available.


> + if (nvme_apst_override != -1 && ctrl->apsta != nvme_apst_override) {
> + dev_dbg(ctrl->device, "Overriding APSTA.\n");
> + ctrl->apsta = nvme_apst_override;
> + }
> + /*
>* If APST isn't supported or if we haven't been initialized yet,
>* then don't do anything.
>*/
>   if (!ctrl->apsta)
> + dev_dbg(ctrl->device, "APSTA not set, disabling APST.\n");
>   return;

You're missing some { brackets } here.

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

[Keith Busch]

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
>   - Samsung 960 Pro 2TB (Firmware 2B6QCXP7, current as of 5/4/17) 
>   - Samsung 960 Pro 1TB (Firmware 3L0QCXY7) 
> 
> These disks support APST, but
> assert APSTA=0 and so never get enabled in the driver.
> 
> This patch introduces an apst_override module parameter.
> By booting with nvme_core.apst_override=1, the driver can force using APST
> on disks which claim to not support it. This patch
> successfully enables APST on both Samsung disks.
> 
> This patch also introduces an additional sanity check on the NPSS to mitigate
> the risk of force-enabling APST on disks that genuinely do not support it.

It sounds like you really want to target this to specific devices rather
than on the module. This param potenially does undefined things if you set
it on a system with a mixure of devices. We've at least 27 bits left for
quirks so maybe you want to reserve one for these devices while they're
still available.


> + if (nvme_apst_override != -1 && ctrl->apsta != nvme_apst_override) {
> + dev_dbg(ctrl->device, "Overriding APSTA.\n");
> + ctrl->apsta = nvme_apst_override;
> + }
> + /*
>* If APST isn't supported or if we haven't been initialized yet,
>* then don't do anything.
>*/
>   if (!ctrl->apsta)
> + dev_dbg(ctrl->device, "APSTA not set, disabling APST.\n");
>   return;

You're missing some { brackets } here.

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

[zhong jiang]

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
>> valid_phys_addr_range(phys_addr_t addr, size_t count)
>>>   
>>>   static inline int valid_mmap_phys_addr_range(unsigned long pfn,
>> size_t size)
>>>   {
>>> - return 1;
>>> + return (pfn << PAGE_SHIFT) + size <= __pa(high_memory);
>>>   }
>>>   #endif
>>>   
>> I suppose you are correct that there should be some sanity checking
>> on the 
>> size used for the mmap().
> My apologies for not responding earlier. It may
> indeed make sense to have a sanity check here.
>
> However, it is not as easy as simply checking the
> end against __pa(high_memory). Some systems have
> non-contiguous physical memory ranges, with gaps
> of invalid addresses in-between.
 The invalid physical address means that it is used as
 io mapped. not in system ram region. /dev/mem is not
 access to them , is it right?
> You would have to make sure that both the beginning
> and the end are valid, and that there are no gaps of
> invalid pfns in the middle...
 If it is limited in system ram, we can walk the resource
 to exclude them. or adding pfn_valid further to optimize.
 whether other situation should be consider ? I am not sure.
> At that point, is the complexity so much that it no
> longer makes sense to try to protect against root
> crashing the system?
>
 your suggestion is to let the issue along without any protection.
 just root user know what they are doing.
 
 Thanks
 zhongjiang

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

[zhong jiang]

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
>> valid_phys_addr_range(phys_addr_t addr, size_t count)
>>>   
>>>   static inline int valid_mmap_phys_addr_range(unsigned long pfn,
>> size_t size)
>>>   {
>>> - return 1;
>>> + return (pfn << PAGE_SHIFT) + size <= __pa(high_memory);
>>>   }
>>>   #endif
>>>   
>> I suppose you are correct that there should be some sanity checking
>> on the 
>> size used for the mmap().
> My apologies for not responding earlier. It may
> indeed make sense to have a sanity check here.
>
> However, it is not as easy as simply checking the
> end against __pa(high_memory). Some systems have
> non-contiguous physical memory ranges, with gaps
> of invalid addresses in-between.
 The invalid physical address means that it is used as
 io mapped. not in system ram region. /dev/mem is not
 access to them , is it right?
> You would have to make sure that both the beginning
> and the end are valid, and that there are no gaps of
> invalid pfns in the middle...
 If it is limited in system ram, we can walk the resource
 to exclude them. or adding pfn_valid further to optimize.
 whether other situation should be consider ? I am not sure.
> At that point, is the complexity so much that it no
> longer makes sense to try to protect against root
> crashing the system?
>
 your suggestion is to let the issue along without any protection.
 just root user know what they are doing.
 
 Thanks
 zhongjiang