RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 7:57 AM
> To: Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965; 
> Jin
> Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > +---
> > +Required rcpm-wakeup property should be added to a device node if the
> > device
> > +can be used as a wakeup source.
> > +
> > +  - rcpm-wakeup: The value of the property consists of 3 cells. The first
> > cell
> > + is a pointer to the rcpm node, the second cell is the bit mask that
> > + should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
> > + Note: If the platform has no IPPDEXPCR1 register, put a zero here.
> 
> What if a future platform has more than two of these registers?

Those registers are only used for wakeup device, we have a lot of available bit
for feature. For example, In LS1021a platform only 7bits has used in the 
registers,
and 57bits is reserved.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 10:19 AM
> To: Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965; 
> Jin
> Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965; Jin
> > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > +---
> > > > +Required rcpm-wakeup property should be added to a device node if
> > > > +the
> > > > device
> > > > +can be used as a wakeup source.
> > > > +
> > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > + The
> > > > first
> > > > cell
> > > > + is a pointer to the rcpm node, the second cell is the bit
> > > > + mask
> > > > that
> > > > + should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
> > > > + Note: If the platform has no IPPDEXPCR1 register, put a zero here.
> > >
> > > What if a future platform has more than two of these registers?
> >
> > Those registers are only used for wakeup device, we have a lot of
> > available bit for feature. For example, In LS1021a platform only 7bits
> > has used in the registers, and 57bits is reserved.
> 
> Still, it'd be better to for the rcpm node to advertise the number of cells it
> expects.

For the foreseeable future it should be enough to use, even if not enough to 
use in
the future at that time we can update the binding.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 16, 2015 10:32 AM
> > To: Wang Dongsheng-B40534 
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > B18965 ; Jin Zhengxiong-R64188
> > ; Zhao Chenhui-B35336
> > ; Tang Yuantian-B29983
> > 
> > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > 
> > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > Hi Scott,
> > > 
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > > B18965; Jin
> > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > 
> > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > Hi Scott,
> > > > > 
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > robh+Huan-
> > > > > > B18965; Jin
> > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > 
> > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > +---
> > > > > > > +Required rcpm-wakeup property should be added to a device
> > > > > > > +node if the
> > > > > > > device
> > > > > > > +can be used as a wakeup source.
> > > > > > > +
> > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > > > > + The
> > > > > > > first
> > > > > > > cell
> > > > > > > + is a pointer to the rcpm node, the second cell is the
> > > > > > > + bit mask
> > > > > > > that
> > > > > > > + should be set in IPPDEXPCR0, and the last cell is for
> > > > > > > IPPDEXPCR1.
> > > > > > > + Note: If the platform has no IPPDEXPCR1 register, put a
> > > > > > > + zero
> > > > > > > here.
> > > > > > 
> > > > > > What if a future platform has more than two of these registers?
> > > > > 
> > > > > Those registers are only used for wakeup device, we have a lot of
> > > > > available bit for feature. For example, In LS1021a platform only
> > > > > 7bits has used in the registers, and 57bits is reserved.
> > > > 
> > > > Still, it'd be better to for the rcpm node to advertise the number
> > > > of cells it expects.
> > > 
> > > For the foreseeable future it should be enough to use, even if not
> > > enough to use in the future at that time we can update the binding.
> > 
> > That's the whole point.  Device tree is stable ABI.  Updating it later to 
> > not be
> > fixed to two cells would be a lot harder than getting it right from the
> > beginning.  Putting the number of cells in the phandle target is a 
> > standard
> > device tree idiom.
> > 
> I agree with you. But what's the point a SOC has more than 64 wakeup source?

I don't know.  Hardware people do strange things sometimes.  They might not 
want to reuse bits they once used for something on some other chip, or they 
might have some encoding scheme in mind that results in the bits not being 
packed as tightly as possible, or there may be some big array of similar 
devices...

What's the point of skipping this part of the phandle-plus-arguments idiom?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Wednesday, September 16, 2015 10:44 AM
> To: Wood Scott-B07421; Tang Yuantian-B29983
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965; 
> Jin
> Zhengxiong-R64188; Zhao Chenhui-B35336
> Subject: RE: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 16, 2015 10:38 AM
> > To: Tang Yuantian-B29983
> > Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org; robh...@kernel.org;
> > linux-arm-ker...@lists.infradead.org;
> > Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> >
> > On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > > To: Wang Dongsheng-B40534 
> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > robh+Huan-
> > > > B18965 ; Jin Zhengxiong-R64188
> > > > ; Zhao Chenhui-B35336
> > > > ; Tang Yuantian-B29983
> > > > 
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > >
> > > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > > Hi Scott,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > robh+Huan-
> > > > > > B18965; Jin
> > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > >
> > > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > Hi Scott,
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > > > > robh+Wang
> > > > > > > > robh+Huan-
> > > > > > > > B18965; Jin
> > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > Yuantian-B29983
> > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > >
> > > > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > > +---
> > > > > > > > > +Required rcpm-wakeup property should be added to a
> > > > > > > > > +device node if the
> > > > > > > > > device
> > > > > > > > > +can be used as a wakeup source.
> > > > > > > > > +
> > > > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 
> > > > > > > > > cells.
> > > > > > > > > + The
> > > > > > > > > first
> > > > > > > > > cell
> > > > > > > > > + is a pointer to the rcpm node, the second cell is
> > > > > > > > > + the bit mask
> > > > > > > > > that
> > > > > > > > > + should be set in IPPDEXPCR0, and the last cell is
> > > > > > > > > + for
> > > > > > > > > IPPDEXPCR1.
> > > > > > > > > + Note: If the platform has no IPPDEXPCR1 register,
> > > > > > > > > + put a zero
> > > > > > > > > here.
> > > > > > > >
> > > > > > > > What if a future platform has more than two of these registers?
> > > > > > >
> > > > > > > Those registers are only used for wakeup device, we have a
> > > > > > > lot of available bit for feature. For example, In LS1021a
> > > > > > > platform only 7bits has used in the registers, and 57bits is
> reserved.
> > > > > >
> > > > > > Still, it'd be better to for the rcpm node to advertise the
> > > > > > number of cells it expects.
> > > > >
> > > > > For the foreseeable future it should be enough to use, even if
> > > > > not enough to use in the future at that time we can update the 
> > > > > binding.
> > > >
> > > > That's the whole point.  Device tree is stable ABI.  Updating it
> > > > later to not be fixed to two cells would be a lot harder than
> > > > getting it right from the beginning.  Putting the number of cells
> > > > in the phandle target is a standard device tree idiom.
> > > >
> > > I agree with you. But what's the point a SOC has more than 64 wakeup 
> > > source?
> >
> > I don't know.  Hardware people do strange things sometimes.  They
> > might not want to reuse 

Re: [PATCH 00/29] cxlflash: Miscellaneous bug fixes and corrections

[Matthew R. Ochs]

> On Sep 15, 2015, at 9:50 PM, Ian Munsie  wrote:
> 
> Hi Matt & Manoj,
> 
> Can you also add linuxppc-dev@lists.ozlabs.org to the Cc list for
> version 2?

Will do.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 10:38 AM
> To: Tang Yuantian-B29983
> Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; robh...@kernel.org; 
> linux-arm-ker...@lists.infradead.org;
> Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > To: Wang Dongsheng-B40534 
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965 ; Jin Zhengxiong-R64188
> > > ; Zhao Chenhui-B35336
> > > ; Tang Yuantian-B29983
> > > 
> > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > Hi Scott,
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > > > B18965; Jin
> > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > >
> > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > Hi Scott,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > To: Wang Dongsheng-B40534
> > > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > > robh+Huan-
> > > > > > > B18965; Jin
> > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > >
> > > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > +---
> > > > > > > > +Required rcpm-wakeup property should be added to a device
> > > > > > > > +node if the
> > > > > > > > device
> > > > > > > > +can be used as a wakeup source.
> > > > > > > > +
> > > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > > > > > + The
> > > > > > > > first
> > > > > > > > cell
> > > > > > > > + is a pointer to the rcpm node, the second cell is the
> > > > > > > > + bit mask
> > > > > > > > that
> > > > > > > > + should be set in IPPDEXPCR0, and the last cell is for
> > > > > > > > IPPDEXPCR1.
> > > > > > > > + Note: If the platform has no IPPDEXPCR1 register, put a
> > > > > > > > + zero
> > > > > > > > here.
> > > > > > >
> > > > > > > What if a future platform has more than two of these registers?
> > > > > >
> > > > > > Those registers are only used for wakeup device, we have a lot of
> > > > > > available bit for feature. For example, In LS1021a platform only
> > > > > > 7bits has used in the registers, and 57bits is reserved.
> > > > >
> > > > > Still, it'd be better to for the rcpm node to advertise the number
> > > > > of cells it expects.
> > > >
> > > > For the foreseeable future it should be enough to use, even if not
> > > > enough to use in the future at that time we can update the binding.
> > >
> > > That's the whole point.  Device tree is stable ABI.  Updating it later to
> > > not be
> > > fixed to two cells would be a lot harder than getting it right from the
> > > beginning.  Putting the number of cells in the phandle target is a
> > > standard
> > > device tree idiom.
> > >
> > I agree with you. But what's the point a SOC has more than 64 wakeup source?
> 
> I don't know.  Hardware people do strange things sometimes.  They might not
> want to reuse bits they once used for something on some other chip, or they
> might have some encoding scheme in mind that results in the bits not being
> packed as tightly as possible, or there may be some big array of similar
> devices...
> 
> What's the point of skipping this part of the phandle-plus-arguments idiom?

Fine, I will add a property in rcpm node to describe the number of register.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Recompute hash value after a failed update

[Paul Mackerras]

On Tue, Sep 15, 2015 at 12:30:08PM +0530, Aneesh Kumar K.V wrote:
> If we had secondary hash flag set, we ended up modifying hash value in
> the updatepp code path. Hence with a failed updatepp we will be using
> a wrong hash value for the following hash insert. Fix this by
> recomputing hash before insert.
> 
> Signed-off-by: Aneesh Kumar K.V 

Reviewed-by: Paul Mackerras 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 12:14 PM
> To: Wang Dongsheng-B40534
> Cc: Tang Yuantian-B29983; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; robh...@kernel.org; 
> linux-arm-ker...@lists.infradead.org;
> Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 22:18 -0500, Wang Dongsheng-B40534 wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Wednesday, September 16, 2015 10:44 AM
> > > To: Wood Scott-B07421; Tang Yuantian-B29983
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965; Jin
> > > Zhengxiong-R64188; Zhao Chenhui-B35336
> > > Subject: RE: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 10:38 AM
> > > > To: Tang Yuantian-B29983
> > > > Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> > > > d...@lists.ozlabs.org; robh...@kernel.org;
> > > > linux-arm-ker...@lists.infradead.org;
> > > > Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > >
> > > > On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > > > > To: Wang Dongsheng-B40534 
> > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > robh+Huan-
> > > > > > B18965 ; Jin Zhengxiong-R64188
> > > > > > ; Zhao Chenhui-B35336
> > > > > > ; Tang Yuantian-B29983
> > > > > > 
> > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > >
> > > > > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > Hi Scott,
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > > > > robh+Wang
> > > > > > > > robh+Huan-
> > > > > > > > B18965; Jin
> > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > Yuantian-B29983
> > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > >
> > > > > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > > > Hi Scott,
> > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Wood Scott-B07421
> > > > > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > > > robh...@kernel.org;
> > > > > > > > > > robh+linux-arm-ker...@lists.infradead.org;
> > > > > > > > > > robh+Wang
> > > > > > > > > > robh+Huan-
> > > > > > > > > > B18965; Jin
> > > > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > > > Yuantian-B29983
> > > > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > > > >
> > > > > > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > > > > +---
> > > > > > > > > > > +Required rcpm-wakeup property should be added to a
> > > > > > > > > > > +device node if the
> > > > > > > > > > > device
> > > > > > > > > > > +can be used as a wakeup source.
> > > > > > > > > > > +
> > > > > > > > > > > +  - rcpm-wakeup: The value of the property consists
> > > > > > > > > > > + of 3
> > > > > > > > > > > cells.
> > > > > > > > > > > + The
> > > > > > > > > > > first
> > > > > > > > > > > cell
> > > > > > > > > > > + is a pointer to the rcpm node, the second cell
> > > > > > > > > > > + is the bit mask
> > > > > > > > > > > that
> > > > > > > > > > > + should be set in IPPDEXPCR0, and the last cell
> > > > > > > > > > > + is for
> > > > > > > > > > > IPPDEXPCR1.
> > > > > > > > > > > + Note: If the platform has no IPPDEXPCR1
> > > > > > > > > > > + register, put a zero
> > > > > > > > > > > here.
> > > > > > > > > >
> > > > > > > > > > What if a future platform has more than two of these
> > > > > > > > > > registers?
> > > > > > > > >
> > > > > > > > > Those registers are only used for 

Re: [PATCH] powerpc/mm: Recompute hash value after a failed update

[Michael Ellerman]

On Wed, 2015-09-16 at 08:53 +0530, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V"  writes:
> 
> > If we had secondary hash flag set, we ended up modifying hash value in
> > the updatepp code path. Hence with a failed updatepp we will be using
> > a wrong hash value for the following hash insert. Fix this by
> > recomputing hash before insert.
> 
> Without this patch we can end up with using wrong slot number in linux
> pte. That can result in us missing an hash pte update or invalidate
> which can cause memory corruption or even machine check ?

Thanks. When did this break? Always? If so this should go to stable?

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Recompute hash value after a failed update

[Aneesh Kumar K.V]

Michael Ellerman  writes:

> On Wed, 2015-09-16 at 08:53 +0530, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V"  writes:
>> 
>> > If we had secondary hash flag set, we ended up modifying hash value in
>> > the updatepp code path. Hence with a failed updatepp we will be using
>> > a wrong hash value for the following hash insert. Fix this by
>> > recomputing hash before insert.
>> 
>> Without this patch we can end up with using wrong slot number in linux
>> pte. That can result in us missing an hash pte update or invalidate
>> which can cause memory corruption or even machine check ?
>
> Thanks. When did this break? Always? If so this should go to stable?
>

IIUC we have this issue with initial support for THP 
(6d492ecc6489113968ec269be1cf88942d4a5d29)
" powerpc/THP: Add code to handle HPTE faults for hugepages". So yes
this should got to stable.

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Tue, 2015-09-15 at 22:18 -0500, Wang Dongsheng-B40534 wrote:
> Hi Scott,
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Wednesday, September 16, 2015 10:44 AM
> > To: Wood Scott-B07421; Tang Yuantian-B29983
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > B18965; Jin
> > Zhengxiong-R64188; Zhao Chenhui-B35336
> > Subject: RE: [PATCH v2 1/2] fsl: Add binding for RCPM
> > 
> > 
> > 
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 16, 2015 10:38 AM
> > > To: Tang Yuantian-B29983
> > > Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> > > d...@lists.ozlabs.org; robh...@kernel.org;
> > > linux-arm-ker...@lists.infradead.org;
> > > Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > 
> > > On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> > > > 
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > > > To: Wang Dongsheng-B40534 
> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > robh+Huan-
> > > > > B18965 ; Jin Zhengxiong-R64188
> > > > > ; Zhao Chenhui-B35336
> > > > > ; Tang Yuantian-B29983
> > > > > 
> > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > 
> > > > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > Hi Scott,
> > > > > > 
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > > > To: Wang Dongsheng-B40534
> > > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > > robh+Huan-
> > > > > > > B18965; Jin
> > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > 
> > > > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > > Hi Scott,
> > > > > > > > 
> > > > > > > > > -Original Message-
> > > > > > > > > From: Wood Scott-B07421
> > > > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > > > > > robh+Wang
> > > > > > > > > robh+Huan-
> > > > > > > > > B18965; Jin
> > > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > > Yuantian-B29983
> > > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > > > 
> > > > > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > > > +---
> > > > > > > > > > +Required rcpm-wakeup property should be added to a
> > > > > > > > > > +device node if the
> > > > > > > > > > device
> > > > > > > > > > +can be used as a wakeup source.
> > > > > > > > > > +
> > > > > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 
> > > > > > > > > > cells.
> > > > > > > > > > + The
> > > > > > > > > > first
> > > > > > > > > > cell
> > > > > > > > > > + is a pointer to the rcpm node, the second cell is
> > > > > > > > > > + the bit mask
> > > > > > > > > > that
> > > > > > > > > > + should be set in IPPDEXPCR0, and the last cell is
> > > > > > > > > > + for
> > > > > > > > > > IPPDEXPCR1.
> > > > > > > > > > + Note: If the platform has no IPPDEXPCR1 register,
> > > > > > > > > > + put a zero
> > > > > > > > > > here.
> > > > > > > > > 
> > > > > > > > > What if a future platform has more than two of these 
> > > > > > > > > registers?
> > > > > > > > 
> > > > > > > > Those registers are only used for wakeup device, we have a
> > > > > > > > lot of available bit for feature. For example, In LS1021a
> > > > > > > > platform only 7bits has used in the registers, and 57bits is
> > reserved.
> > > > > > > 
> > > > > > > Still, it'd be better to for the rcpm node to advertise the
> > > > > > > number of cells it expects.
> > > > > > 
> > > > > > For the foreseeable future it should be enough to use, even if
> > > > > > not enough to use in the future at that time we can update the 
> > > > > > binding.
> > > > > 
> > > > > That's the whole point.  Device tree is stable ABI.  Updating it
> > > > > later to not be fixed to two cells would be a lot harder than
> > > > > getting it 

[PATCH stable 1/2] powerpc: Uncomment and make enable_kernel_vsx() routine available

[Michael Ellerman]

From: Leonidas Da Silva Barbosa 

commit 72cd7b44bc99376b3f3c93cedcd052663fcdf705 upstream.

enable_kernel_vsx() function was commented since anything was using
it. However, vmx-crypto driver uses VSX instructions which are
only available if VSX is enable. Otherwise it rises an exception oops.

This patch uncomment enable_kernel_vsx() routine and makes it available.

Signed-off-by: Leonidas S. Barbosa 
Signed-off-by: Herbert Xu 
Cc: sta...@vger.kernel.org # 4.2
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/switch_to.h | 1 +
 arch/powerpc/kernel/process.c| 3 ---
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index 58abeda64cb7..15cca17cba4b 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -29,6 +29,7 @@ static inline void save_early_sprs(struct thread_struct 
*prev) {}
 
 extern void enable_kernel_fp(void);
 extern void enable_kernel_altivec(void);
+extern void enable_kernel_vsx(void);
 extern int emulate_altivec(struct pt_regs *);
 extern void __giveup_vsx(struct task_struct *);
 extern void giveup_vsx(struct task_struct *);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 8005e18d1b40..64e6e9d9e656 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -204,8 +204,6 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_thread);
 #endif /* CONFIG_ALTIVEC */
 
 #ifdef CONFIG_VSX
-#if 0
-/* not currently used, but some crazy RAID module might want to later */
 void enable_kernel_vsx(void)
 {
WARN_ON(preemptible());
@@ -220,7 +218,6 @@ void enable_kernel_vsx(void)
 #endif /* CONFIG_SMP */
 }
 EXPORT_SYMBOL(enable_kernel_vsx);
-#endif
 
 void giveup_vsx(struct task_struct *tsk)
 {
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> +* Freescale RCPM Wakeup Source Device Tree Bindings
> +---
> +Required rcpm-wakeup property should be added to a device node if the 
> device
> +can be used as a wakeup source.
> +
> +  - rcpm-wakeup: The value of the property consists of 3 cells. The first 
> cell
> + is a pointer to the rcpm node, the second cell is the bit mask that
> + should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
> + Note: If the platform has no IPPDEXPCR1 register, put a zero here.

What if a future platform has more than two of these registers?

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH stable 2/2] crypto: vmx - Adding enable_kernel_vsx() to access VSX instructions

[Michael Ellerman]

From: Leonidas Da Silva Barbosa 

commit 2d6f0600b2cd755959527230ef5a6fba97bb762a upstream.

vmx-crypto driver make use of some VSX instructions which are
only available if VSX is enabled. Running in cases where VSX
are not enabled vmx-crypto fails in a VSX exception.

In order to fix this enable_kernel_vsx() was added to turn on
VSX instructions for vmx-crypto.

Signed-off-by: Leonidas S. Barbosa 
Signed-off-by: Herbert Xu 
Fixes: 8676590a1593 ("crypto: vmx - Adding AES routines for VMX module")
Cc: sta...@vger.kernel.org # 4.2
Signed-off-by: Michael Ellerman 
---
 drivers/crypto/vmx/aes.c | 3 +++
 drivers/crypto/vmx/aes_cbc.c | 3 +++
 drivers/crypto/vmx/aes_ctr.c | 3 +++
 drivers/crypto/vmx/ghash.c   | 4 
 4 files changed, 13 insertions(+)

This fixes a kernel crash at boot.

diff --git a/drivers/crypto/vmx/aes.c b/drivers/crypto/vmx/aes.c
index e79e567e43aa..263af709e536 100644
--- a/drivers/crypto/vmx/aes.c
+++ b/drivers/crypto/vmx/aes.c
@@ -84,6 +84,7 @@ static int p8_aes_setkey(struct crypto_tfm *tfm, const u8 
*key,
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
ret = aes_p8_set_encrypt_key(key, keylen * 8, >enc_key);
ret += aes_p8_set_decrypt_key(key, keylen * 8, >dec_key);
pagefault_enable();
@@ -103,6 +104,7 @@ static void p8_aes_encrypt(struct crypto_tfm *tfm, u8 *dst, 
const u8 *src)
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
aes_p8_encrypt(src, dst, >enc_key);
pagefault_enable();
preempt_enable();
@@ -119,6 +121,7 @@ static void p8_aes_decrypt(struct crypto_tfm *tfm, u8 *dst, 
const u8 *src)
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
aes_p8_decrypt(src, dst, >dec_key);
pagefault_enable();
preempt_enable();
diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
index 725c78ec..0b8fe2ec5315 100644
--- a/drivers/crypto/vmx/aes_cbc.c
+++ b/drivers/crypto/vmx/aes_cbc.c
@@ -85,6 +85,7 @@ static int p8_aes_cbc_setkey(struct crypto_tfm *tfm, const u8 
*key,
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
ret = aes_p8_set_encrypt_key(key, keylen * 8, >enc_key);
ret += aes_p8_set_decrypt_key(key, keylen * 8, >dec_key);
pagefault_enable();
@@ -115,6 +116,7 @@ static int p8_aes_cbc_encrypt(struct blkcipher_desc *desc,
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
 
blkcipher_walk_init(, dst, src, nbytes);
ret = blkcipher_walk_virt(desc, );
@@ -155,6 +157,7 @@ static int p8_aes_cbc_decrypt(struct blkcipher_desc *desc,
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
 
blkcipher_walk_init(, dst, src, nbytes);
ret = blkcipher_walk_virt(desc, );
diff --git a/drivers/crypto/vmx/aes_ctr.c b/drivers/crypto/vmx/aes_ctr.c
index 7adae42a7b79..1e754ae4e850 100644
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -82,6 +82,7 @@ static int p8_aes_ctr_setkey(struct crypto_tfm *tfm, const u8 
*key,
 
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
ret = aes_p8_set_encrypt_key(key, keylen * 8, >enc_key);
pagefault_enable();
 
@@ -100,6 +101,7 @@ static void p8_aes_ctr_final(struct p8_aes_ctr_ctx *ctx,
 
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
aes_p8_encrypt(ctrblk, keystream, >enc_key);
pagefault_enable();
 
@@ -131,6 +133,7 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc *desc,
while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();
aes_p8_ctr32_encrypt_blocks(walk.src.virt.addr,
walk.dst.virt.addr,
(nbytes &
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index b5e29002b666..2183a2e77641 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -119,6 +119,7 @@ static int p8_ghash_setkey(struct crypto_shash *tfm, const 
u8 *key,
preempt_disable();
pagefault_disable();
enable_kernel_altivec();
+   enable_kernel_vsx();

Re: [PATCH 00/29] cxlflash: Miscellaneous bug fixes and corrections

[Ian Munsie]

Hi Matt & Manoj,

Can you also add linuxppc-dev@lists.ozlabs.org to the Cc list for
version 2?

Cheers,
-Ian

Excerpts from Matthew R. Ochs's message of 2015-09-15 06:12:29 +1000:
> > On Sep 13, 2015, at 8:12 PM, Ian Munsie  wrote:
> > 
> > Hi Matt & Manoj,
> > 
> > Just a general comment about this series - I'd like to see more detailed
> > commit messages for almost all these patches. Of course James is the
> > scsi maintainer and it's up to him whether to take these as is or not,
> > but generally when you write a commit message for a bug fix you want to
> > explain:
> > 
> > - What problem can occur, possibly including an example
> > - Why it occurs
> > - How this patch addresses it
> > 
> > You don't necessarily need to go overboard because at some point people
> > can just read the code, but some of these patches don't have any detail
> > beyond a single subject line, which is too little.
> > 
> > Speaking of the subject line - if the patch is fixing a bug there should
> > be some indication of that in the subject (it should probably include
> > the word "fix" somewhere). If the subject just states what you are
> > changing then it's not immediately obvious that it is a bug fix.
> 
> This is a reasonable request. Will incorporate your suggestions
> and send out in a v2 series. Thanks for the examples of what you
> would like to see.
> 
> 
> -matt

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mm: Recompute hash value after a failed update

[Aneesh Kumar K.V]

"Aneesh Kumar K.V"  writes:

> If we had secondary hash flag set, we ended up modifying hash value in
> the updatepp code path. Hence with a failed updatepp we will be using
> a wrong hash value for the following hash insert. Fix this by
> recomputing hash before insert.

Without this patch we can end up with using wrong slot number in linux
pte. That can result in us missing an hash pte update or invalidate
which can cause memory corruption or even machine check ?

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH stable 2/2] crypto: vmx - Adding enable_kernel_vsx() to access VSX instructions

[Michael Ellerman]

commit 2d6f0600b2cd755959527230ef5a6fba97bb762a upstream.

vmx-crypto driver make use of some VSX instructions which are
only available if VSX is enabled. Running in cases where VSX
are not enabled vmx-crypto fails in a VSX exception.

In order to fix this enable_kernel_vsx() was added to turn on
VSX instructions for vmx-crypto.

Signed-off-by: Leonidas S. Barbosa 
Signed-off-by: Herbert Xu 
Fixes: 8676590a1593 ("crypto: vmx - Adding AES routines for VMX module")
Cc: sta...@vger.kernel.org # 4.1
Signed-off-by: Michael Ellerman 
---
 drivers/crypto/vmx/aes.c | 3 +++
 drivers/crypto/vmx/aes_cbc.c | 3 +++
 drivers/crypto/vmx/aes_ctr.c | 3 +++
 drivers/crypto/vmx/ghash.c   | 4 
 4 files changed, 13 insertions(+)

diff --git a/drivers/crypto/vmx/aes.c b/drivers/crypto/vmx/aes.c
index ab300ea19434..41f93334cc44 100644
--- a/drivers/crypto/vmx/aes.c
+++ b/drivers/crypto/vmx/aes.c
@@ -80,6 +80,7 @@ static int p8_aes_setkey(struct crypto_tfm *tfm, const u8 
*key,
 
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 ret = aes_p8_set_encrypt_key(key, keylen * 8, >enc_key);
 ret += aes_p8_set_decrypt_key(key, keylen * 8, >dec_key);
 pagefault_enable();
@@ -97,6 +98,7 @@ static void p8_aes_encrypt(struct crypto_tfm *tfm, u8 *dst, 
const u8 *src)
 } else {
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 aes_p8_encrypt(src, dst, >enc_key);
 pagefault_enable();
 }
@@ -111,6 +113,7 @@ static void p8_aes_decrypt(struct crypto_tfm *tfm, u8 *dst, 
const u8 *src)
 } else {
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 aes_p8_decrypt(src, dst, >dec_key);
 pagefault_enable();
 }
diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
index 1a559b7dddb5..c8e7f653e5d3 100644
--- a/drivers/crypto/vmx/aes_cbc.c
+++ b/drivers/crypto/vmx/aes_cbc.c
@@ -81,6 +81,7 @@ static int p8_aes_cbc_setkey(struct crypto_tfm *tfm, const u8 
*key,
 
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 ret = aes_p8_set_encrypt_key(key, keylen * 8, >enc_key);
 ret += aes_p8_set_decrypt_key(key, keylen * 8, >dec_key);
 pagefault_enable();
@@ -108,6 +109,7 @@ static int p8_aes_cbc_encrypt(struct blkcipher_desc *desc,
 } else {
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 
blkcipher_walk_init(, dst, src, nbytes);
 ret = blkcipher_walk_virt(desc, );
@@ -143,6 +145,7 @@ static int p8_aes_cbc_decrypt(struct blkcipher_desc *desc,
 } else {
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 
blkcipher_walk_init(, dst, src, nbytes);
 ret = blkcipher_walk_virt(desc, );
diff --git a/drivers/crypto/vmx/aes_ctr.c b/drivers/crypto/vmx/aes_ctr.c
index 96dbee4bf4a6..266e708d63df 100644
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -79,6 +79,7 @@ static int p8_aes_ctr_setkey(struct crypto_tfm *tfm, const u8 
*key,
 
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 ret = aes_p8_set_encrypt_key(key, keylen * 8, >enc_key);
 pagefault_enable();
 
@@ -97,6 +98,7 @@ static void p8_aes_ctr_final(struct p8_aes_ctr_ctx *ctx,
 
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 aes_p8_encrypt(ctrblk, keystream, >enc_key);
 pagefault_enable();
 
@@ -127,6 +129,7 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc *desc,
 while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 aes_p8_ctr32_encrypt_blocks(walk.src.virt.addr, walk.dst.virt.addr,
 (nbytes & AES_BLOCK_MASK)/AES_BLOCK_SIZE, >enc_key, 
walk.iv);
 pagefault_enable();
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index d0ffe277af5c..917b3f09e724 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -116,6 +116,7 @@ static int p8_ghash_setkey(struct crypto_shash *tfm, const 
u8 *key,
 
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 enable_kernel_fp();
 gcm_init_p8(ctx->htable, (const u64 *) key);
 pagefault_enable();
@@ -142,6 +143,7 @@ static int p8_ghash_update(struct shash_desc *desc,
 GHASH_DIGEST_SIZE - dctx->bytes);
 pagefault_disable();
 enable_kernel_altivec();
+enable_kernel_vsx();
 enable_kernel_fp();
 gcm_ghash_p8(dctx->shash, ctx->htable, dctx->buffer,
 GHASH_DIGEST_SIZE);
@@ -154,6 +156,7 @@ static int p8_ghash_update(struct shash_desc *desc,
 if (len) {
 pagefault_disable();
  

[PATCH stable 1/2] powerpc: Uncomment and make enable_kernel_vsx() routine available

[Michael Ellerman]

From: Leonidas Da Silva Barbosa 

commit 72cd7b44bc99376b3f3c93cedcd052663fcdf705 upstream.

enable_kernel_vsx() function was commented since anything was using
it. However, vmx-crypto driver uses VSX instructions which are
only available if VSX is enable. Otherwise it rises an exception oops.

This patch uncomment enable_kernel_vsx() routine and makes it available.

Signed-off-by: Leonidas S. Barbosa 
Signed-off-by: Herbert Xu 
Cc: sta...@vger.kernel.org # 4.1
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/switch_to.h | 1 +
 arch/powerpc/kernel/process.c| 3 ---
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/switch_to.h 
b/arch/powerpc/include/asm/switch_to.h
index 58abeda64cb7..15cca17cba4b 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -29,6 +29,7 @@ static inline void save_early_sprs(struct thread_struct 
*prev) {}
 
 extern void enable_kernel_fp(void);
 extern void enable_kernel_altivec(void);
+extern void enable_kernel_vsx(void);
 extern int emulate_altivec(struct pt_regs *);
 extern void __giveup_vsx(struct task_struct *);
 extern void giveup_vsx(struct task_struct *);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index febb50dd5328..0596373cd1c3 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -204,8 +204,6 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_thread);
 #endif /* CONFIG_ALTIVEC */
 
 #ifdef CONFIG_VSX
-#if 0
-/* not currently used, but some crazy RAID module might want to later */
 void enable_kernel_vsx(void)
 {
WARN_ON(preemptible());
@@ -220,7 +218,6 @@ void enable_kernel_vsx(void)
 #endif /* CONFIG_SMP */
 }
 EXPORT_SYMBOL(enable_kernel_vsx);
-#endif
 
 void giveup_vsx(struct task_struct *tsk)
 {
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> Hi Scott,
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 16, 2015 7:57 AM
> > To: Wang Dongsheng-B40534
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > B18965; Jin
> > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > 
> > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > +---
> > > +Required rcpm-wakeup property should be added to a device node if the
> > > device
> > > +can be used as a wakeup source.
> > > +
> > > +  - rcpm-wakeup: The value of the property consists of 3 cells. The 
> > > first
> > > cell
> > > + is a pointer to the rcpm node, the second cell is the bit mask 
> > > that
> > > + should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
> > > + Note: If the platform has no IPPDEXPCR1 register, put a zero here.
> > 
> > What if a future platform has more than two of these registers?
> 
> Those registers are only used for wakeup device, we have a lot of available 
> bit
> for feature. For example, In LS1021a platform only 7bits has used in the 
> registers,
> and 57bits is reserved.

Still, it'd be better to for the rcpm node to advertise the number of cells 
it expects.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> Hi Scott,
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 16, 2015 10:19 AM
> > To: Wang Dongsheng-B40534
> > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > B18965; Jin
> > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > 
> > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > Hi Scott,
> > > 
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > > B18965; Jin
> > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > 
> > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > +---
> > > > > +Required rcpm-wakeup property should be added to a device node if
> > > > > +the
> > > > > device
> > > > > +can be used as a wakeup source.
> > > > > +
> > > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > > + The
> > > > > first
> > > > > cell
> > > > > + is a pointer to the rcpm node, the second cell is the bit
> > > > > + mask
> > > > > that
> > > > > + should be set in IPPDEXPCR0, and the last cell is for 
> > > > > IPPDEXPCR1.
> > > > > + Note: If the platform has no IPPDEXPCR1 register, put a zero 
> > > > > here.
> > > > 
> > > > What if a future platform has more than two of these registers?
> > > 
> > > Those registers are only used for wakeup device, we have a lot of
> > > available bit for feature. For example, In LS1021a platform only 7bits
> > > has used in the registers, and 57bits is reserved.
> > 
> > Still, it'd be better to for the rcpm node to advertise the number of 
> > cells it
> > expects.
> 
> For the foreseeable future it should be enough to use, even if not enough 
> to use in
> the future at that time we can update the binding.

That's the whole point.  Device tree is stable ABI.  Updating it later to not 
be fixed to two cells would be a lot harder than getting it right from the 
beginning.  Putting the number of cells in the phandle target is a standard 
device tree idiom.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/mm: Recompute hash value after a failed update

[Aneesh Kumar K.V]

If we had secondary hash flag set, we ended up modifying hash value in
the updatepp code path. Hence with a failed updatepp we will be using
a wrong hash value for the following hash insert. Fix this by
recomputing hash before insert.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/mm/hugepage-hash64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/hugepage-hash64.c 
b/arch/powerpc/mm/hugepage-hash64.c
index 43dafb9d6a46..4d87122cf6a7 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -85,7 +85,6 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
BUG_ON(index >= 4096);
 
vpn = hpt_vpn(ea, vsid, ssize);
-   hash = hpt_hash(vpn, shift, ssize);
hpte_slot_array = get_hpte_slot_array(pmdp);
if (psize == MMU_PAGE_4K) {
/*
@@ -101,6 +100,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
valid = hpte_valid(hpte_slot_array, index);
if (valid) {
/* update the hpte bits */
+   hash = hpt_hash(vpn, shift, ssize);
hidx =  hpte_hash_index(hpte_slot_array, index);
if (hidx & _PTEIDX_SECONDARY)
hash = ~hash;
@@ -126,6 +126,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access, 
unsigned long vsid,
if (!valid) {
unsigned long hpte_group;
 
+   hash = hpt_hash(vpn, shift, ssize);
/* insert new entry */
pa = pmd_pfn(__pmd(old_pmd)) << PAGE_SHIFT;
new_pmd |= _PAGE_HASHPTE;
-- 
2.5.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 1/2] mm: Replace nr_node_ids for loop with for_each_node in list lru

[Vladimir Davydov]

On Tue, Sep 15, 2015 at 07:38:36AM +0530, Raghavendra K T wrote:
> The functions used in the patch are in slowpath, which gets called
> whenever alloc_super is called during mounts.
> 
> Though this should not make difference for the architectures with
> sequential numa node ids, for the powerpc which can potentially have
> sparse node ids (for e.g., 4 node system having numa ids, 0,1,16,17
> is common), this patch saves some unnecessary allocations for
> non existing numa nodes.
> 
> Even without that saving, perhaps patch makes code more readable.
> 
> [ Take memcg_aware check outside for_each loop: Vldimir]
> Signed-off-by: Raghavendra K T 

Reviewed-by: Vladimir Davydov 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/2] fsl: Add binding for RCPM

[Dongsheng Wang]

From: Wang Dongsheng 

RCPM is the Run Control and Power Management module performs all
device-level tasks associated with device run control and power
management.

Add this for freescale powerpc platform and layerscape platform.

Signed-off-by: Chenhui Zhao 
Signed-off-by: Tang Yuantian 
Signed-off-by: Wang Dongsheng 
---
*v2*
- Remove P4080 example.
- Modify rcpm-wakeup property description.
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..ea24d76
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,60 @@
+* Run Control and Power Management
+---
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+  - reg : Offset and length of the register set of RCPM block.
+  - compatible : Sould contain a chip-specific RCPM block compatible string
+   and (if applicable) may contain a chassis-version RCPM compatible 
string.
+   Chip-specific strings are of the form "fsl,-rcpm", such as:
+   * "fsl,p2041-rcpm"
+   * "fsl,p3041-rcpm"
+   * "fsl,p4080-rcpm"
+   * "fsl,p5020-rcpm"
+   * "fsl,p5040-rcpm"
+   * "fsl,t4240-rcpm"
+   * "fsl,b4420-rcpm"
+   * "fsl,b4860-rcpm"
+
+   Chassis-version strings are of the form "fsl,qoriq-rcpm-",
+   such as:
+   * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
+   * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
+   * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+
+All references to "1.0" and "2.0" refer to the QorIQ chassis version to
+which the chip complies.
+Chassis VersionExample Chips
+------
+1.0p4080, p5020, p5040, p2041, p3041
+2.0t4240, b4860, b4420
+2.1t1040, ls1021
+
+Example:
+The RCPM node for T4240:
+   rcpm: global-utilities@e2000 {
+   compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+   reg = <0xe2000 0x1000>;
+   };
+
+* Freescale RCPM Wakeup Source Device Tree Bindings
+---
+Required rcpm-wakeup property should be added to a device node if the device
+can be used as a wakeup source.
+
+  - rcpm-wakeup: The value of the property consists of 3 cells. The first cell
+   is a pointer to the rcpm node, the second cell is the bit mask that
+   should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
+   Note: If the platform has no IPPDEXPCR1 register, put a zero here.
+
+Example:
+   lpuart0: serial@295 {
+   compatible = "fsl,ls1021a-lpuart";
+   reg = <0x0 0x295 0x0 0x1000>;
+   interrupts = ;
+   clocks = <>;
+   clock-names = "ipg";
+   rcpm-wakeup = < 0x0 0x4000>;
+   status = "disabled";
+   };
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 2/2] arm/layerscape: add RCPM device tree support for ls1021a.

[Dongsheng Wang]

From: Wang Dongsheng 

Signed-off-by: Wang Dongsheng 
---
*v2*: No changes.
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 973a496..deb1271 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -139,6 +139,7 @@
sdhci,auto-cmd12;
big-endian;
bus-width = <4>;
+   rcpm-wakeup = < 0x0080 0x0>;
status = "disabled";
};
 
@@ -186,6 +187,11 @@
};
};
 
+   rcpm: rcpm@1ee2000 {
+   compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1";
+   reg = <0x0 0x1ee2000 0x0 0x1>;
+   };
+
dspi0: dspi@210 {
compatible = "fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
@@ -287,6 +293,7 @@
interrupts = ;
clocks = <>;
clock-names = "ipg";
+   rcpm-wakeup = < 0x0 0x4000>;
status = "disabled";
};
 
-- 
2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case

[Bjorn Helgaas]

On Mon, Sep 07, 2015 at 01:17:03PM +1000, Michael Ellerman wrote:
> On Sun, 2015-09-06 at 17:44 +0300, Michael S. Tsirkin wrote:
> > On Fri, Sep 04, 2015 at 08:17:12PM -0300, Guilherme G. Piccoli wrote:
> > > Hello Bjorn,
> > > 
> > > >of_create_pci_dev() already has a lot of code that duplicates
> > > >pci_setup_device(), and it's a shame to add more.  There's also a sparc
> > > >version of of_create_pci_dev() that presumably has the same problem 
> > > >you're
> > > >fixing for powerpc.
> > > 
> > > Thanks for the information!
> > > 
> > > >Michael originally called pci_msi_setup_pci_dev() from
> > > >pci_init_capabilities() [1].  A subsequent patch moved the call
> > > >to pci_setup_device() [2] because an early quirk (called from
> > > >pci_setup_device()) used pci_msi_off(), which depended on
> > > >pci_msi_setup_pci_dev().
> > > >
> > > >But we later removed pci_msi_off() completely, so I think we probably
> > > >*could* call pci_msi_setup_pci_dev() from pci_init_capabilities().
> > > >
> > > >That would be much nicer because it makes more sense there, and it
> > > >would do the right thing for powerpc and sparc because they both
> > > >already use that path.
> > > >
> > > >Can you look into moving the call?
> > > 
> > > I might have misunderstood something here (sorry if it's the case), but
> > > moving the call to pci_init_capabilities() has the same practical
> > > implications than reverting my 2 commmits [1] [2] and Michael Tsirkin's
> > > commit [3], except when CONFIG_PCI_MSI is not set - in this case, moving 
> > > the
> > > call would initialize MSI capabilities anyway, since 
> > > pci_init_capabilities()
> > > executes even if CONFIG_PCI_MSI isn't set.
> > > 
> > > My question is: is necessary to initialize MSI capabilities even with
> > > CONFIG_PCI_MSI not set? In negative case, would be "cleaner" revert the 3
> > > commits, right?
> > > 
> > > On the other hand, if it's necessary to initialize MSI capabilities on
> > > devices anyway, we can change the call place.
> > 
> > I think the reason why it's necessary is explained in
> > commit log for commit 1851617cd2da9cc53cdc1738f4148f4f042c0e56 (that's
> > [3] below).
> 
> Well yes and no.
> 
> What we want to do when CONFIG_PCI_MSI=n is disable MSI on the device. In 
> order
> to do that the code first initialises dev->msi[x]_cap.
> 
> But arguably that's wrong, ie. when CONFIG_PCI_MSI=n dev->msi[x]_cap *should*
> be zero so that any code which erroneously tries to use them will fail.

We could also argue that when CONFIG_PCI_MSI=n, dev->msi[x]_cap should not
even exist, so we could catch that a build-time instead of run-time.  My
personal opinion is that it's not a big deal, and the existing code that
includes dev->msi[x]_cap and initializes it even when CONFIG_PCI_MSI=n
allows some useful code sharing.

Bjorn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [v2 04/11] soc/fsl: Introduce drivers for the DPAA QMan

[Roy Pledge]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 9:10 PM
> To: Pledge Roy-R01356 
> Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [v2 04/11] soc/fsl: Introduce drivers for the DPAA QMan
> 
> On Wed, Aug 12, 2015 at 04:14:50PM -0400, Roy Pledge wrote:
> > +/* Lock/unlock frame queues, subject to the "LOCKED" flag. This is
> > +about
> > + * inter-processor locking only. Note, FQLOCK() is always called
> > +either under a
> > + * local_irq_save() or from interrupt context - hence there's no need
> > +for irq
> > + * protection (and indeed, attempting to nest irq-protection doesn't
> > +work, as
> > + * the "irq en/disable" machinery isn't recursive...). */ #define
> > +FQLOCK(fq) \
> > +   do { \
> > +   struct qman_fq *__fq478 = (fq); \
> > +   if (fq_isset(__fq478, QMAN_FQ_FLAG_LOCKED)) \
> > +   spin_lock(&__fq478->fqlock); \
> > +   } while (0)
> > +#define FQUNLOCK(fq) \
> > +   do { \
> > +   struct qman_fq *__fq478 = (fq); \
> > +   if (fq_isset(__fq478, QMAN_FQ_FLAG_LOCKED)) \
> > +   spin_unlock(&__fq478->fqlock); \
> > +   } while (0)
> > +
> 
> I don't see QMAN_FQ_FLAG_LOCKED set anywhere.  What is the use case?

The idea was to allow multiple threads to manipulate the state of a frame queue 
at the same time without clobbering each others changes since the operation is 
a read/modify/write.  I see two users of this flag in code that hasn't been 
submitted upstream yet, but I'm not sure if the use is required in those two 
instances either. At a glance it doesn't seem like it is needed but I would 
need to follow up with the users to make sure they aren't performing FQ 
management commands in multiple threads.

> 
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/2] Fix module autoload for OF platform drivers

[Luis de Bethencourt]

Hello,

These patches add the missing MODULE_DEVICE_TABLE() for OF to export
the information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519

Thanks,
Luis

Luis de Bethencourt (2):
  char: hw_random: Fix module autoload for OF platform drivers
  char: ipmi: Fix module autoload for OF platform driver

 drivers/char/hw_random/pasemi-rng.c | 1 +
 drivers/char/hw_random/ppc4xx-rng.c | 1 +
 drivers/char/ipmi/ipmi_si_intf.c| 1 +
 3 files changed, 3 insertions(+)

-- 
2.4.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 6/9] KVM: PPC: Replace SPAPR_TCE_SHIFT with IOMMU_PAGE_SHIFT_4K

[Alexey Kardashevskiy]

SPAPR_TCE_SHIFT is used in few places only and since IOMMU_PAGE_SHIFT_4K
can be easily used instead, remove SPAPR_TCE_SHIFT.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/kvm_book3s_64.h | 2 --
 arch/powerpc/kvm/book3s_64_vio.c | 3 ++-
 arch/powerpc/kvm/book3s_64_vio_hv.c  | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h 
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 2aa79c8..7529aab 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -33,8 +33,6 @@ static inline void svcpu_put(struct kvmppc_book3s_shadow_vcpu 
*svcpu)
 }
 #endif
 
-#define SPAPR_TCE_SHIFT12
-
 #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
 #define KVM_DEFAULT_HPT_ORDER  24  /* 16MB HPT by default */
 #endif
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index b70787d..e347856 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -36,12 +36,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TCES_PER_PAGE  (PAGE_SIZE / sizeof(u64))
 
 static long kvmppc_stt_npages(unsigned long window_size)
 {
-   return ALIGN((window_size >> SPAPR_TCE_SHIFT)
+   return ALIGN((window_size >> IOMMU_PAGE_SHIFT_4K)
 * sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
 }
 
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c 
b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 8ae12ac..6cf1ab3 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -99,7 +99,7 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long 
liobn,
if (ret)
return ret;
 
-   idx = ioba >> SPAPR_TCE_SHIFT;
+   idx = ioba >> IOMMU_PAGE_SHIFT_4K;
page = stt->pages[idx / TCES_PER_PAGE];
tbl = (u64 *)page_address(page);
 
@@ -121,7 +121,7 @@ long kvmppc_h_get_tce(struct kvm_vcpu *vcpu, unsigned long 
liobn,
if (stt) {
ret = kvmppc_ioba_validate(stt, ioba, 1);
if (!ret) {
-   unsigned long idx = ioba >> SPAPR_TCE_SHIFT;
+   unsigned long idx = ioba >> IOMMU_PAGE_SHIFT_4K;
struct page *page = stt->pages[idx / TCES_PER_PAGE];
u64 *tbl = (u64 *)page_address(page);
 
-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 2/9] KVM: PPC: Make real_vmalloc_addr() public

[Alexey Kardashevskiy]

This helper translates vmalloc'd addresses to linear addresses.
It is only used by the KVM MMU code now and resides in the HV KVM code.
We will need it further in the TCE code and the DMA memory preregistration
code called in real mode.

This makes real_vmalloc_addr() public and moves it to the powerpc code as
it does not do anything special for KVM.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/mmu-hash64.h |  3 +++
 arch/powerpc/kvm/book3s_hv_rm_mmu.c   | 17 -
 arch/powerpc/mm/hash_utils_64.c   | 17 +
 3 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-hash64.h 
b/arch/powerpc/include/asm/mmu-hash64.h
index a82f534..fd06b73 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -606,6 +606,9 @@ static inline unsigned long get_kernel_vsid(unsigned long 
ea, int ssize)
context = (MAX_USER_CONTEXT) + ((ea >> 60) - 0xc) + 1;
return get_vsid(context, ea, ssize);
 }
+
+void *real_vmalloc_addr(void *x);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_MMU_HASH64_H_ */
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c 
b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index c1df9bb..987b7d1 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -22,23 +22,6 @@
 #include 
 #include 
 
-/* Translate address of a vmalloc'd thing to a linear map address */
-static void *real_vmalloc_addr(void *x)
-{
-   unsigned long addr = (unsigned long) x;
-   pte_t *p;
-   /*
-* assume we don't have huge pages in vmalloc space...
-* So don't worry about THP collapse/split. Called
-* Only in realmode, hence won't need irq_save/restore.
-*/
-   p = __find_linux_pte_or_hugepte(swapper_pg_dir, addr, NULL);
-   if (!p || !pte_present(*p))
-   return NULL;
-   addr = (pte_pfn(*p) << PAGE_SHIFT) | (addr & ~PAGE_MASK);
-   return __va(addr);
-}
-
 /* Return 1 if we need to do a global tlbie, 0 if we can use tlbiel */
 static int global_invalidates(struct kvm *kvm, unsigned long flags)
 {
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 5ec987f..9737d6a 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1556,3 +1556,20 @@ void setup_initial_memory_limit(phys_addr_t 
first_memblock_base,
/* Finally limit subsequent allocations */
memblock_set_current_limit(ppc64_rma_size);
 }
+
+/* Translate address of a vmalloc'd thing to a linear map address */
+void *real_vmalloc_addr(void *x)
+{
+   unsigned long addr = (unsigned long) x;
+   pte_t *p;
+   /*
+* assume we don't have huge pages in vmalloc space...
+* So don't worry about THP collapse/split. Called
+* Only in realmode, hence won't need irq_save/restore.
+*/
+   p = __find_linux_pte_or_hugepte(swapper_pg_dir, addr, NULL);
+   if (!p || !pte_present(*p))
+   return NULL;
+   addr = (pte_pfn(*p) << PAGE_SHIFT) | (addr & ~PAGE_MASK);
+   return __va(addr);
+}
-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 7/9] KVM: PPC: Move reusable bits of H_PUT_TCE handler to helpers

[Alexey Kardashevskiy]

Upcoming multi-tce support (H_PUT_TCE_INDIRECT/H_STUFF_TCE hypercalls)
will validate TCE (not to have unexpected bits) and IO address
(to be within the DMA window boundaries).

This introduces helpers to validate TCE and IO address.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/kvm_ppc.h  |  4 ++
 arch/powerpc/kvm/book3s_64_vio_hv.c | 89 -
 2 files changed, 83 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index c6ef05b..fcde896 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -166,6 +166,10 @@ extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
 
 extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args);
+extern long kvmppc_ioba_validate(struct kvmppc_spapr_tce_table *stt,
+   unsigned long ioba, unsigned long npages);
+extern long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *tt,
+   unsigned long tce);
 extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
 unsigned long ioba, unsigned long tce);
 extern long kvmppc_h_get_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c 
b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 6cf1ab3..f0fd84c 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TCES_PER_PAGE  (PAGE_SIZE / sizeof(u64))
 
@@ -64,7 +65,7 @@ static struct kvmppc_spapr_tce_table 
*kvmppc_find_table(struct kvm_vcpu *vcpu,
  * WARNING: This will be called in real-mode on HV KVM and virtual
  *  mode on PR KVM
  */
-static long kvmppc_ioba_validate(struct kvmppc_spapr_tce_table *stt,
+long kvmppc_ioba_validate(struct kvmppc_spapr_tce_table *stt,
unsigned long ioba, unsigned long npages)
 {
unsigned long mask = (1ULL << IOMMU_PAGE_SHIFT_4K) - 1;
@@ -76,6 +77,79 @@ static long kvmppc_ioba_validate(struct 
kvmppc_spapr_tce_table *stt,
 
return H_SUCCESS;
 }
+EXPORT_SYMBOL_GPL(kvmppc_ioba_validate);
+
+/*
+ * Validates TCE address.
+ * At the moment flags and page mask are validated.
+ * As the host kernel does not access those addresses (just puts them
+ * to the table and user space is supposed to process them), we can skip
+ * checking other things (such as TCE is a guest RAM address or the page
+ * was actually allocated).
+ *
+ * WARNING: This will be called in real-mode on HV KVM and virtual
+ *  mode on PR KVM
+ */
+long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt, unsigned long tce)
+{
+   unsigned long mask = ((1ULL << IOMMU_PAGE_SHIFT_4K) - 1) &
+   ~(TCE_PCI_WRITE | TCE_PCI_READ);
+
+   if (tce & mask)
+   return H_PARAMETER;
+
+   return H_SUCCESS;
+}
+EXPORT_SYMBOL_GPL(kvmppc_tce_validate);
+
+/* Note on the use of page_address() in real mode,
+ *
+ * It is safe to use page_address() in real mode on ppc64 because
+ * page_address() is always defined as lowmem_page_address()
+ * which returns __va(PFN_PHYS(page_to_pfn(page))) which is arithmetial
+ * operation and does not access page struct.
+ *
+ * Theoretically page_address() could be defined different
+ * but either WANT_PAGE_VIRTUAL or HASHED_PAGE_VIRTUAL
+ * should be enabled.
+ * WANT_PAGE_VIRTUAL is never enabled on ppc32/ppc64,
+ * HASHED_PAGE_VIRTUAL could be enabled for ppc32 only and only
+ * if CONFIG_HIGHMEM is defined. As CONFIG_SPARSEMEM_VMEMMAP
+ * is not expected to be enabled on ppc32, page_address()
+ * is safe for ppc32 as well.
+ *
+ * WARNING: This will be called in real-mode on HV KVM and virtual
+ *  mode on PR KVM
+ */
+static u64 *kvmppc_page_address(struct page *page)
+{
+#if defined(HASHED_PAGE_VIRTUAL) || defined(WANT_PAGE_VIRTUAL)
+#error TODO: fix to avoid page_address() here
+#endif
+   return (u64 *) page_address(page);
+}
+
+/*
+ * Handles TCE requests for emulated devices.
+ * Puts guest TCE values to the table and expects user space to convert them.
+ * Called in both real and virtual modes.
+ * Cannot fail so kvmppc_tce_validate must be called before it.
+ *
+ * WARNING: This will be called in real-mode on HV KVM and virtual
+ *  mode on PR KVM
+ */
+void kvmppc_tce_put(struct kvmppc_spapr_tce_table *stt,
+   unsigned long idx, unsigned long tce)
+{
+   struct page *page;
+   u64 *tbl;
+
+   page = stt->pages[idx / TCES_PER_PAGE];
+   tbl = kvmppc_page_address(page);
+
+   tbl[idx % TCES_PER_PAGE] = tce;
+}
+EXPORT_SYMBOL_GPL(kvmppc_tce_put);
 
 /* WARNING: This will be called in real-mode on HV KVM and virtual
  *  mode on PR KVM
@@ -85,9 +159,6 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long 
liobn,
 {
struct kvmppc_spapr_tce_table *stt 

RE: [PATCH 2/3] drivers/ps3: Fix ps3-vuart null dereference

[David Laight]

From: Colin Ian King
> Sent: 14 September 2015 20:35
> On the unlikely event that drv is null, the current code will
> perform a null pointer dereference with it when printing a dev_dbg
> message.  Instead, the BUG_ON check on drv should be performed
> before we emit the dev_dbg message.
...
> diff --git a/drivers/ps3/ps3-vuart.c b/drivers/ps3/ps3-vuart.c
> index d6db822..632701a 100644
> --- a/drivers/ps3/ps3-vuart.c
> +++ b/drivers/ps3/ps3-vuart.c
> @@ -1000,12 +1000,11 @@ static int ps3_vuart_probe(struct 
> ps3_system_bus_device *dev)
>   dev_dbg(>core, "%s:%d\n", __func__, __LINE__);
> 
>   drv = ps3_system_bus_dev_to_vuart_drv(dev);
> + BUG_ON(!drv);
> 
>   dev_dbg(>core, "%s:%d: (%s)\n", __func__, __LINE__,
>   drv->core.core.name);
> 
> - BUG_ON(!drv);
> -

Just delete the BUG_ON(), it is just as easy to debug the dereference.

David

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 0/9] KVM: PPC: Add in-kernel multitce handling

[Alexey Kardashevskiy]

These patches enable in-kernel acceleration for H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls which allow doing multiple (up to 512) TCE entries
update in a single call saving time on switching context. QEMU already
supports these hypercalls so this is just an optimization.

Both HV and PR KVM modes are supported.

This does not affect VFIO, this support is coming next.

Please comment. Thanks.


Alexey Kardashevskiy (9):
  rcu: Define notrace version of list_for_each_entry_rcu
  KVM: PPC: Make real_vmalloc_addr() public
  KVM: PPC: Rework H_PUT_TCE/H_GET_TCE handlers
  KVM: PPC: Use RCU for arch.spapr_tce_tables
  KVM: PPC: Account TCE-containing pages in locked_vm
  KVM: PPC: Replace SPAPR_TCE_SHIFT with IOMMU_PAGE_SHIFT_4K
  KVM: PPC: Move reusable bits of H_PUT_TCE handler to helpers
  KVM: Fix KVM_SMI chapter number
  KVM: PPC: Add support for multiple-TCE hcalls

 Documentation/virtual/kvm/api.txt|  27 ++-
 arch/powerpc/include/asm/kvm_book3s_64.h |   2 -
 arch/powerpc/include/asm/kvm_host.h  |   1 +
 arch/powerpc/include/asm/kvm_ppc.h   |  16 ++
 arch/powerpc/include/asm/mmu-hash64.h|   3 +
 arch/powerpc/kvm/book3s.c|   2 +-
 arch/powerpc/kvm/book3s_64_vio.c | 185 --
 arch/powerpc/kvm/book3s_64_vio_hv.c  | 310 +++
 arch/powerpc/kvm/book3s_hv.c |  26 ++-
 arch/powerpc/kvm/book3s_hv_rm_mmu.c  |  17 --
 arch/powerpc/kvm/book3s_hv_rmhandlers.S  |   6 +-
 arch/powerpc/kvm/book3s_pr_papr.c|  35 
 arch/powerpc/kvm/powerpc.c   |   3 +
 arch/powerpc/mm/hash_utils_64.c  |  17 ++
 include/linux/rculist.h  |  38 
 15 files changed, 610 insertions(+), 78 deletions(-)

-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 1/9] rcu: Define notrace version of list_for_each_entry_rcu

[Alexey Kardashevskiy]

This defines list_for_each_entry_rcu_notrace and list_entry_rcu_notrace
which use rcu_dereference_raw_notrace instead of rcu_dereference_raw.
This allows using list_for_each_entry_rcu_notrace in real mode (MMU is off).

Signed-off-by: Alexey Kardashevskiy 
---
 include/linux/rculist.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 17c6b1f..439c4d7 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -253,6 +253,25 @@ static inline void list_splice_init_rcu(struct list_head 
*list,
 })
 
 /**
+ * list_entry_rcu_notrace - get the struct for this entry
+ * @ptr:the  list_head pointer.
+ * @type:   the type of the struct this is embedded in.
+ * @member: the name of the list_struct within the struct.
+ *
+ * This primitive may safely run concurrently with the _rcu list-mutation
+ * primitives such as list_add_rcu() as long as it's guarded by 
rcu_read_lock().
+ *
+ * This is the same as list_entry_rcu() except that it does
+ * not do any RCU debugging or tracing.
+ */
+#define list_entry_rcu_notrace(ptr, type, member) \
+({ \
+   typeof(*ptr) __rcu *__ptr = (typeof(*ptr) __rcu __force *)ptr; \
+   container_of((typeof(ptr))rcu_dereference_raw_notrace(__ptr), \
+   type, member); \
+})
+
+/**
  * Where are list_empty_rcu() and list_first_entry_rcu()?
  *
  * Implementing those functions following their counterparts list_empty() and
@@ -308,6 +327,25 @@ static inline void list_splice_init_rcu(struct list_head 
*list,
pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
 
 /**
+ * list_for_each_entry_rcu_notrace - iterate over rcu list of given type
+ * @pos:   the type * to use as a loop cursor.
+ * @head:  the head for your list.
+ * @member:the name of the list_struct within the struct.
+ *
+ * This list-traversal primitive may safely run concurrently with
+ * the _rcu list-mutation primitives such as list_add_rcu()
+ * as long as the traversal is guarded by rcu_read_lock().
+ *
+ * This is the same as list_for_each_entry_rcu() except that it does
+ * not do any RCU debugging or tracing.
+ */
+#define list_for_each_entry_rcu_notrace(pos, head, member) \
+   for (pos = list_entry_rcu_notrace((head)->next, typeof(*pos), member); \
+   >member != (head); \
+   pos = list_entry_rcu_notrace(pos->member.next, typeof(*pos), \
+   member))
+
+/**
  * list_for_each_entry_continue_rcu - continue iteration over list of given 
type
  * @pos:   the type * to use as a loop cursor.
  * @head:  the head for your list.
-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 4/9] KVM: PPC: Use RCU for arch.spapr_tce_tables

[Alexey Kardashevskiy]

At the moment spapr_tce_tables is not protected against races. This makes
use of RCU-variants of list helpers. As some bits are executed in real
mode, this makes use of just introduced list_for_each_entry_rcu_notrace().

This converts release_spapr_tce_table() to a RCU scheduled handler.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/kvm_host.h |  1 +
 arch/powerpc/kvm/book3s.c   |  2 +-
 arch/powerpc/kvm/book3s_64_vio.c| 20 +++-
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 98eebbf6..e19d412 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -178,6 +178,7 @@ struct kvmppc_spapr_tce_table {
struct kvm *kvm;
u64 liobn;
u32 window_size;
+   struct rcu_head rcu;
struct page *pages[0];
 };
 
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 53285d5..3418f7c 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -806,7 +806,7 @@ int kvmppc_core_init_vm(struct kvm *kvm)
 {
 
 #ifdef CONFIG_PPC64
-   INIT_LIST_HEAD(>arch.spapr_tce_tables);
+   INIT_LIST_HEAD_RCU(>arch.spapr_tce_tables);
INIT_LIST_HEAD(>arch.rtas_tokens);
 #endif
 
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 54cf9bc..9526c34 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -45,19 +45,16 @@ static long kvmppc_stt_npages(unsigned long window_size)
 * sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
 }
 
-static void release_spapr_tce_table(struct kvmppc_spapr_tce_table *stt)
+static void release_spapr_tce_table(struct rcu_head *head)
 {
-   struct kvm *kvm = stt->kvm;
+   struct kvmppc_spapr_tce_table *stt = container_of(head,
+   struct kvmppc_spapr_tce_table, rcu);
int i;
 
-   mutex_lock(>lock);
-   list_del(>list);
for (i = 0; i < kvmppc_stt_npages(stt->window_size); i++)
__free_page(stt->pages[i]);
+
kfree(stt);
-   mutex_unlock(>lock);
-
-   kvm_put_kvm(kvm);
 }
 
 static int kvm_spapr_tce_fault(struct vm_area_struct *vma, struct vm_fault 
*vmf)
@@ -88,7 +85,12 @@ static int kvm_spapr_tce_release(struct inode *inode, struct 
file *filp)
 {
struct kvmppc_spapr_tce_table *stt = filp->private_data;
 
-   release_spapr_tce_table(stt);
+   list_del_rcu(>list);
+
+   kvm_put_kvm(stt->kvm);
+
+   call_rcu(>rcu, release_spapr_tce_table);
+
return 0;
 }
 
@@ -131,7 +133,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
kvm_get_kvm(kvm);
 
mutex_lock(>lock);
-   list_add(>list, >arch.spapr_tce_tables);
+   list_add_rcu(>list, >arch.spapr_tce_tables);
 
mutex_unlock(>lock);
 
-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 9/9] KVM: PPC: Add support for multiple-TCE hcalls

[Alexey Kardashevskiy]

This adds real and virtual mode handlers for the H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO
devices or emulated PCI.  These calls allow adding multiple entries
(up to 512) into the TCE table in one call which saves time on
transition between kernel and user space.

This implements the KVM_CAP_PPC_MULTITCE capability. When present,
the kernel will try handling H_PUT_TCE_INDIRECT and H_STUFF_TCE.
If they can not be handled by the kernel, they are passed on to
the user space. The user space still has to have an implementation
for these.

Both HV and PR-syle KVM are supported.

Signed-off-by: Alexey Kardashevskiy 
---
 Documentation/virtual/kvm/api.txt   |  25 ++
 arch/powerpc/include/asm/kvm_ppc.h  |  12 +++
 arch/powerpc/kvm/book3s_64_vio.c| 111 +++-
 arch/powerpc/kvm/book3s_64_vio_hv.c | 145 ++--
 arch/powerpc/kvm/book3s_hv.c|  26 +-
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |   6 +-
 arch/powerpc/kvm/book3s_pr_papr.c   |  35 
 arch/powerpc/kvm/powerpc.c  |   3 +
 8 files changed, 350 insertions(+), 13 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index d86d831..593c62a 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3019,6 +3019,31 @@ Returns: 0 on success, -1 on error
 
 Queues an SMI on the thread's vcpu.
 
+4.97 KVM_CAP_PPC_MULTITCE
+
+Capability: KVM_CAP_PPC_MULTITCE
+Architectures: ppc
+Type: vm
+
+This capability means the kernel is capable of handling hypercalls
+H_PUT_TCE_INDIRECT and H_STUFF_TCE without passing those into the user
+space. This significantly accelerates DMA operations for PPC KVM guests.
+User space should expect that its handlers for these hypercalls
+are not going to be called if user space previously registered LIOBN
+in KVM (via KVM_CREATE_SPAPR_TCE or similar calls).
+
+In order to enable H_PUT_TCE_INDIRECT and H_STUFF_TCE use in the guest,
+user space might have to advertise it for the guest. For example,
+IBM pSeries (sPAPR) guest starts using them if "hcall-multi-tce" is
+present in the "ibm,hypertas-functions" device-tree property.
+
+The hypercalls mentioned above may or may not be processed successfully
+in the kernel based fast path. If they can not be handled by the kernel,
+they will get passed on to user space. So user space still has to have
+an implementation for these despite the in kernel acceleration.
+
+This capability is always enabled.
+
 5. The kvm_run structure
 
 
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index fcde896..e5b968e 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -166,12 +166,24 @@ extern int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu);
 
 extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args);
+extern struct kvmppc_spapr_tce_table *kvmppc_find_table(
+   struct kvm_vcpu *vcpu, unsigned long liobn);
 extern long kvmppc_ioba_validate(struct kvmppc_spapr_tce_table *stt,
unsigned long ioba, unsigned long npages);
 extern long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *tt,
unsigned long tce);
+extern long kvmppc_gpa_to_ua(struct kvm *kvm, unsigned long gpa,
+   unsigned long *ua, unsigned long **prmap);
+extern void kvmppc_tce_put(struct kvmppc_spapr_tce_table *tt,
+   unsigned long idx, unsigned long tce);
 extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
 unsigned long ioba, unsigned long tce);
+extern long kvmppc_h_put_tce_indirect(struct kvm_vcpu *vcpu,
+   unsigned long liobn, unsigned long ioba,
+   unsigned long tce_list, unsigned long npages);
+extern long kvmppc_h_stuff_tce(struct kvm_vcpu *vcpu,
+   unsigned long liobn, unsigned long ioba,
+   unsigned long tce_value, unsigned long npages);
 extern long kvmppc_h_get_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
 unsigned long ioba);
 extern struct page *kvm_alloc_hpt(unsigned long nr_pages);
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index e347856..d3fc732 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -14,6 +14,7 @@
  *
  * Copyright 2010 Paul Mackerras, IBM Corp. 
  * Copyright 2011 David Gibson, IBM Corporation 
+ * Copyright 2013 Alexey Kardashevskiy, IBM Corporation 
  */
 
 #include 
@@ -37,8 +38,7 @@
 #include 
 #include 
 #include 
-
-#define TCES_PER_PAGE  (PAGE_SIZE / sizeof(u64))
+#include 
 
 static long kvmppc_stt_npages(unsigned long window_size)
 {
@@ -200,3 +200,110 @@ fail:
}

[PATCH v2] powerpc: msi: mark bitmap with kmemleak_not_leak()

[Denis Kirjanov]

During the MSI bitmap test on boot kmemleak spews the following trace:

unreferenced object 0xc0016e86c900 (size 64):
comm "swapper/0", pid 1, jiffies 4294893173 (age 518.024s)
hex dump (first 32 bytes):
00 00 01 ff 7f ff 7f 37 00 00 00 00 00 00 00 00
...7
ff ff ff ff ff ff ff ff 01 ff ff ff ff
ff ff ff

backtrace:
[] .zalloc_maybe_bootmem+0x3c/0x380
[] .msi_bitmap_alloc+0x3c/0xb0
[] .msi_bitmap_selftest+0x30/0x2b4
[] .do_one_initcall+0xd4/0x270
[] .kernel_init_freeable+0x1a0/0x280
[] .kernel_init+0x1c/0x120
[] .ret_from_kernel_thread+0x58/0x9c

Added a flag to msi_bitmap for tracking allocations
from slab and memblock so we can properly free/handle
memory in msi_bitmap_free().

Signed-off-by: Denis Kirjanov 

Changes vor v2:
 - added a flag to msi_bitmap
 - kmemleak annotaion moved under CONFIG_MSI_BITMAP_SELFTEST
---
 arch/powerpc/include/asm/msi_bitmap.h |  1 +
 arch/powerpc/sysdev/msi_bitmap.c  | 15 +++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/msi_bitmap.h 
b/arch/powerpc/include/asm/msi_bitmap.h
index 97ac3f4..9a1d2fb 100644
--- a/arch/powerpc/include/asm/msi_bitmap.h
+++ b/arch/powerpc/include/asm/msi_bitmap.h
@@ -19,6 +19,7 @@ struct msi_bitmap {
unsigned long   *bitmap;
spinlock_t  lock;
unsigned intirq_count;
+   boolbitmap_from_slab;
 };
 
 int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num);
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index 73b64c7..305ebe3 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -122,7 +123,12 @@ int msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int 
irq_count,
size = BITS_TO_LONGS(irq_count) * sizeof(long);
pr_debug("msi_bitmap: allocator bitmap size is 0x%x bytes\n", size);
 
-   bmp->bitmap = zalloc_maybe_bootmem(size, GFP_KERNEL);
+   if (slab_is_available()) {
+   bmp->bitmap = kzalloc(size, GFP_KERNEL);
+   bmp->bitmap_from_slab = true;
+   } else
+   bmp->bitmap = memblock_virt_alloc(size, 0);
+
if (!bmp->bitmap) {
pr_debug("msi_bitmap: ENOMEM allocating allocator bitmap!\n");
return -ENOMEM;
@@ -138,7 +144,8 @@ int msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int 
irq_count,
 
 void msi_bitmap_free(struct msi_bitmap *bmp)
 {
-   /* we can't free the bitmap we don't know if it's bootmem etc. */
+   if (bmp->bitmap_from_slab)
+   kfree(bmp->bitmap);
of_node_put(bmp->of_node);
bmp->bitmap = NULL;
 }
@@ -200,11 +207,11 @@ static void __init test_basics(void)
WARN_ON(rc < 0 && rc % 128 != 0);
 
msi_bitmap_free();
+   if (!bmp.bitmap_from_slab)
+   kmemleak_not_leak(bmp.bitmap);
 
/* Clients may WARN_ON bitmap == NULL for "not-allocated" */
WARN_ON(bmp.bitmap != NULL);
-
-   kfree(bmp.bitmap);
 }
 
 static void __init test_of_node(void)
-- 
2.4.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] char: hw_random: Fix module autoload for OF platform drivers

[Luis de Bethencourt]

This platform drivers have a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
---
 drivers/char/hw_random/pasemi-rng.c | 1 +
 drivers/char/hw_random/ppc4xx-rng.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/char/hw_random/pasemi-rng.c 
b/drivers/char/hw_random/pasemi-rng.c
index 3eb7bdd..20d6564 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -138,6 +138,7 @@ static struct of_device_id rng_match[] = {
{ .compatible  = "pasemi,pwrficient-rng", },
{ },
 };
+MODULE_DEVICE_TABLE(of, rng_match);
 
 static struct platform_driver rng_driver = {
.driver = {
diff --git a/drivers/char/hw_random/ppc4xx-rng.c 
b/drivers/char/hw_random/ppc4xx-rng.c
index c85d31a..145e273 100644
--- a/drivers/char/hw_random/ppc4xx-rng.c
+++ b/drivers/char/hw_random/ppc4xx-rng.c
@@ -129,6 +129,7 @@ static struct of_device_id ppc4xx_rng_match[] = {
{ .compatible = "amcc,ppc440epx-rng", },
{},
 };
+MODULE_DEVICE_TABLE(of, ppc4xx_rng_match);
 
 static struct platform_driver ppc4xx_rng_driver = {
.driver = {
-- 
2.4.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 3/9] KVM: PPC: Rework H_PUT_TCE/H_GET_TCE handlers

[Alexey Kardashevskiy]

This reworks the existing H_PUT_TCE/H_GET_TCE handlers to have one
exit path. This allows next patch to add locks nicely.

This moves the ioba boundaries check to a helper and adds a check for
least bits which have to be zeros.

The patch is pretty mechanical (only check for least ioba bits is added)
so no change in behaviour is expected.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/kvm/book3s_64_vio_hv.c | 102 +++-
 1 file changed, 66 insertions(+), 36 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c 
b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 89e96b3..8ae12ac 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -35,71 +35,101 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TCES_PER_PAGE  (PAGE_SIZE / sizeof(u64))
 
+/*
+ * Finds a TCE table descriptor by LIOBN.
+ *
+ * WARNING: This will be called in real or virtual mode on HV KVM and virtual
+ *  mode on PR KVM
+ */
+static struct kvmppc_spapr_tce_table *kvmppc_find_table(struct kvm_vcpu *vcpu,
+   unsigned long liobn)
+{
+   struct kvm *kvm = vcpu->kvm;
+   struct kvmppc_spapr_tce_table *stt;
+
+   list_for_each_entry_rcu_notrace(stt, >arch.spapr_tce_tables, list)
+   if (stt->liobn == liobn)
+   return stt;
+
+   return NULL;
+}
+
+/*
+ * Validates IO address.
+ *
+ * WARNING: This will be called in real-mode on HV KVM and virtual
+ *  mode on PR KVM
+ */
+static long kvmppc_ioba_validate(struct kvmppc_spapr_tce_table *stt,
+   unsigned long ioba, unsigned long npages)
+{
+   unsigned long mask = (1ULL << IOMMU_PAGE_SHIFT_4K) - 1;
+   unsigned long idx = ioba >> IOMMU_PAGE_SHIFT_4K;
+   unsigned long size = stt->window_size >> IOMMU_PAGE_SHIFT_4K;
+
+   if ((ioba & mask) || (size + npages <= idx))
+   return H_PARAMETER;
+
+   return H_SUCCESS;
+}
+
 /* WARNING: This will be called in real-mode on HV KVM and virtual
  *  mode on PR KVM
  */
 long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
  unsigned long ioba, unsigned long tce)
 {
-   struct kvm *kvm = vcpu->kvm;
-   struct kvmppc_spapr_tce_table *stt;
+   struct kvmppc_spapr_tce_table *stt = kvmppc_find_table(vcpu, liobn);
+   long ret = H_TOO_HARD;
+   unsigned long idx;
+   struct page *page;
+   u64 *tbl;
 
/* udbg_printf("H_PUT_TCE(): liobn=0x%lx ioba=0x%lx, tce=0x%lx\n", */
/*  liobn, ioba, tce); */
 
-   list_for_each_entry(stt, >arch.spapr_tce_tables, list) {
-   if (stt->liobn == liobn) {
-   unsigned long idx = ioba >> SPAPR_TCE_SHIFT;
-   struct page *page;
-   u64 *tbl;
+   if (!stt)
+   return ret;
 
-   /* udbg_printf("H_PUT_TCE: liobn 0x%lx => stt=%p  
window_size=0x%x\n", */
-   /*  liobn, stt, stt->window_size); */
-   if (ioba >= stt->window_size)
-   return H_PARAMETER;
+   ret = kvmppc_ioba_validate(stt, ioba, 1);
+   if (ret)
+   return ret;
 
-   page = stt->pages[idx / TCES_PER_PAGE];
-   tbl = (u64 *)page_address(page);
+   idx = ioba >> SPAPR_TCE_SHIFT;
+   page = stt->pages[idx / TCES_PER_PAGE];
+   tbl = (u64 *)page_address(page);
 
-   /* FIXME: Need to validate the TCE itself */
-   /* udbg_printf("tce @ %p\n", [idx % 
TCES_PER_PAGE]); */
-   tbl[idx % TCES_PER_PAGE] = tce;
-   return H_SUCCESS;
-   }
-   }
+   /* FIXME: Need to validate the TCE itself */
+   /* udbg_printf("tce @ %p\n", [idx % TCES_PER_PAGE]); */
+   tbl[idx % TCES_PER_PAGE] = tce;
 
-   /* Didn't find the liobn, punt it to userspace */
-   return H_TOO_HARD;
+   return ret;
 }
 EXPORT_SYMBOL_GPL(kvmppc_h_put_tce);
 
 long kvmppc_h_get_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
  unsigned long ioba)
 {
-   struct kvm *kvm = vcpu->kvm;
-   struct kvmppc_spapr_tce_table *stt;
+   struct kvmppc_spapr_tce_table *stt = kvmppc_find_table(vcpu, liobn);
+   long ret = H_TOO_HARD;
 
-   list_for_each_entry(stt, >arch.spapr_tce_tables, list) {
-   if (stt->liobn == liobn) {
+
+   if (stt) {
+   ret = kvmppc_ioba_validate(stt, ioba, 1);
+   if (!ret) {
unsigned long idx = ioba >> SPAPR_TCE_SHIFT;
-   struct page *page;
-   u64 *tbl;
-
-   if (ioba >= stt->window_size)
-   return H_PARAMETER;
-
-   page = stt->pages[idx / TCES_PER_PAGE];
-   tbl = (u64 *)page_address(page);

[PATCH kernel 5/9] KVM: PPC: Account TCE-containing pages in locked_vm

[Alexey Kardashevskiy]

At the moment pages used for TCE tables (in addition to pages addressed
by TCEs) are not counted in locked_vm counter so a malicious userspace
tool can call ioctl(KVM_CREATE_SPAPR_TCE) as many times as RLIMIT_NOFILE and
lock a lot of memory.

This adds counting for pages used for TCE tables.

This counts the number of pages required for a table plus pages for
the kvmppc_spapr_tce_table struct (TCE table descriptor) itself.

This does not change the amount of (de)allocated memory.

Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/kvm/book3s_64_vio.c | 51 +++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 9526c34..b70787d 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -45,13 +45,56 @@ static long kvmppc_stt_npages(unsigned long window_size)
 * sizeof(u64), PAGE_SIZE) / PAGE_SIZE;
 }
 
+static long kvmppc_account_memlimit(long npages, bool inc)
+{
+   long ret = 0;
+   const long bytes = sizeof(struct kvmppc_spapr_tce_table) +
+   (abs(npages) * sizeof(struct page *));
+   const long stt_pages = ALIGN(bytes, PAGE_SIZE) / PAGE_SIZE;
+
+   if (!current || !current->mm)
+   return ret; /* process exited */
+
+   npages += stt_pages;
+
+   down_write(>mm->mmap_sem);
+
+   if (inc) {
+   long locked, lock_limit;
+
+   locked = current->mm->locked_vm + npages;
+   lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+   if (locked > lock_limit && !capable(CAP_IPC_LOCK))
+   ret = -ENOMEM;
+   else
+   current->mm->locked_vm += npages;
+   } else {
+   if (npages > current->mm->locked_vm)
+   npages = current->mm->locked_vm;
+
+   current->mm->locked_vm -= npages;
+   }
+
+   pr_debug("[%d] RLIMIT_MEMLOCK KVM %c%ld %ld/%ld%s\n", current->pid,
+   inc ? '+' : '-',
+   npages << PAGE_SHIFT,
+   current->mm->locked_vm << PAGE_SHIFT,
+   rlimit(RLIMIT_MEMLOCK),
+   ret ? " - exceeded" : "");
+
+   up_write(>mm->mmap_sem);
+
+   return ret;
+}
+
 static void release_spapr_tce_table(struct rcu_head *head)
 {
struct kvmppc_spapr_tce_table *stt = container_of(head,
struct kvmppc_spapr_tce_table, rcu);
int i;
+   long npages = kvmppc_stt_npages(stt->window_size);
 
-   for (i = 0; i < kvmppc_stt_npages(stt->window_size); i++)
+   for (i = 0; i < npages; i++)
__free_page(stt->pages[i]);
 
kfree(stt);
@@ -89,6 +132,7 @@ static int kvm_spapr_tce_release(struct inode *inode, struct 
file *filp)
 
kvm_put_kvm(stt->kvm);
 
+   kvmppc_account_memlimit(kvmppc_stt_npages(stt->window_size), false);
call_rcu(>rcu, release_spapr_tce_table);
 
return 0;
@@ -114,6 +158,11 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
}
 
npages = kvmppc_stt_npages(args->window_size);
+   ret = kvmppc_account_memlimit(npages, true);
+   if (ret) {
+   stt = NULL;
+   goto fail;
+   }
 
stt = kzalloc(sizeof(*stt) + npages * sizeof(struct page *),
  GFP_KERNEL);
-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH kernel 8/9] KVM: Fix KVM_SMI chapter number

[Alexey Kardashevskiy]

The KVM_SMI capability is following the KVM_S390_SET_IRQ_STATE capability
which is "4.95", this changes the number of the KVM_SMI chapter to 4.96.

Signed-off-by: Alexey Kardashevskiy 
---
 Documentation/virtual/kvm/api.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index d9eccee..d86d831 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3009,7 +3009,7 @@ len must be a multiple of sizeof(struct kvm_s390_irq). It 
must be > 0
 and it must not exceed (max_vcpus + 32) * sizeof(struct kvm_s390_irq),
 which is the maximum number of possibly pending cpu-local interrupts.
 
-4.90 KVM_SMI
+4.96 KVM_SMI
 
 Capability: KVM_CAP_X86_SMM
 Architectures: x86
-- 
2.4.0.rc3.8.gfb3e7d5

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev