Re: linux-next: manual merge of the pm tree with the arm-soc tree

[Arnd Bergmann]

On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the pm tree got a conflict in:
>
>   include/dt-bindings/genpd/k2g.h
>
> between commit:
>
>   7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>
> from the arm-soc tree and commit:
>
>   45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>
> from the pm tree.
>
> I fixed it up (I just used the pm tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Dave, Santosh,

any idea what happened here? It seems that we picked up the wrong
version of the tree, do we need to drop this from arm-soc?

Arnd

Re: linux-next: manual merge of the pm tree with the arm-soc tree

[Arnd Bergmann]

On Fri, Apr 21, 2017 at 2:54 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the pm tree got a conflict in:
>
>   include/dt-bindings/genpd/k2g.h
>
> between commit:
>
>   7cc119f29b19 ("dt-bindings: Add TI SCI PM Domains")
>
> from the arm-soc tree and commit:
>
>   45da8edd1741 ("dt-bindings: Add TI SCI PM Domains")
>
> from the pm tree.
>
> I fixed it up (I just used the pm tree version) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Dave, Santosh,

any idea what happened here? It seems that we picked up the wrong
version of the tree, do we need to drop this from arm-soc?

Arnd

Re: [PATCH 05/28] drm/bridge: fix include notation and remove -Iinclude/drm flag

[Andrzej Hajda]

Hi Masahiro,

On 20.04.2017 11:56, Masahiro Yamada wrote:
> Include  instead of relative path from include/drm, then
> remove the -Iinclude/drm compiler flag.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/gpu/drm/bridge/Makefile|  2 --
>  drivers/gpu/drm/bridge/nxp-ptn3460.c   | 10 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c |  8 
>  3 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 3fe2226..defcf1e 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,3 @@
> -ccflags-y := -Iinclude/drm
> -
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
> b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> index 3517043..3fc285a 100644
> --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> @@ -24,11 +24,11 @@
>  #include 
>  #include 
>  
> -#include "drm_crtc.h"
> -#include "drm_crtc_helper.h"
> -#include "drm_atomic_helper.h"
> -#include "drm_edid.h"
> -#include "drmP.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Could you merge these includes with the ones above and sort them
alphabetically.

>  
>  #define PTN3460_EDID_ADDR0x0
>  #define PTN3460_EDID_EMULATION_ADDR  0x84
> diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
> b/drivers/gpu/drm/bridge/parade-ps8622.c
> index 1dcec3b..ada2186 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8622.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8622.c
> @@ -28,10 +28,10 @@
>  #include 
>  #include 
>  
> -#include "drmP.h"
> -#include "drm_crtc.h"
> -#include "drm_crtc_helper.h"
> -#include "drm_atomic_helper.h"
> +#include 
> +#include 
> +#include 
> +#include 

Ditto.

After this change you can add my:
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej


>  
>  /* Brightness scale on the Parade chip */
>  #define PS8622_MAX_BRIGHTNESS 0xff

Re: [PATCH 05/28] drm/bridge: fix include notation and remove -Iinclude/drm flag

[Andrzej Hajda]

Hi Masahiro,

On 20.04.2017 11:56, Masahiro Yamada wrote:
> Include  instead of relative path from include/drm, then
> remove the -Iinclude/drm compiler flag.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/gpu/drm/bridge/Makefile|  2 --
>  drivers/gpu/drm/bridge/nxp-ptn3460.c   | 10 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c |  8 
>  3 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 3fe2226..defcf1e 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,3 @@
> -ccflags-y := -Iinclude/drm
> -
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
> b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> index 3517043..3fc285a 100644
> --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> @@ -24,11 +24,11 @@
>  #include 
>  #include 
>  
> -#include "drm_crtc.h"
> -#include "drm_crtc_helper.h"
> -#include "drm_atomic_helper.h"
> -#include "drm_edid.h"
> -#include "drmP.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Could you merge these includes with the ones above and sort them
alphabetically.

>  
>  #define PTN3460_EDID_ADDR0x0
>  #define PTN3460_EDID_EMULATION_ADDR  0x84
> diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
> b/drivers/gpu/drm/bridge/parade-ps8622.c
> index 1dcec3b..ada2186 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8622.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8622.c
> @@ -28,10 +28,10 @@
>  #include 
>  #include 
>  
> -#include "drmP.h"
> -#include "drm_crtc.h"
> -#include "drm_crtc_helper.h"
> -#include "drm_atomic_helper.h"
> +#include 
> +#include 
> +#include 
> +#include 

Ditto.

After this change you can add my:
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej


>  
>  /* Brightness scale on the Parade chip */
>  #define PS8622_MAX_BRIGHTNESS 0xff

[PATCH 2/3] crypto: cavium: Remove the individual encrypt/decrypt function for each algorithm

[George Cherian]

Remove the individual encrypt/decrypt function for easch algorithm.
This is in prepration of adding more crypto algorithms supported by
hardware. While at that simplify create_ctx_hdr/create_input_list
function interfaces.

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_algs.c | 133 +
 drivers/crypto/cavium/cpt/cptvf_algs.h |   7 ++
 2 files changed, 77 insertions(+), 63 deletions(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c 
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index cc853f9..c365fc6 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -98,7 +98,6 @@ static inline void update_output_data(struct cpt_request_info 
*req_info,
 }
 
 static inline u32 create_ctx_hdr(struct ablkcipher_request *req, u32 enc,
-u32 cipher_type, u32 aes_key_type,
 u32 *argcnt)
 {
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
@@ -124,11 +123,11 @@ static inline u32 create_ctx_hdr(struct 
ablkcipher_request *req, u32 enc,
req_info->req.param1 = req->nbytes; /* Encryption Data length */
req_info->req.param2 = 0; /*Auth data length */
 
-   fctx->enc.enc_ctrl.e.enc_cipher = cipher_type;
-   fctx->enc.enc_ctrl.e.aes_key = aes_key_type;
+   fctx->enc.enc_ctrl.e.enc_cipher = ctx->cipher_type;
+   fctx->enc.enc_ctrl.e.aes_key = ctx->key_type;
fctx->enc.enc_ctrl.e.iv_source = FROM_DPTR;
 
-   if (cipher_type == AES_XTS)
+   if (ctx->cipher_type == AES_XTS)
memcpy(fctx->enc.encr_key, ctx->enc_key, ctx->key_len * 2);
else
memcpy(fctx->enc.encr_key, ctx->enc_key, ctx->key_len);
@@ -154,14 +153,13 @@ static inline u32 create_ctx_hdr(struct 
ablkcipher_request *req, u32 enc,
 }
 
 static inline u32 create_input_list(struct ablkcipher_request  *req, u32 enc,
-   u32 cipher_type, u32 aes_key_type,
u32 enc_iv_len)
 {
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
struct cpt_request_info *req_info = >cpt_req;
u32 argcnt =  0;
 
-   create_ctx_hdr(req, enc, cipher_type, aes_key_type, );
+   create_ctx_hdr(req, enc, );
update_input_iv(req_info, req->info, enc_iv_len, );
update_input_data(req_info, req->src, req->nbytes, );
req_info->incnt = argcnt;
@@ -177,7 +175,6 @@ static inline void store_cb_info(struct ablkcipher_request 
*req,
 }
 
 static inline void create_output_list(struct ablkcipher_request *req,
- u32 cipher_type,
  u32 enc_iv_len)
 {
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
@@ -197,12 +194,9 @@ static inline void create_output_list(struct 
ablkcipher_request *req,
req_info->outcnt = argcnt;
 }
 
-static inline int cvm_enc_dec(struct ablkcipher_request *req, u32 enc,
- u32 cipher_type)
+static inline int cvm_enc_dec(struct ablkcipher_request *req, u32 enc)
 {
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
-   struct cvm_enc_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-   u32 key_type = AES_128_BIT;
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
u32 enc_iv_len = crypto_ablkcipher_ivsize(tfm);
struct fc_context *fctx = >fctx;
@@ -210,36 +204,10 @@ static inline int cvm_enc_dec(struct ablkcipher_request 
*req, u32 enc,
void *cdev = NULL;
int status;
 
-   switch (ctx->key_len) {
-   case 16:
-   key_type = AES_128_BIT;
-   break;
-   case 24:
-   key_type = AES_192_BIT;
-   break;
-   case 32:
-   if (cipher_type == AES_XTS)
-   key_type = AES_128_BIT;
-   else
-   key_type = AES_256_BIT;
-   break;
-   case 64:
-   if (cipher_type == AES_XTS)
-   key_type = AES_256_BIT;
-   else
-   return -EINVAL;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   if (cipher_type == DES3_CBC)
-   key_type = 0;
-
memset(req_info, 0, sizeof(struct cpt_request_info));
memset(fctx, 0, sizeof(struct fc_context));
-   create_input_list(req, enc, cipher_type, key_type, enc_iv_len);
-   create_output_list(req, cipher_type, enc_iv_len);
+   create_input_list(req, enc, enc_iv_len);
+   create_output_list(req, enc_iv_len);
store_cb_info(req, req_info);
cdev = dev_handle.cdev[smp_processor_id()];
status = cptvf_do_request(cdev, req_info);
@@ -254,34 +222,41 @@ static inline int cvm_enc_dec(struct ablkcipher_request 
*req, u32 enc,
return -EINPROGRESS;
 }
 
-int cvm_des3_encrypt_cbc(struct 

[PATCH 2/3] crypto: cavium: Remove the individual encrypt/decrypt function for each algorithm

[George Cherian]

Remove the individual encrypt/decrypt function for easch algorithm.
This is in prepration of adding more crypto algorithms supported by
hardware. While at that simplify create_ctx_hdr/create_input_list
function interfaces.

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_algs.c | 133 +
 drivers/crypto/cavium/cpt/cptvf_algs.h |   7 ++
 2 files changed, 77 insertions(+), 63 deletions(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c 
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index cc853f9..c365fc6 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -98,7 +98,6 @@ static inline void update_output_data(struct cpt_request_info 
*req_info,
 }
 
 static inline u32 create_ctx_hdr(struct ablkcipher_request *req, u32 enc,
-u32 cipher_type, u32 aes_key_type,
 u32 *argcnt)
 {
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
@@ -124,11 +123,11 @@ static inline u32 create_ctx_hdr(struct 
ablkcipher_request *req, u32 enc,
req_info->req.param1 = req->nbytes; /* Encryption Data length */
req_info->req.param2 = 0; /*Auth data length */
 
-   fctx->enc.enc_ctrl.e.enc_cipher = cipher_type;
-   fctx->enc.enc_ctrl.e.aes_key = aes_key_type;
+   fctx->enc.enc_ctrl.e.enc_cipher = ctx->cipher_type;
+   fctx->enc.enc_ctrl.e.aes_key = ctx->key_type;
fctx->enc.enc_ctrl.e.iv_source = FROM_DPTR;
 
-   if (cipher_type == AES_XTS)
+   if (ctx->cipher_type == AES_XTS)
memcpy(fctx->enc.encr_key, ctx->enc_key, ctx->key_len * 2);
else
memcpy(fctx->enc.encr_key, ctx->enc_key, ctx->key_len);
@@ -154,14 +153,13 @@ static inline u32 create_ctx_hdr(struct 
ablkcipher_request *req, u32 enc,
 }
 
 static inline u32 create_input_list(struct ablkcipher_request  *req, u32 enc,
-   u32 cipher_type, u32 aes_key_type,
u32 enc_iv_len)
 {
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
struct cpt_request_info *req_info = >cpt_req;
u32 argcnt =  0;
 
-   create_ctx_hdr(req, enc, cipher_type, aes_key_type, );
+   create_ctx_hdr(req, enc, );
update_input_iv(req_info, req->info, enc_iv_len, );
update_input_data(req_info, req->src, req->nbytes, );
req_info->incnt = argcnt;
@@ -177,7 +175,6 @@ static inline void store_cb_info(struct ablkcipher_request 
*req,
 }
 
 static inline void create_output_list(struct ablkcipher_request *req,
- u32 cipher_type,
  u32 enc_iv_len)
 {
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
@@ -197,12 +194,9 @@ static inline void create_output_list(struct 
ablkcipher_request *req,
req_info->outcnt = argcnt;
 }
 
-static inline int cvm_enc_dec(struct ablkcipher_request *req, u32 enc,
- u32 cipher_type)
+static inline int cvm_enc_dec(struct ablkcipher_request *req, u32 enc)
 {
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
-   struct cvm_enc_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-   u32 key_type = AES_128_BIT;
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
u32 enc_iv_len = crypto_ablkcipher_ivsize(tfm);
struct fc_context *fctx = >fctx;
@@ -210,36 +204,10 @@ static inline int cvm_enc_dec(struct ablkcipher_request 
*req, u32 enc,
void *cdev = NULL;
int status;
 
-   switch (ctx->key_len) {
-   case 16:
-   key_type = AES_128_BIT;
-   break;
-   case 24:
-   key_type = AES_192_BIT;
-   break;
-   case 32:
-   if (cipher_type == AES_XTS)
-   key_type = AES_128_BIT;
-   else
-   key_type = AES_256_BIT;
-   break;
-   case 64:
-   if (cipher_type == AES_XTS)
-   key_type = AES_256_BIT;
-   else
-   return -EINVAL;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   if (cipher_type == DES3_CBC)
-   key_type = 0;
-
memset(req_info, 0, sizeof(struct cpt_request_info));
memset(fctx, 0, sizeof(struct fc_context));
-   create_input_list(req, enc, cipher_type, key_type, enc_iv_len);
-   create_output_list(req, cipher_type, enc_iv_len);
+   create_input_list(req, enc, enc_iv_len);
+   create_output_list(req, enc_iv_len);
store_cb_info(req, req_info);
cdev = dev_handle.cdev[smp_processor_id()];
status = cptvf_do_request(cdev, req_info);
@@ -254,34 +222,41 @@ static inline int cvm_enc_dec(struct ablkcipher_request 
*req, u32 enc,
return -EINPROGRESS;
 }
 
-int cvm_des3_encrypt_cbc(struct ablkcipher_request *req)
+int 

[PATCH 1/3] crypto: cavium: Downgrade the annoying misc interrupt print from dev_err to dev_dbg

[George Cherian]

Mailbox interrupt is common and it is not an error interrupt.
So downgrade the print from dev_err to  dev_dbg.

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c 
b/drivers/crypto/cavium/cpt/cptvf_main.c
index 6ffc740..5c796ed 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -525,7 +525,7 @@ static irqreturn_t cptvf_misc_intr_handler(int irq, void 
*cptvf_irq)
intr = cptvf_read_vf_misc_intr_status(cptvf);
/*Check for MISC interrupt types*/
if (likely(intr & CPT_VF_INTR_MBOX_MASK)) {
-   dev_err(>dev, "Mailbox interrupt 0x%llx on CPT VF %d\n",
+   dev_dbg(>dev, "Mailbox interrupt 0x%llx on CPT VF %d\n",
intr, cptvf->vfid);
cptvf_handle_mbox_intr(cptvf);
cptvf_clear_mbox_intr(cptvf);
-- 
2.1.4

[PATCH 1/3] crypto: cavium: Downgrade the annoying misc interrupt print from dev_err to dev_dbg

[George Cherian]

Mailbox interrupt is common and it is not an error interrupt.
So downgrade the print from dev_err to  dev_dbg.

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c 
b/drivers/crypto/cavium/cpt/cptvf_main.c
index 6ffc740..5c796ed 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -525,7 +525,7 @@ static irqreturn_t cptvf_misc_intr_handler(int irq, void 
*cptvf_irq)
intr = cptvf_read_vf_misc_intr_status(cptvf);
/*Check for MISC interrupt types*/
if (likely(intr & CPT_VF_INTR_MBOX_MASK)) {
-   dev_err(>dev, "Mailbox interrupt 0x%llx on CPT VF %d\n",
+   dev_dbg(>dev, "Mailbox interrupt 0x%llx on CPT VF %d\n",
intr, cptvf->vfid);
cptvf_handle_mbox_intr(cptvf);
cptvf_clear_mbox_intr(cptvf);
-- 
2.1.4

[PATCH 0/3] Add more algorithms and some misc cleanups

[George Cherian]

This series adds more algorithem support for CPT.
Add support for
-ecb(aes) 
-cfb(aes) 
-ecb(des3_ede)

Some cleanups too.

George Cherian (3):
  crypto: cavium: Downgrade the annoying misc interrupt print from
dev_err to dev_dbg
  crypto: cavium: Remove the individual encrypt/decrypt function for
each algorithm
  crypto: cavium: Add more algorithms

 drivers/crypto/cavium/cpt/cptvf_algs.c | 196 ++---
 drivers/crypto/cavium/cpt/cptvf_algs.h |   7 ++
 drivers/crypto/cavium/cpt/cptvf_main.c |   2 +-
 3 files changed, 141 insertions(+), 64 deletions(-)

-- 
2.1.4

[PATCH 0/3] Add more algorithms and some misc cleanups

[George Cherian]

This series adds more algorithem support for CPT.
Add support for
-ecb(aes) 
-cfb(aes) 
-ecb(des3_ede)

Some cleanups too.

George Cherian (3):
  crypto: cavium: Downgrade the annoying misc interrupt print from
dev_err to dev_dbg
  crypto: cavium: Remove the individual encrypt/decrypt function for
each algorithm
  crypto: cavium: Add more algorithms

 drivers/crypto/cavium/cpt/cptvf_algs.c | 196 ++---
 drivers/crypto/cavium/cpt/cptvf_algs.h |   7 ++
 drivers/crypto/cavium/cpt/cptvf_main.c |   2 +-
 3 files changed, 141 insertions(+), 64 deletions(-)

-- 
2.1.4

[PATCH 3/3] crypto: cavium: Add more algorithms

[George Cherian]

Add more algorithm support for the driver.
Add support for ecb(aes), cfb(aes) and ecb(des3_ede).

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_algs.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c 
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index c365fc6..b980d13 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -385,6 +385,48 @@ struct crypto_alg algs[] = { {
.cra_module = THIS_MODULE,
 }, {
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_enc_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "ecb(aes)",
+   .cra_driver_name = "cavium-ecb-aes",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .ivsize = AES_BLOCK_SIZE,
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_enc_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "cfb(aes)",
+   .cra_driver_name = "cavium-cfb-aes",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .ivsize = AES_BLOCK_SIZE,
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
.cra_blocksize = DES3_EDE_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct cvm_des3_ctx),
.cra_alignmask = 7,
@@ -404,6 +446,27 @@ struct crypto_alg algs[] = { {
},
.cra_init = cvm_enc_dec_init,
.cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_des3_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "ecb(des3_ede)",
+   .cra_driver_name = "cavium-ecb-des3_ede",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .min_keysize = DES3_EDE_KEY_SIZE,
+   .max_keysize = DES3_EDE_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
 } };
 
 static inline int cav_register_algs(void)
-- 
2.1.4

[PATCH 3/3] crypto: cavium: Add more algorithms

[George Cherian]

Add more algorithm support for the driver.
Add support for ecb(aes), cfb(aes) and ecb(des3_ede).

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_algs.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c 
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index c365fc6..b980d13 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -385,6 +385,48 @@ struct crypto_alg algs[] = { {
.cra_module = THIS_MODULE,
 }, {
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_enc_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "ecb(aes)",
+   .cra_driver_name = "cavium-ecb-aes",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .ivsize = AES_BLOCK_SIZE,
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_enc_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "cfb(aes)",
+   .cra_driver_name = "cavium-cfb-aes",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .ivsize = AES_BLOCK_SIZE,
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
.cra_blocksize = DES3_EDE_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct cvm_des3_ctx),
.cra_alignmask = 7,
@@ -404,6 +446,27 @@ struct crypto_alg algs[] = { {
},
.cra_init = cvm_enc_dec_init,
.cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_des3_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "ecb(des3_ede)",
+   .cra_driver_name = "cavium-ecb-des3_ede",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .min_keysize = DES3_EDE_KEY_SIZE,
+   .max_keysize = DES3_EDE_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
 } };
 
 static inline int cav_register_algs(void)
-- 
2.1.4

Re: [PATCH v3] scsi/bfa: use designated initializers

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [PATCH v3] scsi/bfa: use designated initializers

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig 

Re: [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries

[Viresh Kumar]

On 20-04-17, 22:14, Robert Jarzmik wrote:
> Viresh Kumar  writes:
> 
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski 
> > Reported-by: Masahiro Yamada 
> > Suggested-by: Mark Rutland 
> > Signed-off-by: Viresh Kumar 
> > Acked-by: Rob Herring 
> Acked-by: Robert Jarzmik 

Thanks. But I need you to pick it up for your pull request for arm-soc.

-- 
viresh

Re: [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries

[Viresh Kumar]

On 20-04-17, 22:14, Robert Jarzmik wrote:
> Viresh Kumar  writes:
> 
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski 
> > Reported-by: Masahiro Yamada 
> > Suggested-by: Mark Rutland 
> > Signed-off-by: Viresh Kumar 
> > Acked-by: Rob Herring 
> Acked-by: Robert Jarzmik 

Thanks. But I need you to pick it up for your pull request for arm-soc.

-- 
viresh

Re: [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries

[Viresh Kumar]

On 20-04-17, 18:09, Krzysztof Kozlowski wrote:
> On Thu, Apr 20, 2017 at 04:25:07PM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> > 
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> > unit name, but no reg property
> > 
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> > 
> > Reported-by: Krzysztof Kozlowski 
> > Reported-by: Masahiro Yamada 
> > Suggested-by: Mark Rutland 
> > Signed-off-by: Viresh Kumar 
> > Reviewed-by: Chanwoo Choi 
> > Reviewed-by: Krzysztof Kozlowski 
> > Acked-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
> >  arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
> >  arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
> >  arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
> >  arch/arm/boot/dts/exynos4412.dtsi  | 66 
> > +++---
> >  arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
> >  arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
> >  arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
> >  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
> >  9 files changed, 194 insertions(+), 194 deletions(-)
> 
> 
> Thanks, split ARM64 from ARM and applied (for v4.12). arm-soc keeps DTS
> separated between ARM architectures. Technically this should require a
> resend but we had way too many resends for this simple patch.

Bah! Will make sure to send separate patches from now on. Thanks.

-- 
viresh

Re: [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries

[Viresh Kumar]

On 20-04-17, 18:09, Krzysztof Kozlowski wrote:
> On Thu, Apr 20, 2017 at 04:25:07PM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> > 
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> > unit name, but no reg property
> > 
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> > 
> > Reported-by: Krzysztof Kozlowski 
> > Reported-by: Masahiro Yamada 
> > Suggested-by: Mark Rutland 
> > Signed-off-by: Viresh Kumar 
> > Reviewed-by: Chanwoo Choi 
> > Reviewed-by: Krzysztof Kozlowski 
> > Acked-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++
> >  arch/arm/boot/dts/exynos3250.dtsi  | 46 +++
> >  arch/arm/boot/dts/exynos4210.dtsi  | 32 +--
> >  arch/arm/boot/dts/exynos4412-prime.dtsi|  4 +-
> >  arch/arm/boot/dts/exynos4412.dtsi  | 66 
> > +++---
> >  arch/arm/boot/dts/exynos5420.dtsi  | 40 ++---
> >  arch/arm/boot/dts/exynos5800.dtsi  | 56 +-
> >  arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 
> >  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 
> >  9 files changed, 194 insertions(+), 194 deletions(-)
> 
> 
> Thanks, split ARM64 from ARM and applied (for v4.12). arm-soc keeps DTS
> separated between ARM architectures. Technically this should require a
> resend but we had way too many resends for this simple patch.

Bah! Will make sure to send separate patches from now on. Thanks.

-- 
viresh

Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt

[Giuseppe CAVALLARO]

On 4/18/2017 2:39 PM, Niklas Cassel wrote:

From: Niklas Cassel 

The hardware has a LPI interrupt.
There is already code in the stmmac driver to parse and handle the
interrupt. However, this information was missing from the DT binding.

At the same time, improve the description of the existing interrupts.

Signed-off-by: Niklas Cassel 
---
  Documentation/devicetree/bindings/net/stmmac.txt | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c384ce..c3a7be6615c5 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -7,9 +7,12 @@ Required properties:
  - interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
  - interrupts: Should contain the STMMAC interrupts
-- interrupt-names: Should contain the interrupt names "macirq"
-  "eth_wake_irq" if this interrupt is supported in the "interrupts"
-  property
+- interrupt-names: Should contain a list of interrupt names corresponding to
+   the interrupts in the interrupts property, if available.
+   Valid interrupt names are:
+  - "macirq" (combined signal for various interrupt events)
+  - "eth_wake_irq" (the interrupt to manage the remote wake-up packet 
detection)
+  - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
  - phy-mode: See ethernet.txt file in the same directory.
  - snps,reset-gpio gpio number for phy reset.
  - snps,reset-active-low boolean flag to indicate if phy reset is active low.
@@ -152,8 +155,8 @@ Examples:
compatible = "st,spear600-gmac";
reg = <0xe080 0x8000>;
interrupt-parent = <>;
-   interrupts = <24 23>;
-   interrupt-names = "macirq", "eth_wake_irq";
+   interrupts = <24 23 22>;
+   interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
mac-address = []; /* Filled in by U-Boot */
max-frame-size = <3800>;
phy-mode = "gmii";


Acked-by: Giuseppe Cavallaro 

Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt

[Giuseppe CAVALLARO]

On 4/18/2017 2:39 PM, Niklas Cassel wrote:

From: Niklas Cassel 

The hardware has a LPI interrupt.
There is already code in the stmmac driver to parse and handle the
interrupt. However, this information was missing from the DT binding.

At the same time, improve the description of the existing interrupts.

Signed-off-by: Niklas Cassel 
---
  Documentation/devicetree/bindings/net/stmmac.txt | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index f652b0c384ce..c3a7be6615c5 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -7,9 +7,12 @@ Required properties:
  - interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
  - interrupts: Should contain the STMMAC interrupts
-- interrupt-names: Should contain the interrupt names "macirq"
-  "eth_wake_irq" if this interrupt is supported in the "interrupts"
-  property
+- interrupt-names: Should contain a list of interrupt names corresponding to
+   the interrupts in the interrupts property, if available.
+   Valid interrupt names are:
+  - "macirq" (combined signal for various interrupt events)
+  - "eth_wake_irq" (the interrupt to manage the remote wake-up packet 
detection)
+  - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
  - phy-mode: See ethernet.txt file in the same directory.
  - snps,reset-gpio gpio number for phy reset.
  - snps,reset-active-low boolean flag to indicate if phy reset is active low.
@@ -152,8 +155,8 @@ Examples:
compatible = "st,spear600-gmac";
reg = <0xe080 0x8000>;
interrupt-parent = <>;
-   interrupts = <24 23>;
-   interrupt-names = "macirq", "eth_wake_irq";
+   interrupts = <24 23 22>;
+   interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
mac-address = []; /* Filled in by U-Boot */
max-frame-size = <3800>;
phy-mode = "gmii";


Acked-by: Giuseppe Cavallaro 

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

[Serge E. Hallyn]

On Fri, Apr 21, 2017 at 01:09:59AM -0400, Matt Brown wrote:
> On 04/20/2017 01:41 PM, Serge E. Hallyn wrote:
> >Quoting m...@nmatt.com (m...@nmatt.com):
> >>On 2017-04-20 11:19, Serge E. Hallyn wrote:
> >>>Quoting Matt Brown (m...@nmatt.com):
> On 04/19/2017 07:53 PM, Serge E. Hallyn wrote:
> >Quoting Matt Brown (m...@nmatt.com):
> >>On 04/19/2017 12:58 AM, Serge E. Hallyn wrote:
> >>>On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:
> This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the 
> grsecurity
> project in-kernel.
> 
> This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the 
> corresponding
> sysctl kernel.tiocsti_restrict that, when activated, restrict all 
> TIOCSTI
> ioctl calls from non CAP_SYS_ADMIN users.
> 
> Possible effects on userland:
> 
> There could be a few user programs that would be effected by this
> change.
> See: 
> notable programs are: agetty, csh, xemacs and tcsh
> 
> However, I still believe that this change is worth it given that the
> Kconfig defaults to n. This will be a feature that is turned on for 
> the
> >>>
> >>>It's not worthless, but note that for instance before this was fixed
> >>>in lxc, this patch would not have helped with escapes from privileged
> >>>containers.
> >>>
> >>
> >>I assume you are talking about this CVE:
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1411256
> >>
> >>In retrospect, is there any way that an escape from a privileged
> >>container with the this bug could have been prevented?
> >
> >I don't know, that's what I was probing for.  Detecting that the pgrp
> >or session - heck, the pid namespace - has changed would seem like a
> >good indicator that it shouldn't be able to push.
> >
> 
> pgrp and session won't do because in the case we are discussing
> current->signal->tty is the same as tty.
> 
> This is the current check that is already in place:
> | if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
> | return -EPERM;
> >>>
> >>>Yeah...
> >>>
> The only thing I could find to detect the tty message coming from a
> container is as follows:
> | task_active_pid_ns(current)->level
> 
> This will be zero when run on the host, but 1 when run inside a
> container. However this is very much a hack and could probably break
> some userland stuff where there are multiple levels of namespaces.
> >>>
> >>>Yes.  This is also however why I don't like the current patch, because
> >>>capable() will never be true in a container, so nested containers
> >>>break.
> >>>
> >>
> >>What do you mean by "capable() will never be true in a container"?
> >>My understanding
> >>is that if a container is given CAP_SYS_ADMIN then
> >>capable(CAP_SYS_ADMIN) will return
> >>true?
> >
> >No, capable(X) checks for X with respect to the initial user namespace.
> >So for root-owned containers it will be true, but containers running in
> >non-initial user namespaces cannot pass that check.
> >
> >To check for privilege with respect to another user namespace, you need
> >to use ns_capable.  But for that you need a user_ns to target.
> >
> 
> How about: ns_capable(current_user_ns(),CAP_SYS_ADMIN) ?
> 
> current_user_ns() was found in include/linux/cred.h

Any user can create a new user namespace and pass the above check.  What we
want is to find the user namespace which opened the tty.

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

[Serge E. Hallyn]

On Fri, Apr 21, 2017 at 01:09:59AM -0400, Matt Brown wrote:
> On 04/20/2017 01:41 PM, Serge E. Hallyn wrote:
> >Quoting m...@nmatt.com (m...@nmatt.com):
> >>On 2017-04-20 11:19, Serge E. Hallyn wrote:
> >>>Quoting Matt Brown (m...@nmatt.com):
> On 04/19/2017 07:53 PM, Serge E. Hallyn wrote:
> >Quoting Matt Brown (m...@nmatt.com):
> >>On 04/19/2017 12:58 AM, Serge E. Hallyn wrote:
> >>>On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:
> This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the 
> grsecurity
> project in-kernel.
> 
> This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the 
> corresponding
> sysctl kernel.tiocsti_restrict that, when activated, restrict all 
> TIOCSTI
> ioctl calls from non CAP_SYS_ADMIN users.
> 
> Possible effects on userland:
> 
> There could be a few user programs that would be effected by this
> change.
> See: 
> notable programs are: agetty, csh, xemacs and tcsh
> 
> However, I still believe that this change is worth it given that the
> Kconfig defaults to n. This will be a feature that is turned on for 
> the
> >>>
> >>>It's not worthless, but note that for instance before this was fixed
> >>>in lxc, this patch would not have helped with escapes from privileged
> >>>containers.
> >>>
> >>
> >>I assume you are talking about this CVE:
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1411256
> >>
> >>In retrospect, is there any way that an escape from a privileged
> >>container with the this bug could have been prevented?
> >
> >I don't know, that's what I was probing for.  Detecting that the pgrp
> >or session - heck, the pid namespace - has changed would seem like a
> >good indicator that it shouldn't be able to push.
> >
> 
> pgrp and session won't do because in the case we are discussing
> current->signal->tty is the same as tty.
> 
> This is the current check that is already in place:
> | if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
> | return -EPERM;
> >>>
> >>>Yeah...
> >>>
> The only thing I could find to detect the tty message coming from a
> container is as follows:
> | task_active_pid_ns(current)->level
> 
> This will be zero when run on the host, but 1 when run inside a
> container. However this is very much a hack and could probably break
> some userland stuff where there are multiple levels of namespaces.
> >>>
> >>>Yes.  This is also however why I don't like the current patch, because
> >>>capable() will never be true in a container, so nested containers
> >>>break.
> >>>
> >>
> >>What do you mean by "capable() will never be true in a container"?
> >>My understanding
> >>is that if a container is given CAP_SYS_ADMIN then
> >>capable(CAP_SYS_ADMIN) will return
> >>true?
> >
> >No, capable(X) checks for X with respect to the initial user namespace.
> >So for root-owned containers it will be true, but containers running in
> >non-initial user namespaces cannot pass that check.
> >
> >To check for privilege with respect to another user namespace, you need
> >to use ns_capable.  But for that you need a user_ns to target.
> >
> 
> How about: ns_capable(current_user_ns(),CAP_SYS_ADMIN) ?
> 
> current_user_ns() was found in include/linux/cred.h

Any user can create a new user namespace and pass the above check.  What we
want is to find the user namespace which opened the tty.

Re: [PATCH] Added paranthesis around complex define statements

[Greg KH]

On Fri, Apr 21, 2017 at 05:15:46AM +, Andriy Gelman wrote:
> This is a patch to the ks_wlan_ioctl.h file that fixes paranthesis error
> found by the checkpatch.pl tool

No, it also does other things :(

Also, please fix up the subject to look like other patches done for this
file/driver.

And fix the spelling mistake :)

> 
> Signed-off-by: Andriy Gelman 
> ---
>  drivers/staging/ks7010/ks_wlan_ioctl.h | 53 
> +-
>  1 file changed, 26 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
> b/drivers/staging/ks7010/ks_wlan_ioctl.h
> index 8e62b10..851f563 100644
> --- a/drivers/staging/ks7010/ks_wlan_ioctl.h
> +++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
> @@ -1,6 +1,6 @@
>  /*
>   *   Driver for KeyStream 11b/g wireless LAN
> - *   
> + *

This is not a () change :(

Please only do one type of thing in each patch.

thanks,

greg k-h

Re: [PATCH] Added paranthesis around complex define statements

[Greg KH]

On Fri, Apr 21, 2017 at 05:15:46AM +, Andriy Gelman wrote:
> This is a patch to the ks_wlan_ioctl.h file that fixes paranthesis error
> found by the checkpatch.pl tool

No, it also does other things :(

Also, please fix up the subject to look like other patches done for this
file/driver.

And fix the spelling mistake :)

> 
> Signed-off-by: Andriy Gelman 
> ---
>  drivers/staging/ks7010/ks_wlan_ioctl.h | 53 
> +-
>  1 file changed, 26 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
> b/drivers/staging/ks7010/ks_wlan_ioctl.h
> index 8e62b10..851f563 100644
> --- a/drivers/staging/ks7010/ks_wlan_ioctl.h
> +++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
> @@ -1,6 +1,6 @@
>  /*
>   *   Driver for KeyStream 11b/g wireless LAN
> - *   
> + *

This is not a () change :(

Please only do one type of thing in each patch.

thanks,

greg k-h

[PATCH] Added paranthesis around complex define statements

[Andriy Gelman]

This is a patch to the ks_wlan_ioctl.h file that fixes paranthesis error
found by the checkpatch.pl tool

Signed-off-by: Andriy Gelman 
---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 53 +-
 1 file changed, 26 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 8e62b10..851f563 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream 11b/g wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -18,38 +18,38 @@
 /* SIOCIWFIRSTPRIV + 0 */
 /* former KS_WLAN_GET_DRIVER_VERSION   SIOCIWFIRSTPRIV + 1 */
 /* SIOCIWFIRSTPRIV + 2 */
-#define KS_WLAN_GET_FIRM_VERSION   SIOCIWFIRSTPRIV + 3
+#define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
-#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5
-#define KS_WLAN_SET_WPS_PROBE_REQ  SIOCIWFIRSTPRIV + 6
+#define KS_WLAN_SET_WPS_ENABLE  (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE  (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
-#define KS_WLAN_GET_EEPROM_CKSUM   SIOCIWFIRSTPRIV + 7
-#define KS_WLAN_SET_PREAMBLE   SIOCIWFIRSTPRIV + 8
-#define KS_WLAN_GET_PREAMBLE   SIOCIWFIRSTPRIV + 9
-#define KS_WLAN_SET_POWER_SAVE SIOCIWFIRSTPRIV + 10
-#define KS_WLAN_GET_POWER_SAVE SIOCIWFIRSTPRIV + 11
-#define KS_WLAN_SET_SCAN_TYPE  SIOCIWFIRSTPRIV + 12
-#define KS_WLAN_GET_SCAN_TYPE  SIOCIWFIRSTPRIV + 13
-#define KS_WLAN_SET_RX_GAINSIOCIWFIRSTPRIV + 14
-#define KS_WLAN_GET_RX_GAINSIOCIWFIRSTPRIV + 15
-#define KS_WLAN_HOSTT  SIOCIWFIRSTPRIV + 16/* unused */
+#define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
+#define KS_WLAN_SET_PREAMBLE   (SIOCIWFIRSTPRIV + 8)
+#define KS_WLAN_GET_PREAMBLE   (SIOCIWFIRSTPRIV + 9)
+#define KS_WLAN_SET_POWER_SAVE (SIOCIWFIRSTPRIV + 10)
+#define KS_WLAN_GET_POWER_SAVE (SIOCIWFIRSTPRIV + 11)
+#define KS_WLAN_SET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 12)
+#define KS_WLAN_GET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 13)
+#define KS_WLAN_SET_RX_GAIN(SIOCIWFIRSTPRIV + 14)
+#define KS_WLAN_GET_RX_GAIN(SIOCIWFIRSTPRIV + 15)
+#define KS_WLAN_HOSTT   (SIOCIWFIRSTPRIV + 16) /* unused */
 //#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV + 17
-#define KS_WLAN_SET_BEACON_LOSTSIOCIWFIRSTPRIV + 18
-#define KS_WLAN_GET_BEACON_LOSTSIOCIWFIRSTPRIV + 19
+#define KS_WLAN_SET_BEACON_LOST(SIOCIWFIRSTPRIV + 18)
+#define KS_WLAN_GET_BEACON_LOST(SIOCIWFIRSTPRIV + 19)
 
-#define KS_WLAN_SET_TX_GAINSIOCIWFIRSTPRIV + 20
-#define KS_WLAN_GET_TX_GAINSIOCIWFIRSTPRIV + 21
+#define KS_WLAN_SET_TX_GAIN(SIOCIWFIRSTPRIV + 20)
+#define KS_WLAN_GET_TX_GAIN(SIOCIWFIRSTPRIV + 21)
 
 /* for KS7010 */
-#define KS_WLAN_SET_PHY_TYPE   SIOCIWFIRSTPRIV + 22
-#define KS_WLAN_GET_PHY_TYPE   SIOCIWFIRSTPRIV + 23
-#define KS_WLAN_SET_CTS_MODE   SIOCIWFIRSTPRIV + 24
-#define KS_WLAN_GET_CTS_MODE   SIOCIWFIRSTPRIV + 25
+#define KS_WLAN_SET_PHY_TYPE   (SIOCIWFIRSTPRIV + 22)
+#define KS_WLAN_GET_PHY_TYPE   (SIOCIWFIRSTPRIV + 23)
+#define KS_WLAN_SET_CTS_MODE   (SIOCIWFIRSTPRIV + 24)
+#define KS_WLAN_GET_CTS_MODE   (SIOCIWFIRSTPRIV + 25)
 /* SIOCIWFIRSTPRIV + 26 */
 /* SIOCIWFIRSTPRIV + 27 */
-#define KS_WLAN_SET_SLEEP_MODE SIOCIWFIRSTPRIV + 28/* sleep mode */
-#define KS_WLAN_GET_SLEEP_MODE SIOCIWFIRSTPRIV + 29/* sleep mode */
+#define KS_WLAN_SET_SLEEP_MODE (SIOCIWFIRSTPRIV + 28)  /* sleep mode */
+#define KS_WLAN_GET_SLEEP_MODE (SIOCIWFIRSTPRIV + 29)  /* sleep mode */
 /* SIOCIWFIRSTPRIV + 30 */
 /* SIOCIWFIRSTPRIV + 31 */
 
@@ -59,8 +59,7 @@
 #include 
 
 int ks_wlan_read_config_file(struct ks_wlan_private *priv);
-int ks_wlan_setup_parameter(struct ks_wlan_private *priv,
-unsigned int commit_flag);
+int ks_wlan_setup_parameter(struct ks_wlan_private *priv, int commit_flag);
 
 #endif /* __KERNEL__ */
 
-- 
2.7.4

[PATCH] Added paranthesis around complex define statements

[Andriy Gelman]

This is a patch to the ks_wlan_ioctl.h file that fixes paranthesis error
found by the checkpatch.pl tool

Signed-off-by: Andriy Gelman 
---
 drivers/staging/ks7010/ks_wlan_ioctl.h | 53 +-
 1 file changed, 26 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_ioctl.h 
b/drivers/staging/ks7010/ks_wlan_ioctl.h
index 8e62b10..851f563 100644
--- a/drivers/staging/ks7010/ks_wlan_ioctl.h
+++ b/drivers/staging/ks7010/ks_wlan_ioctl.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream 11b/g wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -18,38 +18,38 @@
 /* SIOCIWFIRSTPRIV + 0 */
 /* former KS_WLAN_GET_DRIVER_VERSION   SIOCIWFIRSTPRIV + 1 */
 /* SIOCIWFIRSTPRIV + 2 */
-#define KS_WLAN_GET_FIRM_VERSION   SIOCIWFIRSTPRIV + 3
+#define KS_WLAN_GET_FIRM_VERSION   (SIOCIWFIRSTPRIV + 3)
 #ifdef WPS
-#define KS_WLAN_SET_WPS_ENABLE SIOCIWFIRSTPRIV + 4
-#define KS_WLAN_GET_WPS_ENABLE SIOCIWFIRSTPRIV + 5
-#define KS_WLAN_SET_WPS_PROBE_REQ  SIOCIWFIRSTPRIV + 6
+#define KS_WLAN_SET_WPS_ENABLE  (SIOCIWFIRSTPRIV + 4)
+#define KS_WLAN_GET_WPS_ENABLE  (SIOCIWFIRSTPRIV + 5)
+#define KS_WLAN_SET_WPS_PROBE_REQ  (SIOCIWFIRSTPRIV + 6)
 #endif
-#define KS_WLAN_GET_EEPROM_CKSUM   SIOCIWFIRSTPRIV + 7
-#define KS_WLAN_SET_PREAMBLE   SIOCIWFIRSTPRIV + 8
-#define KS_WLAN_GET_PREAMBLE   SIOCIWFIRSTPRIV + 9
-#define KS_WLAN_SET_POWER_SAVE SIOCIWFIRSTPRIV + 10
-#define KS_WLAN_GET_POWER_SAVE SIOCIWFIRSTPRIV + 11
-#define KS_WLAN_SET_SCAN_TYPE  SIOCIWFIRSTPRIV + 12
-#define KS_WLAN_GET_SCAN_TYPE  SIOCIWFIRSTPRIV + 13
-#define KS_WLAN_SET_RX_GAINSIOCIWFIRSTPRIV + 14
-#define KS_WLAN_GET_RX_GAINSIOCIWFIRSTPRIV + 15
-#define KS_WLAN_HOSTT  SIOCIWFIRSTPRIV + 16/* unused */
+#define KS_WLAN_GET_EEPROM_CKSUM   (SIOCIWFIRSTPRIV + 7)
+#define KS_WLAN_SET_PREAMBLE   (SIOCIWFIRSTPRIV + 8)
+#define KS_WLAN_GET_PREAMBLE   (SIOCIWFIRSTPRIV + 9)
+#define KS_WLAN_SET_POWER_SAVE (SIOCIWFIRSTPRIV + 10)
+#define KS_WLAN_GET_POWER_SAVE (SIOCIWFIRSTPRIV + 11)
+#define KS_WLAN_SET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 12)
+#define KS_WLAN_GET_SCAN_TYPE  (SIOCIWFIRSTPRIV + 13)
+#define KS_WLAN_SET_RX_GAIN(SIOCIWFIRSTPRIV + 14)
+#define KS_WLAN_GET_RX_GAIN(SIOCIWFIRSTPRIV + 15)
+#define KS_WLAN_HOSTT   (SIOCIWFIRSTPRIV + 16) /* unused */
 //#define KS_WLAN_SET_REGIONSIOCIWFIRSTPRIV + 17
-#define KS_WLAN_SET_BEACON_LOSTSIOCIWFIRSTPRIV + 18
-#define KS_WLAN_GET_BEACON_LOSTSIOCIWFIRSTPRIV + 19
+#define KS_WLAN_SET_BEACON_LOST(SIOCIWFIRSTPRIV + 18)
+#define KS_WLAN_GET_BEACON_LOST(SIOCIWFIRSTPRIV + 19)
 
-#define KS_WLAN_SET_TX_GAINSIOCIWFIRSTPRIV + 20
-#define KS_WLAN_GET_TX_GAINSIOCIWFIRSTPRIV + 21
+#define KS_WLAN_SET_TX_GAIN(SIOCIWFIRSTPRIV + 20)
+#define KS_WLAN_GET_TX_GAIN(SIOCIWFIRSTPRIV + 21)
 
 /* for KS7010 */
-#define KS_WLAN_SET_PHY_TYPE   SIOCIWFIRSTPRIV + 22
-#define KS_WLAN_GET_PHY_TYPE   SIOCIWFIRSTPRIV + 23
-#define KS_WLAN_SET_CTS_MODE   SIOCIWFIRSTPRIV + 24
-#define KS_WLAN_GET_CTS_MODE   SIOCIWFIRSTPRIV + 25
+#define KS_WLAN_SET_PHY_TYPE   (SIOCIWFIRSTPRIV + 22)
+#define KS_WLAN_GET_PHY_TYPE   (SIOCIWFIRSTPRIV + 23)
+#define KS_WLAN_SET_CTS_MODE   (SIOCIWFIRSTPRIV + 24)
+#define KS_WLAN_GET_CTS_MODE   (SIOCIWFIRSTPRIV + 25)
 /* SIOCIWFIRSTPRIV + 26 */
 /* SIOCIWFIRSTPRIV + 27 */
-#define KS_WLAN_SET_SLEEP_MODE SIOCIWFIRSTPRIV + 28/* sleep mode */
-#define KS_WLAN_GET_SLEEP_MODE SIOCIWFIRSTPRIV + 29/* sleep mode */
+#define KS_WLAN_SET_SLEEP_MODE (SIOCIWFIRSTPRIV + 28)  /* sleep mode */
+#define KS_WLAN_GET_SLEEP_MODE (SIOCIWFIRSTPRIV + 29)  /* sleep mode */
 /* SIOCIWFIRSTPRIV + 30 */
 /* SIOCIWFIRSTPRIV + 31 */
 
@@ -59,8 +59,7 @@
 #include 
 
 int ks_wlan_read_config_file(struct ks_wlan_private *priv);
-int ks_wlan_setup_parameter(struct ks_wlan_private *priv,
-unsigned int commit_flag);
+int ks_wlan_setup_parameter(struct ks_wlan_private *priv, int commit_flag);
 
 #endif /* __KERNEL__ */
 
-- 
2.7.4

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

On 04/20/2017 01:41 PM, Serge E. Hallyn wrote:

Quoting m...@nmatt.com (m...@nmatt.com):

On 2017-04-20 11:19, Serge E. Hallyn wrote:

Quoting Matt Brown (m...@nmatt.com):

On 04/19/2017 07:53 PM, Serge E. Hallyn wrote:

Quoting Matt Brown (m...@nmatt.com):

On 04/19/2017 12:58 AM, Serge E. Hallyn wrote:

On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:

This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity
project in-kernel.

This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding
sysctl kernel.tiocsti_restrict that, when activated, restrict all TIOCSTI
ioctl calls from non CAP_SYS_ADMIN users.

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the


It's not worthless, but note that for instance before this was fixed
in lxc, this patch would not have helped with escapes from privileged
containers.



I assume you are talking about this CVE:
https://bugzilla.redhat.com/show_bug.cgi?id=1411256

In retrospect, is there any way that an escape from a privileged
container with the this bug could have been prevented?


I don't know, that's what I was probing for.  Detecting that the pgrp
or session - heck, the pid namespace - has changed would seem like a
good indicator that it shouldn't be able to push.



pgrp and session won't do because in the case we are discussing
current->signal->tty is the same as tty.

This is the current check that is already in place:
| if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
|   return -EPERM;


Yeah...


The only thing I could find to detect the tty message coming from a
container is as follows:
| task_active_pid_ns(current)->level

This will be zero when run on the host, but 1 when run inside a
container. However this is very much a hack and could probably break
some userland stuff where there are multiple levels of namespaces.


Yes.  This is also however why I don't like the current patch, because
capable() will never be true in a container, so nested containers
break.



What do you mean by "capable() will never be true in a container"?
My understanding
is that if a container is given CAP_SYS_ADMIN then
capable(CAP_SYS_ADMIN) will return
true?


No, capable(X) checks for X with respect to the initial user namespace.
So for root-owned containers it will be true, but containers running in
non-initial user namespaces cannot pass that check.

To check for privilege with respect to another user namespace, you need
to use ns_capable.  But for that you need a user_ns to target.



How about: ns_capable(current_user_ns(),CAP_SYS_ADMIN) ?

current_user_ns() was found in include/linux/cred.h


 I agree the hack I mentioned above would be a bad idea because
it would break
nested containers, but the current patch would not IMO.

A better version of the hack could involve a config
CONFIG_TIOCSTI_MAX_NS_LEVEL where
a check would be performed to ensure that
task_active_pid_ns(current)->level is not
greater than the config value(an integer that is >= 0) .


Yeah.  That would break a different set of cases than the capable
check, I assume.  A smaller set, I think.


Again, I think we both would agree that this is not the best
solution. The clear
downside is that you could have multiple container layers where the
desired security
boundaries happened to fall at different levels. Just throwing ideas
around.


Yup, appreciated.

Re: [PATCH] make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

On 04/20/2017 01:41 PM, Serge E. Hallyn wrote:

Quoting m...@nmatt.com (m...@nmatt.com):

On 2017-04-20 11:19, Serge E. Hallyn wrote:

Quoting Matt Brown (m...@nmatt.com):

On 04/19/2017 07:53 PM, Serge E. Hallyn wrote:

Quoting Matt Brown (m...@nmatt.com):

On 04/19/2017 12:58 AM, Serge E. Hallyn wrote:

On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:

This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity
project in-kernel.

This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding
sysctl kernel.tiocsti_restrict that, when activated, restrict all TIOCSTI
ioctl calls from non CAP_SYS_ADMIN users.

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the


It's not worthless, but note that for instance before this was fixed
in lxc, this patch would not have helped with escapes from privileged
containers.



I assume you are talking about this CVE:
https://bugzilla.redhat.com/show_bug.cgi?id=1411256

In retrospect, is there any way that an escape from a privileged
container with the this bug could have been prevented?


I don't know, that's what I was probing for.  Detecting that the pgrp
or session - heck, the pid namespace - has changed would seem like a
good indicator that it shouldn't be able to push.



pgrp and session won't do because in the case we are discussing
current->signal->tty is the same as tty.

This is the current check that is already in place:
| if ((current->signal->tty != tty) && !capable(CAP_SYS_ADMIN))
|   return -EPERM;


Yeah...


The only thing I could find to detect the tty message coming from a
container is as follows:
| task_active_pid_ns(current)->level

This will be zero when run on the host, but 1 when run inside a
container. However this is very much a hack and could probably break
some userland stuff where there are multiple levels of namespaces.


Yes.  This is also however why I don't like the current patch, because
capable() will never be true in a container, so nested containers
break.



What do you mean by "capable() will never be true in a container"?
My understanding
is that if a container is given CAP_SYS_ADMIN then
capable(CAP_SYS_ADMIN) will return
true?


No, capable(X) checks for X with respect to the initial user namespace.
So for root-owned containers it will be true, but containers running in
non-initial user namespaces cannot pass that check.

To check for privilege with respect to another user namespace, you need
to use ns_capable.  But for that you need a user_ns to target.



How about: ns_capable(current_user_ns(),CAP_SYS_ADMIN) ?

current_user_ns() was found in include/linux/cred.h


 I agree the hack I mentioned above would be a bad idea because
it would break
nested containers, but the current patch would not IMO.

A better version of the hack could involve a config
CONFIG_TIOCSTI_MAX_NS_LEVEL where
a check would be performed to ensure that
task_active_pid_ns(current)->level is not
greater than the config value(an integer that is >= 0) .


Yeah.  That would break a different set of cases than the capable
check, I assume.  A smaller set, I think.


Again, I think we both would agree that this is not the best
solution. The clear
downside is that you could have multiple container layers where the
desired security
boundaries happened to fall at different levels. Just throwing ideas
around.


Yup, appreciated.

[PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number

[Yinghai Lu]

On one system found strange "no compatible bridge window" warning
even we already had pref_compat support that add extra pref bit for device
resource.

PCI: Claiming :00:01.0: Resource 14: 00020001..000200010fff 
[10220c]
PCI: Claiming :01:00.0: Resource 1: 00020001..00020001 
[100214]
pci :01:00.0: can't claim BAR 1 [mem 0x20001-0x20001 
64bit]: no compatible bridge window

It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not have mmio resource.

We already fix pci_up_path_over_pref_mem64() to check all bus resources.

And at the same time, this patch make resource to have consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index adb9653..887441e 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -481,7 +481,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
pci_read_bridge_bases(bus);
goto after_ranges;
}
-   i = 1;
+   i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
u64 start;
 
@@ -513,6 +513,12 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
   " for bridge %s\n", node->full_name);
continue;
}
+   } else if ((flags & IORESOURCE_PREFETCH) &&
+  !bus->resource[2]->flags) {
+   res = bus->resource[2];
+   } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+   IORESOURCE_MEM) && !bus->resource[1]->flags) {
+   res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.9.3

[PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number

[Yinghai Lu]

On one system found strange "no compatible bridge window" warning
even we already had pref_compat support that add extra pref bit for device
resource.

PCI: Claiming :00:01.0: Resource 14: 00020001..000200010fff 
[10220c]
PCI: Claiming :01:00.0: Resource 1: 00020001..00020001 
[100214]
pci :01:00.0: can't claim BAR 1 [mem 0x20001-0x20001 
64bit]: no compatible bridge window

It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not have mmio resource.

We already fix pci_up_path_over_pref_mem64() to check all bus resources.

And at the same time, this patch make resource to have consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index adb9653..887441e 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -481,7 +481,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
pci_read_bridge_bases(bus);
goto after_ranges;
}
-   i = 1;
+   i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
u64 start;
 
@@ -513,6 +513,12 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
   " for bridge %s\n", node->full_name);
continue;
}
+   } else if ((flags & IORESOURCE_PREFETCH) &&
+  !bus->resource[2]->flags) {
+   res = bus->resource[2];
+   } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+   IORESOURCE_MEM) && !bus->resource[1]->flags) {
+   res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.9.3

[PATCH 00/13] PCI: sparc related 64bit resource fixup

[Yinghai Lu]

Hi Bjorn,

Please check sparc related 64bit resource handling patches.

patch 1-8: parse MEM64 for sparc and other system with OF.
So device 64bit resource could find their parent resource.

patch 9-12: MMIO64 handling enhancement
treat non-pref mmio64 as pref mmio64 if all bridges to root all pcie.

patch 13: restore old pref allocation logic if hostbridge does not support 
mmio64.

Those patches could be applied on top of today's pci/next.

Thanks

Yinghai


Yinghai Lu (13):
  sparc/PCI: Use correct offset for bus address to resource
  PCI: Add pci_find_bus_resource()
  sparc/PCI: Reserve legacy mmio after PCI mmio
  sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
  sparc/PCI: Keep resource idx order with bridge register number
  powerpc/PCI: Keep resource idx order with bridge register number
  powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
  OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
  PCI: Check pref compatible bit for mem64 resource of PCIe device
  PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64
  PCI: Add has_mem64 for struct host_bridge
  PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64
  PCI: Restore pref MMIO allocation logic for host bridge without mmio64

 arch/powerpc/kernel/pci_of_scan.c | 12 +-
 arch/sparc/kernel/of_device_32.c  |  5 ++-
 arch/sparc/kernel/of_device_64.c  |  5 ++-
 arch/sparc/kernel/pci.c   | 15 +--
 arch/sparc/kernel/pci_common.c| 91 +++
 arch/sparc/kernel/pci_impl.h  |  5 +++
 drivers/of/address.c  |  4 +-
 drivers/pci/bus.c |  4 +-
 drivers/pci/pci.c | 31 +++--
 drivers/pci/pci.h |  2 +
 drivers/pci/probe.c   | 40 +
 drivers/pci/setup-bus.c   | 65 
 drivers/pci/setup-res.c   | 13 --
 include/linux/pci.h   |  4 ++
 14 files changed, 224 insertions(+), 72 deletions(-)

-- 
2.9.3

[PATCH 00/13] PCI: sparc related 64bit resource fixup

[Yinghai Lu]

Hi Bjorn,

Please check sparc related 64bit resource handling patches.

patch 1-8: parse MEM64 for sparc and other system with OF.
So device 64bit resource could find their parent resource.

patch 9-12: MMIO64 handling enhancement
treat non-pref mmio64 as pref mmio64 if all bridges to root all pcie.

patch 13: restore old pref allocation logic if hostbridge does not support 
mmio64.

Those patches could be applied on top of today's pci/next.

Thanks

Yinghai


Yinghai Lu (13):
  sparc/PCI: Use correct offset for bus address to resource
  PCI: Add pci_find_bus_resource()
  sparc/PCI: Reserve legacy mmio after PCI mmio
  sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
  sparc/PCI: Keep resource idx order with bridge register number
  powerpc/PCI: Keep resource idx order with bridge register number
  powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
  OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
  PCI: Check pref compatible bit for mem64 resource of PCIe device
  PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64
  PCI: Add has_mem64 for struct host_bridge
  PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64
  PCI: Restore pref MMIO allocation logic for host bridge without mmio64

 arch/powerpc/kernel/pci_of_scan.c | 12 +-
 arch/sparc/kernel/of_device_32.c  |  5 ++-
 arch/sparc/kernel/of_device_64.c  |  5 ++-
 arch/sparc/kernel/pci.c   | 15 +--
 arch/sparc/kernel/pci_common.c| 91 +++
 arch/sparc/kernel/pci_impl.h  |  5 +++
 drivers/of/address.c  |  4 +-
 drivers/pci/bus.c |  4 +-
 drivers/pci/pci.c | 31 +++--
 drivers/pci/pci.h |  2 +
 drivers/pci/probe.c   | 40 +
 drivers/pci/setup-bus.c   | 65 
 drivers/pci/setup-res.c   | 13 --
 include/linux/pci.h   |  4 ++
 14 files changed, 224 insertions(+), 72 deletions(-)

-- 
2.9.3

[PATCH 07/13] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

[Yinghai Lu]

For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

This patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Gavin Shan 
Cc: Yijing Wang 
Cc: Anton Blanchard 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 9581e00..24714d4 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
 
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
-   flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+   if (addr0 & 0x0100)
+   flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
 | PCI_BASE_ADDRESS_MEM_PREFETCH;
-- 
2.9.3

[PATCH 07/13] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

[Yinghai Lu]

For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

This patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Gavin Shan 
Cc: Yijing Wang 
Cc: Anton Blanchard 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 9581e00..24714d4 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
 
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
-   flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+   if (addr0 & 0x0100)
+   flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
 | PCI_BASE_ADDRESS_MEM_PREFETCH;
-- 
2.9.3

[PATCH 01/13] sparc/PCI: Use correct offset for bus address to resource

[Yinghai Lu]

After we added 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.

It turns out that we can not use mem_space.start as 64bit mem space
offset, aka there is mem_space.start != offset.

Use child_phys_addr to calculate exact offset and record offset in
pbm.

After patch we get correct offset.

/pci@305: PCI IO [io  0x2007e-0x2007e0fff] offset 2007e
/pci@305: PCI MEM [mem 0x20010-0x27eff] offset 2
/pci@305: PCI MEM64 [mem 0x20001-0x2000d] offset 2
...
pci_sun4v f02ae7f8: PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x2007e-0x2007e0fff] (bus 
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x20010-0x27eff] (bus 
address [0x0010-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x2000d] (bus 
address [0x1-0xd])

-v3: put back mem64_offset, as we found T4 has mem_offset != mem64_offset
 check overlapping between mem64_space and mem_space.
-v7: after new pci_mmap_page_range patches.
-v8: remove change in pci_resource_to_user()

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci.c|  6 +++---
 arch/sparc/kernel/pci_common.c | 32 
 arch/sparc/kernel/pci_impl.h   |  4 
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 7eceaa1..c5cf813 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -663,12 +663,12 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
printk("PCI: Scanning PBM %s\n", node->full_name);
 
pci_add_resource_offset(, >io_space,
-   pbm->io_space.start);
+   pbm->io_offset);
pci_add_resource_offset(, >mem_space,
-   pbm->mem_space.start);
+   pbm->mem_offset);
if (pbm->mem64_space.flags)
pci_add_resource_offset(, >mem64_space,
-   pbm->mem_space.start);
+   pbm->mem64_offset);
pbm->busn.start = pbm->pci_first_busno;
pbm->busn.end   = pbm->pci_last_busno;
pbm->busn.flags = IORESOURCE_BUS;
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 33524c1..76998f8 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -410,13 +410,16 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
 
for (i = 0; i < num_pbm_ranges; i++) {
const struct linux_prom_pci_ranges *pr = _ranges[i];
-   unsigned long a, size;
+   unsigned long a, size, region_a;
u32 parent_phys_hi, parent_phys_lo;
+   u32 child_phys_mid, child_phys_lo;
u32 size_hi, size_lo;
int type;
 
parent_phys_hi = pr->parent_phys_hi;
parent_phys_lo = pr->parent_phys_lo;
+   child_phys_mid = pr->child_phys_mid;
+   child_phys_lo = pr->child_phys_lo;
if (tlb_type == hypervisor)
parent_phys_hi &= 0x0fff;
 
@@ -426,6 +429,8 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
type = (pr->child_phys_hi >> 24) & 0x3;
a = (((unsigned long)parent_phys_hi << 32UL) |
 ((unsigned long)parent_phys_lo  <<  0UL));
+   region_a = (((unsigned long)child_phys_mid << 32UL) |
+((unsigned long)child_phys_lo  <<  0UL));
size = (((unsigned long)size_hi << 32UL) |
((unsigned long)size_lo  <<  0UL));
 
@@ -440,6 +445,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->io_space.start = a;
pbm->io_space.end = a + size - 1UL;
pbm->io_space.flags = IORESOURCE_IO;
+   pbm->io_offset = a - region_a;
saw_io = 1;
break;
 
@@ -448,6 +454,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->mem_space.start = a;
pbm->mem_space.end = a + size - 1UL;
pbm->mem_space.flags = IORESOURCE_MEM;
+   pbm->mem_offset = a - region_a;
saw_mem = 1;
break;
 
@@ -456,6 +463,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->mem64_space.start = a;
pbm->mem64_space.end = a + size - 1UL;
pbm->mem64_space.flags = IORESOURCE_MEM;
+   

[PATCH 01/13] sparc/PCI: Use correct offset for bus address to resource

[Yinghai Lu]

After we added 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.

It turns out that we can not use mem_space.start as 64bit mem space
offset, aka there is mem_space.start != offset.

Use child_phys_addr to calculate exact offset and record offset in
pbm.

After patch we get correct offset.

/pci@305: PCI IO [io  0x2007e-0x2007e0fff] offset 2007e
/pci@305: PCI MEM [mem 0x20010-0x27eff] offset 2
/pci@305: PCI MEM64 [mem 0x20001-0x2000d] offset 2
...
pci_sun4v f02ae7f8: PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x2007e-0x2007e0fff] (bus 
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x20010-0x27eff] (bus 
address [0x0010-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x2000d] (bus 
address [0x1-0xd])

-v3: put back mem64_offset, as we found T4 has mem_offset != mem64_offset
 check overlapping between mem64_space and mem_space.
-v7: after new pci_mmap_page_range patches.
-v8: remove change in pci_resource_to_user()

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci.c|  6 +++---
 arch/sparc/kernel/pci_common.c | 32 
 arch/sparc/kernel/pci_impl.h   |  4 
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 7eceaa1..c5cf813 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -663,12 +663,12 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
printk("PCI: Scanning PBM %s\n", node->full_name);
 
pci_add_resource_offset(, >io_space,
-   pbm->io_space.start);
+   pbm->io_offset);
pci_add_resource_offset(, >mem_space,
-   pbm->mem_space.start);
+   pbm->mem_offset);
if (pbm->mem64_space.flags)
pci_add_resource_offset(, >mem64_space,
-   pbm->mem_space.start);
+   pbm->mem64_offset);
pbm->busn.start = pbm->pci_first_busno;
pbm->busn.end   = pbm->pci_last_busno;
pbm->busn.flags = IORESOURCE_BUS;
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 33524c1..76998f8 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -410,13 +410,16 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
 
for (i = 0; i < num_pbm_ranges; i++) {
const struct linux_prom_pci_ranges *pr = _ranges[i];
-   unsigned long a, size;
+   unsigned long a, size, region_a;
u32 parent_phys_hi, parent_phys_lo;
+   u32 child_phys_mid, child_phys_lo;
u32 size_hi, size_lo;
int type;
 
parent_phys_hi = pr->parent_phys_hi;
parent_phys_lo = pr->parent_phys_lo;
+   child_phys_mid = pr->child_phys_mid;
+   child_phys_lo = pr->child_phys_lo;
if (tlb_type == hypervisor)
parent_phys_hi &= 0x0fff;
 
@@ -426,6 +429,8 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
type = (pr->child_phys_hi >> 24) & 0x3;
a = (((unsigned long)parent_phys_hi << 32UL) |
 ((unsigned long)parent_phys_lo  <<  0UL));
+   region_a = (((unsigned long)child_phys_mid << 32UL) |
+((unsigned long)child_phys_lo  <<  0UL));
size = (((unsigned long)size_hi << 32UL) |
((unsigned long)size_lo  <<  0UL));
 
@@ -440,6 +445,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->io_space.start = a;
pbm->io_space.end = a + size - 1UL;
pbm->io_space.flags = IORESOURCE_IO;
+   pbm->io_offset = a - region_a;
saw_io = 1;
break;
 
@@ -448,6 +454,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->mem_space.start = a;
pbm->mem_space.end = a + size - 1UL;
pbm->mem_space.flags = IORESOURCE_MEM;
+   pbm->mem_offset = a - region_a;
saw_mem = 1;
break;
 
@@ -456,6 +463,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->mem64_space.start = a;
pbm->mem64_space.end = a + size - 1UL;
pbm->mem64_space.flags = IORESOURCE_MEM;
+   pbm->mem64_offset = a - region_a;

[PATCH 12/13] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64

[Yinghai Lu]

If host bridge does not have mmio64 above 4G, We don't need to
treat device non-pref mmio64 as as pref mmio64.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/setup-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index b3fd314..7a0e59b 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -738,7 +738,7 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int i)
 static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
 {
if (pci_is_root_bus(bus))
-   return true;
+   return to_pci_host_bridge(bus->bridge)->has_mem64;
 
if (bus->self) {
int i;
-- 
2.9.3

[PATCH 02/13] PCI: Add pci_find_bus_resource()

[Yinghai Lu]

Add pci_find_bus_resource() to return bus resource for input resource.

In some case, we may only have bus instead of dev.
It is same as pci_find_parent_resource, but take bus as input.

Signed-off-by: Yinghai Lu 
---
 drivers/pci/pci.c   | 27 ---
 include/linux/pci.h |  2 ++
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4ffa152..deb828f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -437,18 +437,9 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
 }
 EXPORT_SYMBOL_GPL(pci_find_ht_capability);
 
-/**
- * pci_find_parent_resource - return resource region of parent bus of given 
region
- * @dev: PCI device structure contains resources to be searched
- * @res: child resource record for which parent is sought
- *
- *  For given resource region of given device, return the resource
- *  region of parent bus the given region is contained in.
- */
-struct resource *pci_find_parent_resource(const struct pci_dev *dev,
- struct resource *res)
+struct resource *pci_find_bus_resource(const struct pci_bus *bus,
+   struct resource *res)
 {
-   const struct pci_bus *bus = dev->bus;
struct resource *r;
int i;
 
@@ -478,6 +469,20 @@ struct resource *pci_find_parent_resource(const struct 
pci_dev *dev,
}
return NULL;
 }
+
+/**
+ * pci_find_parent_resource - return resource region of parent bus of given 
region
+ * @dev: PCI device structure contains resources to be searched
+ * @res: child resource record for which parent is sought
+ *
+ *  For given resource region of given device, return the resource
+ *  region of parent bus the given region is contained in.
+ */
+struct resource *pci_find_parent_resource(const struct pci_dev *dev,
+ struct resource *res)
+{
+   return pci_find_bus_resource(dev->bus, res);
+}
 EXPORT_SYMBOL(pci_find_parent_resource);
 
 /**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 88185ff..817786b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -836,6 +836,8 @@ void pcibios_resource_to_bus(struct pci_bus *bus, struct 
pci_bus_region *region,
 struct resource *res);
 void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
 struct pci_bus_region *region);
+struct resource *pci_find_bus_resource(const struct pci_bus *bus,
+   struct resource *res);
 void pcibios_scan_specific_bus(int busn);
 struct pci_bus *pci_find_bus(int domain, int busnr);
 void pci_bus_add_devices(const struct pci_bus *bus);
-- 
2.9.3

[PATCH 12/13] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64

[Yinghai Lu]

If host bridge does not have mmio64 above 4G, We don't need to
treat device non-pref mmio64 as as pref mmio64.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/setup-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index b3fd314..7a0e59b 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -738,7 +738,7 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int i)
 static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
 {
if (pci_is_root_bus(bus))
-   return true;
+   return to_pci_host_bridge(bus->bridge)->has_mem64;
 
if (bus->self) {
int i;
-- 
2.9.3

[PATCH 02/13] PCI: Add pci_find_bus_resource()

[Yinghai Lu]

Add pci_find_bus_resource() to return bus resource for input resource.

In some case, we may only have bus instead of dev.
It is same as pci_find_parent_resource, but take bus as input.

Signed-off-by: Yinghai Lu 
---
 drivers/pci/pci.c   | 27 ---
 include/linux/pci.h |  2 ++
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4ffa152..deb828f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -437,18 +437,9 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
 }
 EXPORT_SYMBOL_GPL(pci_find_ht_capability);
 
-/**
- * pci_find_parent_resource - return resource region of parent bus of given 
region
- * @dev: PCI device structure contains resources to be searched
- * @res: child resource record for which parent is sought
- *
- *  For given resource region of given device, return the resource
- *  region of parent bus the given region is contained in.
- */
-struct resource *pci_find_parent_resource(const struct pci_dev *dev,
- struct resource *res)
+struct resource *pci_find_bus_resource(const struct pci_bus *bus,
+   struct resource *res)
 {
-   const struct pci_bus *bus = dev->bus;
struct resource *r;
int i;
 
@@ -478,6 +469,20 @@ struct resource *pci_find_parent_resource(const struct 
pci_dev *dev,
}
return NULL;
 }
+
+/**
+ * pci_find_parent_resource - return resource region of parent bus of given 
region
+ * @dev: PCI device structure contains resources to be searched
+ * @res: child resource record for which parent is sought
+ *
+ *  For given resource region of given device, return the resource
+ *  region of parent bus the given region is contained in.
+ */
+struct resource *pci_find_parent_resource(const struct pci_dev *dev,
+ struct resource *res)
+{
+   return pci_find_bus_resource(dev->bus, res);
+}
 EXPORT_SYMBOL(pci_find_parent_resource);
 
 /**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 88185ff..817786b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -836,6 +836,8 @@ void pcibios_resource_to_bus(struct pci_bus *bus, struct 
pci_bus_region *region,
 struct resource *res);
 void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
 struct pci_bus_region *region);
+struct resource *pci_find_bus_resource(const struct pci_bus *bus,
+   struct resource *res);
 void pcibios_scan_specific_bus(int busn);
 struct pci_bus *pci_find_bus(int domain, int busnr);
 void pci_bus_add_devices(const struct pci_bus *bus);
-- 
2.9.3

[PATCH 09/13] PCI: Check pref compatible bit for mem64 resource of PCIe device

[Yinghai Lu]

We still get "no compatible bridge window" warning on sparc T5-8
after we add support for 64bit resource parsing for root bus.

 PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
 PCI: Claiming :00:01.0: Resource 15: 8001..8004afff 
[220c]
 PCI: Claiming :01:00.0: Resource 15: 8001..8004afff 
[220c]
 PCI: Claiming :02:04.0: Resource 15: 8001..80012fff 
[220c]
 PCI: Claiming :03:00.0: Resource 15: 8001..80012fff 
[220c]
 PCI: Claiming :04:06.0: Resource 14: 8001..80010fff 
[220c]
 PCI: Claiming :05:00.0: Resource 0: 8001..80011fff 
[204]
 pci :05:00.0: can't claim BAR 0 [mem 0x8001-0x80011fff]: no 
compatible bridge window

All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mmio under pref mmio.

According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.

Mark if the entire path from the host to the adapter is over PCI Express.
Set pref compatible bit for claim/sizing/assign for 64bit mem resource
on that pcie device.

-v2: set pref for mmio 64 when whole path is PCI Express, according to David 
Miller.
-v3: don't set pref directly, change to UNDER_PREF, and set PREF before
 sizing and assign resource, and cleart PREF afterwards. requested by BenH.
-v4: use on_all_pcie_path device flag instead.
-v6: update after pci_find_bus_resource() change

Link: 
http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern 
Tested-by: David Ahern 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
Tested-by: TJ 
Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci_common.c |  2 +-
 drivers/pci/pci.c  |  8 +---
 drivers/pci/pci.h  |  2 ++
 drivers/pci/probe.c| 33 +
 drivers/pci/setup-bus.c| 23 +++
 drivers/pci/setup-res.c|  4 
 include/linux/pci.h|  3 ++-
 7 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 1ebc7ff..6f206a1 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -343,7 +343,7 @@ static void pci_register_region(struct pci_bus *bus, const 
char *name,
region.start = rstart;
region.end = rstart + size - 1UL;
pcibios_bus_to_resource(bus, res, );
-   bus_res = pci_find_bus_resource(bus, res);
+   bus_res = pci_find_bus_resource(bus, res, res->flags);
if (!bus_res) {
kfree(res);
return;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index deb828f..bdb70b7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -438,7 +438,7 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
 EXPORT_SYMBOL_GPL(pci_find_ht_capability);
 
 struct resource *pci_find_bus_resource(const struct pci_bus *bus,
-   struct resource *res)
+   struct resource *res, int flags)
 {
struct resource *r;
int i;
@@ -453,7 +453,7 @@ struct resource *pci_find_bus_resource(const struct pci_bus 
*bus,
 * not, the allocator made a mistake.
 */
if (r->flags & IORESOURCE_PREFETCH &&
-   !(res->flags & IORESOURCE_PREFETCH))
+   !(flags & IORESOURCE_PREFETCH))
return NULL;
 
/*
@@ -481,7 +481,9 @@ struct resource *pci_find_bus_resource(const struct pci_bus 
*bus,
 struct resource *pci_find_parent_resource(const struct pci_dev *dev,
  struct resource *res)
 {
-   return pci_find_bus_resource(dev->bus, res);
+   int flags = pci_resource_pref_compatible(dev, res);
+
+   return pci_find_bus_resource(dev->bus, res, flags);
 }
 EXPORT_SYMBOL(pci_find_parent_resource);
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 586e63f..eb57780 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -368,4 +368,6 @@ int acpi_get_rc_resources(struct device *dev, const char 
*hid, u16 segment,
  struct resource *res);
 #endif
 
+int pci_resource_pref_compatible(const struct pci_dev *dev,
+struct resource *res);
 #endif /* DRIVERS_PCI_H */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5548044..676b55f 100644
--- a/drivers/pci/probe.c
+++ 

[PATCH 09/13] PCI: Check pref compatible bit for mem64 resource of PCIe device

[Yinghai Lu]

We still get "no compatible bridge window" warning on sparc T5-8
after we add support for 64bit resource parsing for root bus.

 PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
 PCI: Claiming :00:01.0: Resource 15: 8001..8004afff 
[220c]
 PCI: Claiming :01:00.0: Resource 15: 8001..8004afff 
[220c]
 PCI: Claiming :02:04.0: Resource 15: 8001..80012fff 
[220c]
 PCI: Claiming :03:00.0: Resource 15: 8001..80012fff 
[220c]
 PCI: Claiming :04:06.0: Resource 14: 8001..80010fff 
[220c]
 PCI: Claiming :05:00.0: Resource 0: 8001..80011fff 
[204]
 pci :05:00.0: can't claim BAR 0 [mem 0x8001-0x80011fff]: no 
compatible bridge window

All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mmio under pref mmio.

According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.

Mark if the entire path from the host to the adapter is over PCI Express.
Set pref compatible bit for claim/sizing/assign for 64bit mem resource
on that pcie device.

-v2: set pref for mmio 64 when whole path is PCI Express, according to David 
Miller.
-v3: don't set pref directly, change to UNDER_PREF, and set PREF before
 sizing and assign resource, and cleart PREF afterwards. requested by BenH.
-v4: use on_all_pcie_path device flag instead.
-v6: update after pci_find_bus_resource() change

Link: 
http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern 
Tested-by: David Ahern 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
Tested-by: TJ 
Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci_common.c |  2 +-
 drivers/pci/pci.c  |  8 +---
 drivers/pci/pci.h  |  2 ++
 drivers/pci/probe.c| 33 +
 drivers/pci/setup-bus.c| 23 +++
 drivers/pci/setup-res.c|  4 
 include/linux/pci.h|  3 ++-
 7 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 1ebc7ff..6f206a1 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -343,7 +343,7 @@ static void pci_register_region(struct pci_bus *bus, const 
char *name,
region.start = rstart;
region.end = rstart + size - 1UL;
pcibios_bus_to_resource(bus, res, );
-   bus_res = pci_find_bus_resource(bus, res);
+   bus_res = pci_find_bus_resource(bus, res, res->flags);
if (!bus_res) {
kfree(res);
return;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index deb828f..bdb70b7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -438,7 +438,7 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
 EXPORT_SYMBOL_GPL(pci_find_ht_capability);
 
 struct resource *pci_find_bus_resource(const struct pci_bus *bus,
-   struct resource *res)
+   struct resource *res, int flags)
 {
struct resource *r;
int i;
@@ -453,7 +453,7 @@ struct resource *pci_find_bus_resource(const struct pci_bus 
*bus,
 * not, the allocator made a mistake.
 */
if (r->flags & IORESOURCE_PREFETCH &&
-   !(res->flags & IORESOURCE_PREFETCH))
+   !(flags & IORESOURCE_PREFETCH))
return NULL;
 
/*
@@ -481,7 +481,9 @@ struct resource *pci_find_bus_resource(const struct pci_bus 
*bus,
 struct resource *pci_find_parent_resource(const struct pci_dev *dev,
  struct resource *res)
 {
-   return pci_find_bus_resource(dev->bus, res);
+   int flags = pci_resource_pref_compatible(dev, res);
+
+   return pci_find_bus_resource(dev->bus, res, flags);
 }
 EXPORT_SYMBOL(pci_find_parent_resource);
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 586e63f..eb57780 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -368,4 +368,6 @@ int acpi_get_rc_resources(struct device *dev, const char 
*hid, u16 segment,
  struct resource *res);
 #endif
 
+int pci_resource_pref_compatible(const struct pci_dev *dev,
+struct resource *res);
 #endif /* DRIVERS_PCI_H */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5548044..676b55f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1920,6 +1920,36 @@ static void pci_dma_configure(struct pci_dev *dev)

[PATCH 10/13] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64

[Yinghai Lu]

If any bridge up to root only have 32bit pref mmio, We don't need to
treat device non-pref mmio64 as as pref mmio64.

We need to move pci_bridge_check_ranges calling early.
For parent bridges pref mmio BAR may not allocated by BIOS, res flags
is still 0, we need to have it correct set before we check them for
child device resources.

-v2: check all bus resources instead of just res[15].

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/setup-bus.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 3de66e6..b3fd314 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -735,6 +735,29 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int 
i)
return -EINVAL;
 }
 
+static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
+{
+   if (pci_is_root_bus(bus))
+   return true;
+
+   if (bus->self) {
+   int i;
+   bool found = false;
+   struct resource *res;
+
+   pci_bus_for_each_resource(bus, res, i)
+   if (res->flags & IORESOURCE_MEM_64) {
+   found = true;
+   break;
+   }
+
+   if (!found)
+   return false;
+   }
+
+   return pci_up_path_over_pref_mem64(bus->parent);
+}
+
 int pci_resource_pref_compatible(const struct pci_dev *dev,
 struct resource *res)
 {
@@ -743,7 +766,8 @@ int pci_resource_pref_compatible(const struct pci_dev *dev,
 
if ((res->flags & IORESOURCE_MEM) &&
(res->flags & IORESOURCE_MEM_64) &&
-   dev->on_all_pcie_path)
+   dev->on_all_pcie_path &&
+   pci_up_path_over_pref_mem64(dev->bus))
return res->flags | IORESOURCE_PREFETCH;
 
return res->flags;
@@ -1236,6 +1260,10 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
struct resource *b_res;
int ret;
 
+   if (!pci_is_root_bus(bus) &&
+   (bus->self->class >> 8) == PCI_CLASS_BRIDGE_PCI)
+   pci_bridge_check_ranges(bus);
+
list_for_each_entry(dev, >devices, bus_list) {
struct pci_bus *b = dev->subordinate;
if (!b)
@@ -1263,7 +1291,6 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
break;
 
case PCI_CLASS_BRIDGE_PCI:
-   pci_bridge_check_ranges(bus);
if (bus->self->is_hotplug_bridge) {
additional_io_size  = pci_hotplug_io_size;
additional_mem_size = pci_hotplug_mem_size;
-- 
2.9.3

[PATCH 10/13] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64

[Yinghai Lu]

If any bridge up to root only have 32bit pref mmio, We don't need to
treat device non-pref mmio64 as as pref mmio64.

We need to move pci_bridge_check_ranges calling early.
For parent bridges pref mmio BAR may not allocated by BIOS, res flags
is still 0, we need to have it correct set before we check them for
child device resources.

-v2: check all bus resources instead of just res[15].

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/setup-bus.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 3de66e6..b3fd314 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -735,6 +735,29 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int 
i)
return -EINVAL;
 }
 
+static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
+{
+   if (pci_is_root_bus(bus))
+   return true;
+
+   if (bus->self) {
+   int i;
+   bool found = false;
+   struct resource *res;
+
+   pci_bus_for_each_resource(bus, res, i)
+   if (res->flags & IORESOURCE_MEM_64) {
+   found = true;
+   break;
+   }
+
+   if (!found)
+   return false;
+   }
+
+   return pci_up_path_over_pref_mem64(bus->parent);
+}
+
 int pci_resource_pref_compatible(const struct pci_dev *dev,
 struct resource *res)
 {
@@ -743,7 +766,8 @@ int pci_resource_pref_compatible(const struct pci_dev *dev,
 
if ((res->flags & IORESOURCE_MEM) &&
(res->flags & IORESOURCE_MEM_64) &&
-   dev->on_all_pcie_path)
+   dev->on_all_pcie_path &&
+   pci_up_path_over_pref_mem64(dev->bus))
return res->flags | IORESOURCE_PREFETCH;
 
return res->flags;
@@ -1236,6 +1260,10 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
struct resource *b_res;
int ret;
 
+   if (!pci_is_root_bus(bus) &&
+   (bus->self->class >> 8) == PCI_CLASS_BRIDGE_PCI)
+   pci_bridge_check_ranges(bus);
+
list_for_each_entry(dev, >devices, bus_list) {
struct pci_bus *b = dev->subordinate;
if (!b)
@@ -1263,7 +1291,6 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
break;
 
case PCI_CLASS_BRIDGE_PCI:
-   pci_bridge_check_ranges(bus);
if (bus->self->is_hotplug_bridge) {
additional_io_size  = pci_hotplug_io_size;
additional_mem_size = pci_hotplug_mem_size;
-- 
2.9.3

Re: [PATCH] ASoC: rsnd: fix semicolon.cocci warnings

[Kuninori Morimoto]

Hi

> sound/soc/sh/rcar/adg.c:462:54-55: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> CC: Kuninori Morimoto 
> Signed-off-by: Fengguang Wu 

Where is my brown paper bag ?

Acked-by: Kuninori Morimoto 

> ---
> 
>  adg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/sound/soc/sh/rcar/adg.c
> +++ b/sound/soc/sh/rcar/adg.c
> @@ -459,7 +459,7 @@ static void rsnd_adg_get_clkout(struct r
>* ADG supports BRRA/BRRB output only
>* this means all clkout0/1/2/3 will be same rate
>*/
> - prop = of_find_property(np, "clock-frequency", NULL);;
> + prop = of_find_property(np, "clock-frequency", NULL);
>   req_size = prop->length / sizeof(u32);
>  
>   of_property_read_u32_array(np, "clock-frequency", req_rate, req_size);

[PATCH 06/13] powerpc/PCI: Keep resource idx order with bridge register number

[Yinghai Lu]

Same as sparc version.

Make resource with consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index ea3d981..9581e00 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -252,7 +252,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
bus->resource[i] = res;
++res;
}
-   i = 1;
+   i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
flags = pci_parse_of_flags(of_read_number(ranges, 1), 1);
size = of_read_number([6], 2);
@@ -265,6 +265,12 @@ void of_scan_pci_bridge(struct pci_dev *dev)
   " for bridge %s\n", node->full_name);
continue;
}
+   } else if ((flags & IORESOURCE_PREFETCH) &&
+  !bus->resource[2]->flags) {
+   res = bus->resource[2];
+   } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+   IORESOURCE_MEM) && !bus->resource[1]->flags) {
+   res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.9.3

[PATCH 04/13] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

[Yinghai Lu]

For device resource with PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

so this patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: "David S. Miller" 
Cc: sparcli...@vger.kernel.org
Tested-by: Khalid Aziz 
---
 arch/sparc/kernel/of_device_32.c | 5 +++--
 arch/sparc/kernel/of_device_64.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 185aa96..3e9f273 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -83,11 +83,12 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, 
unsigned long flags)
case 0x01:
flags |= IORESOURCE_IO;
break;
-
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index 7bbdc26..defee61 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -146,11 +146,12 @@ static unsigned long of_bus_pci_get_flags(const u32 
*addr, unsigned long flags)
case 0x01:
flags |= IORESOURCE_IO;
break;
-
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
-- 
2.9.3

[PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

[Yinghai Lu]

For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

This patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Tested-by: Khalid Aziz 
---
 drivers/of/address.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..d1bb76c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -131,9 +131,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 
*addr)
flags |= IORESOURCE_IO;
break;
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
-- 
2.9.3

Re: [PATCH] ASoC: rsnd: fix semicolon.cocci warnings

[Kuninori Morimoto]

Hi

> sound/soc/sh/rcar/adg.c:462:54-55: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> CC: Kuninori Morimoto 
> Signed-off-by: Fengguang Wu 

Where is my brown paper bag ?

Acked-by: Kuninori Morimoto 

> ---
> 
>  adg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/sound/soc/sh/rcar/adg.c
> +++ b/sound/soc/sh/rcar/adg.c
> @@ -459,7 +459,7 @@ static void rsnd_adg_get_clkout(struct r
>* ADG supports BRRA/BRRB output only
>* this means all clkout0/1/2/3 will be same rate
>*/
> - prop = of_find_property(np, "clock-frequency", NULL);;
> + prop = of_find_property(np, "clock-frequency", NULL);
>   req_size = prop->length / sizeof(u32);
>  
>   of_property_read_u32_array(np, "clock-frequency", req_rate, req_size);

[PATCH 06/13] powerpc/PCI: Keep resource idx order with bridge register number

[Yinghai Lu]

Same as sparc version.

Make resource with consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu 
Cc: linuxppc-...@lists.ozlabs.org
---
 arch/powerpc/kernel/pci_of_scan.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index ea3d981..9581e00 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -252,7 +252,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
bus->resource[i] = res;
++res;
}
-   i = 1;
+   i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
flags = pci_parse_of_flags(of_read_number(ranges, 1), 1);
size = of_read_number([6], 2);
@@ -265,6 +265,12 @@ void of_scan_pci_bridge(struct pci_dev *dev)
   " for bridge %s\n", node->full_name);
continue;
}
+   } else if ((flags & IORESOURCE_PREFETCH) &&
+  !bus->resource[2]->flags) {
+   res = bus->resource[2];
+   } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+   IORESOURCE_MEM) && !bus->resource[1]->flags) {
+   res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.9.3

[PATCH 04/13] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

[Yinghai Lu]

For device resource with PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

so this patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: "David S. Miller" 
Cc: sparcli...@vger.kernel.org
Tested-by: Khalid Aziz 
---
 arch/sparc/kernel/of_device_32.c | 5 +++--
 arch/sparc/kernel/of_device_64.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 185aa96..3e9f273 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -83,11 +83,12 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, 
unsigned long flags)
case 0x01:
flags |= IORESOURCE_IO;
break;
-
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index 7bbdc26..defee61 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -146,11 +146,12 @@ static unsigned long of_bus_pci_get_flags(const u32 
*addr, unsigned long flags)
case 0x01:
flags |= IORESOURCE_IO;
break;
-
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
-- 
2.9.3

[PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

[Yinghai Lu]

For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.

This patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Tested-by: Khalid Aziz 
---
 drivers/of/address.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..d1bb76c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -131,9 +131,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 
*addr)
flags |= IORESOURCE_IO;
break;
case 0x02: /* 32 bits */
-   case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+   case 0x03: /* 64 bits */
+   flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+   break;
}
if (w & 0x4000)
flags |= IORESOURCE_PREFETCH;
-- 
2.9.3

[PATCH 13/13] PCI: Restore pref MMIO allocation logic for host bridge without mmio64

[Yinghai Lu]

>From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit
resources), we change the logic for pref mmio allocation:
When bridge pref support mmio64, we will only put children pref
that support mmio64 into it, and will put children pref mmio32
into bridge's non-pref mmio32.

That could leave bridge pref bar not used when that pref bar is mmio64,
and children res only has mmio32.
Also could have allocation failure when non-pref mmio32 is not big
enough space for those children pref mmio32.

That is not rational when the host bridge does not have 64bit mmio
above 4g at all.

The patch restore to old logic:
when host bridge does not have has_mem64, put children pref mmio64 and
pref mmio32 all under bridges pref bars.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/bus.c   |  4 +++-
 drivers/pci/setup-bus.c | 13 +
 drivers/pci/setup-res.c |  9 ++---
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index bc56cf1..79205fb 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -233,8 +233,10 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct 
resource *res,
 {
 #ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
int rc;
+   unsigned long mmio64 = pci_find_host_bridge(bus)->has_mem64 ?
+   IORESOURCE_MEM_64 : 0;
 
-   if (res->flags & IORESOURCE_MEM_64) {
+   if (res->flags & mmio64) {
rc = pci_bus_alloc_from_region(bus, res, size, align, min,
   type_mask, alignf, alignf_data,
   _high);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7a0e59b..f29cf5d 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1308,7 +1308,8 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
b_res = >self->resource[PCI_BRIDGE_RESOURCES];
mask = IORESOURCE_MEM;
prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-   if (b_res[2].flags & IORESOURCE_MEM_64) {
+   if ((b_res[2].flags & IORESOURCE_MEM_64) &&
+   pci_find_host_bridge(bus)->has_mem64) {
prefmask |= IORESOURCE_MEM_64;
ret = pbus_size_mem(bus, prefmask, prefmask,
  prefmask, prefmask,
@@ -1578,17 +1579,21 @@ static void pci_bridge_release_resources(struct pci_bus 
*bus,
 *io port.
 * 2. if there is non pref mmio assign fail, release bridge
 *nonpref mmio.
-* 3. if there is 64bit pref mmio assign fail, and bridge pref
+* 3. if there is pref mmio assign fail, and host bridge does
+*have 64bit mmio, release bridge pref mmio.
+* 4. if there is 64bit pref mmio assign fail, and bridge pref
 *is 64bit, release bridge pref mmio.
-* 4. if there is pref mmio assign fail, and bridge pref is
+* 5. if there is pref mmio assign fail, and bridge pref is
 *32bit mmio, release bridge pref mmio
-* 5. if there is pref mmio assign fail, and bridge pref is not
+* 6. if there is pref mmio assign fail, and bridge pref is not
 *assigned, release bridge nonpref mmio.
 */
if (type & IORESOURCE_IO)
idx = 0;
else if (!(type & IORESOURCE_PREFETCH))
idx = 1;
+   else if (!pci_find_host_bridge(bus)->has_mem64)
+   idx = 2;
else if ((type & IORESOURCE_MEM_64) &&
 (b_res[2].flags & IORESOURCE_MEM_64))
idx = 2;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 2aeb4bc..49cfb55 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -240,6 +240,8 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
struct resource *res = dev->resource + resno;
resource_size_t min;
int ret;
+   unsigned long mmio64 = pci_find_host_bridge(bus)->has_mem64 ?
+   IORESOURCE_MEM_64 : 0;
 
min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
 
@@ -251,7 +253,7 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
 * things differently than they were sized, not everything will fit.
 */
ret = pci_bus_alloc_resource(bus, res, size, align, min,
-IORESOURCE_PREFETCH | IORESOURCE_MEM_64,
+IORESOURCE_PREFETCH | mmio64,
 pcibios_align_resource, dev);
if (ret == 0)
return 0;
@@ -260,7 +262,8 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
 * If the prefetchable 

[PATCH 13/13] PCI: Restore pref MMIO allocation logic for host bridge without mmio64

[Yinghai Lu]

>From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit
resources), we change the logic for pref mmio allocation:
When bridge pref support mmio64, we will only put children pref
that support mmio64 into it, and will put children pref mmio32
into bridge's non-pref mmio32.

That could leave bridge pref bar not used when that pref bar is mmio64,
and children res only has mmio32.
Also could have allocation failure when non-pref mmio32 is not big
enough space for those children pref mmio32.

That is not rational when the host bridge does not have 64bit mmio
above 4g at all.

The patch restore to old logic:
when host bridge does not have has_mem64, put children pref mmio64 and
pref mmio32 all under bridges pref bars.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/bus.c   |  4 +++-
 drivers/pci/setup-bus.c | 13 +
 drivers/pci/setup-res.c |  9 ++---
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index bc56cf1..79205fb 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -233,8 +233,10 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct 
resource *res,
 {
 #ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
int rc;
+   unsigned long mmio64 = pci_find_host_bridge(bus)->has_mem64 ?
+   IORESOURCE_MEM_64 : 0;
 
-   if (res->flags & IORESOURCE_MEM_64) {
+   if (res->flags & mmio64) {
rc = pci_bus_alloc_from_region(bus, res, size, align, min,
   type_mask, alignf, alignf_data,
   _high);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7a0e59b..f29cf5d 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1308,7 +1308,8 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
b_res = >self->resource[PCI_BRIDGE_RESOURCES];
mask = IORESOURCE_MEM;
prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-   if (b_res[2].flags & IORESOURCE_MEM_64) {
+   if ((b_res[2].flags & IORESOURCE_MEM_64) &&
+   pci_find_host_bridge(bus)->has_mem64) {
prefmask |= IORESOURCE_MEM_64;
ret = pbus_size_mem(bus, prefmask, prefmask,
  prefmask, prefmask,
@@ -1578,17 +1579,21 @@ static void pci_bridge_release_resources(struct pci_bus 
*bus,
 *io port.
 * 2. if there is non pref mmio assign fail, release bridge
 *nonpref mmio.
-* 3. if there is 64bit pref mmio assign fail, and bridge pref
+* 3. if there is pref mmio assign fail, and host bridge does
+*have 64bit mmio, release bridge pref mmio.
+* 4. if there is 64bit pref mmio assign fail, and bridge pref
 *is 64bit, release bridge pref mmio.
-* 4. if there is pref mmio assign fail, and bridge pref is
+* 5. if there is pref mmio assign fail, and bridge pref is
 *32bit mmio, release bridge pref mmio
-* 5. if there is pref mmio assign fail, and bridge pref is not
+* 6. if there is pref mmio assign fail, and bridge pref is not
 *assigned, release bridge nonpref mmio.
 */
if (type & IORESOURCE_IO)
idx = 0;
else if (!(type & IORESOURCE_PREFETCH))
idx = 1;
+   else if (!pci_find_host_bridge(bus)->has_mem64)
+   idx = 2;
else if ((type & IORESOURCE_MEM_64) &&
 (b_res[2].flags & IORESOURCE_MEM_64))
idx = 2;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 2aeb4bc..49cfb55 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -240,6 +240,8 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
struct resource *res = dev->resource + resno;
resource_size_t min;
int ret;
+   unsigned long mmio64 = pci_find_host_bridge(bus)->has_mem64 ?
+   IORESOURCE_MEM_64 : 0;
 
min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
 
@@ -251,7 +253,7 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
 * things differently than they were sized, not everything will fit.
 */
ret = pci_bus_alloc_resource(bus, res, size, align, min,
-IORESOURCE_PREFETCH | IORESOURCE_MEM_64,
+IORESOURCE_PREFETCH | mmio64,
 pcibios_align_resource, dev);
if (ret == 0)
return 0;
@@ -260,7 +262,8 @@ static int __pci_assign_resource(struct pci_bus *bus, 
struct pci_dev *dev,
 * If the prefetchable window is only 32 bits wide, we can put
   

[PATCH 11/13] PCI: Add has_mem64 for struct host_bridge

[Yinghai Lu]

Add has_mem64 for struct host_bridge, on root bus that does not support
mmio64 above 4g, will not set that.

We will use that info next two following patches:
1. Don't treat non-pref mmio64 as pref mmio, so will not put
   it under bridge's pref range when rescan the devices
2. will keep pref mmio64 and pref mmio32 under bridge pref bar.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/probe.c | 7 +++
 include/linux/pci.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 676b55f..8f439e0 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -818,6 +818,13 @@ int pci_register_host_bridge(struct pci_host_bridge 
*bridge)
addr[0] = '\0';
 
dev_info(>dev, "root bus resource %pR%s\n", res, addr);
+
+   if (resource_type(res) == IORESOURCE_MEM) {
+   if ((res->end - offset) > 0x)
+   bridge->has_mem64 = 1;
+   if ((res->start - offset) > 0x)
+   res->flags |= IORESOURCE_MEM_64;
+   }
}
 
down_write(_bus_sem);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b14dd94..a3693ef 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -436,6 +436,7 @@ struct pci_host_bridge {
void *release_data;
struct msi_controller *msi;
unsigned int ignore_reset_delay:1;  /* for entire hierarchy */
+   unsigned int has_mem64:1;
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
const struct resource *res,
-- 
2.9.3

[PATCH 11/13] PCI: Add has_mem64 for struct host_bridge

[Yinghai Lu]

Add has_mem64 for struct host_bridge, on root bus that does not support
mmio64 above 4g, will not set that.

We will use that info next two following patches:
1. Don't treat non-pref mmio64 as pref mmio, so will not put
   it under bridge's pref range when rescan the devices
2. will keep pref mmio64 and pref mmio32 under bridge pref bar.

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
---
 drivers/pci/probe.c | 7 +++
 include/linux/pci.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 676b55f..8f439e0 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -818,6 +818,13 @@ int pci_register_host_bridge(struct pci_host_bridge 
*bridge)
addr[0] = '\0';
 
dev_info(>dev, "root bus resource %pR%s\n", res, addr);
+
+   if (resource_type(res) == IORESOURCE_MEM) {
+   if ((res->end - offset) > 0x)
+   bridge->has_mem64 = 1;
+   if ((res->start - offset) > 0x)
+   res->flags |= IORESOURCE_MEM_64;
+   }
}
 
down_write(_bus_sem);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b14dd94..a3693ef 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -436,6 +436,7 @@ struct pci_host_bridge {
void *release_data;
struct msi_controller *msi;
unsigned int ignore_reset_delay:1;  /* for entire hierarchy */
+   unsigned int has_mem64:1;
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
const struct resource *res,
-- 
2.9.3

[PATCH 03/13] sparc/PCI: Reserve legacy mmio after PCI mmio

[Yinghai Lu]

On one system found bunch of claim resource fail from pci device.
pci_sun4v f02b894c: PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x2007e-0x2007e0fff] (bus 
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x2-0x27eff] (bus 
address [0x-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x20007] (bus 
address [0x1-0x7])
...
PCI: Claiming :00:02.0: Resource 14: 0002..0002004f 
[200]
pci :00:02.0: can't claim BAR 14 [mem 0x2-0x2004f]: 
address conflict with Video RAM area [??? 0x2000a-0x2000b flags 
0x8000]
pci :02:00.0: can't claim BAR 0 [mem 0x2-0x2000f]: no 
compatible bridge window
PCI: Claiming :02:00.0: Resource 3: 00020010..000200103fff [200]
pci :02:00.0: can't claim BAR 3 [mem 0x20010-0x200103fff]: no 
compatible bridge window
PCI: Claiming :02:00.1: Resource 0: 00020020..0002002f [200]
pci :02:00.1: can't claim BAR 0 [mem 0x20020-0x2002f]: no 
compatible bridge window
PCI: Claiming :02:00.1: Resource 3: 000200104000..000200107fff [200]
pci :02:00.1: can't claim BAR 3 [mem 0x200104000-0x200107fff]: no 
compatible bridge window
PCI: Claiming :02:00.2: Resource 0: 00020030..0002003f [200]
pci :02:00.2: can't claim BAR 0 [mem 0x20030-0x2003f]: no 
compatible bridge window
PCI: Claiming :02:00.2: Resource 3: 000200108000..00020010bfff [200]
pci :02:00.2: can't claim BAR 3 [mem 0x200108000-0x20010bfff]: no 
compatible bridge window
PCI: Claiming :02:00.3: Resource 0: 00020040..0002004f [200]
pci :02:00.3: can't claim BAR 0 [mem 0x20040-0x2004f]: no 
compatible bridge window
PCI: Claiming :02:00.3: Resource 3: 00020010c000..00020010 [200]
pci :02:00.3: can't claim BAR 3 [mem 0x20010c000-0x20010]: no 
compatible bridge window

The bridge 00:02.0 resource does not get reserved as Video RAM take the 
position early,
and following children resources reservation all fail.

Move down Video RAM area reservation after pci mmio get reserved,
so we leave pci driver to use those regions.

-v5: merge simplify one and use pcibios_bus_to_resource()

-v6: use pci_find_bus_resource()

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci.c|  1 +
 arch/sparc/kernel/pci_common.c | 59 ++
 arch/sparc/kernel/pci_impl.h   |  1 +
 3 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index c5cf813..adb9653 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -686,6 +686,7 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
pci_bus_register_of_sysfs(bus);
 
pci_claim_bus_resources(bus);
+   pci_register_legacy_regions(bus);
pci_bus_add_devices(bus);
return bus;
 }
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 76998f8..1ebc7ff 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -328,41 +328,46 @@ void pci_get_pbm_props(struct pci_pbm_info *pbm)
}
 }
 
-static void pci_register_legacy_regions(struct resource *io_res,
-   struct resource *mem_res)
+static void pci_register_region(struct pci_bus *bus, const char *name,
+   resource_size_t rstart, resource_size_t size)
 {
-   struct resource *p;
+   struct resource *res, *conflict, *bus_res;
+   struct pci_bus_region region;
 
-   /* VGA Video RAM. */
-   p = kzalloc(sizeof(*p), GFP_KERNEL);
-   if (!p)
+   res = kzalloc(sizeof(*res), GFP_KERNEL);
+   if (!res)
return;
 
-   p->name = "Video RAM area";
-   p->start = mem_res->start + 0xaUL;
-   p->end = p->start + 0x1UL;
-   p->flags = IORESOURCE_BUSY;
-   request_resource(mem_res, p);
+   res->flags = IORESOURCE_MEM;
 
-   p = kzalloc(sizeof(*p), GFP_KERNEL);
-   if (!p)
+   region.start = rstart;
+   region.end = rstart + size - 1UL;
+   pcibios_bus_to_resource(bus, res, );
+   bus_res = pci_find_bus_resource(bus, res);
+   if (!bus_res) {
+   kfree(res);
return;
+   }
+
+   res->name = name;
+   res->flags |= IORESOURCE_BUSY;
+   conflict = request_resource_conflict(bus_res, res);
+   if (conflict) {
+   dev_printk(KERN_DEBUG, >dev,
+   " can't claim %s %pR: address conflict with %s %pR\n",
+   res->name, res, conflict->name, conflict);
+   kfree(res);
+   }
+}
 

[PATCH 03/13] sparc/PCI: Reserve legacy mmio after PCI mmio

[Yinghai Lu]

On one system found bunch of claim resource fail from pci device.
pci_sun4v f02b894c: PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x2007e-0x2007e0fff] (bus 
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x2-0x27eff] (bus 
address [0x-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x20007] (bus 
address [0x1-0x7])
...
PCI: Claiming :00:02.0: Resource 14: 0002..0002004f 
[200]
pci :00:02.0: can't claim BAR 14 [mem 0x2-0x2004f]: 
address conflict with Video RAM area [??? 0x2000a-0x2000b flags 
0x8000]
pci :02:00.0: can't claim BAR 0 [mem 0x2-0x2000f]: no 
compatible bridge window
PCI: Claiming :02:00.0: Resource 3: 00020010..000200103fff [200]
pci :02:00.0: can't claim BAR 3 [mem 0x20010-0x200103fff]: no 
compatible bridge window
PCI: Claiming :02:00.1: Resource 0: 00020020..0002002f [200]
pci :02:00.1: can't claim BAR 0 [mem 0x20020-0x2002f]: no 
compatible bridge window
PCI: Claiming :02:00.1: Resource 3: 000200104000..000200107fff [200]
pci :02:00.1: can't claim BAR 3 [mem 0x200104000-0x200107fff]: no 
compatible bridge window
PCI: Claiming :02:00.2: Resource 0: 00020030..0002003f [200]
pci :02:00.2: can't claim BAR 0 [mem 0x20030-0x2003f]: no 
compatible bridge window
PCI: Claiming :02:00.2: Resource 3: 000200108000..00020010bfff [200]
pci :02:00.2: can't claim BAR 3 [mem 0x200108000-0x20010bfff]: no 
compatible bridge window
PCI: Claiming :02:00.3: Resource 0: 00020040..0002004f [200]
pci :02:00.3: can't claim BAR 0 [mem 0x20040-0x2004f]: no 
compatible bridge window
PCI: Claiming :02:00.3: Resource 3: 00020010c000..00020010 [200]
pci :02:00.3: can't claim BAR 3 [mem 0x20010c000-0x20010]: no 
compatible bridge window

The bridge 00:02.0 resource does not get reserved as Video RAM take the 
position early,
and following children resources reservation all fail.

Move down Video RAM area reservation after pci mmio get reserved,
so we leave pci driver to use those regions.

-v5: merge simplify one and use pcibios_bus_to_resource()

-v6: use pci_find_bus_resource()

Signed-off-by: Yinghai Lu 
Tested-by: Khalid Aziz 
Cc: sparcli...@vger.kernel.org
---
 arch/sparc/kernel/pci.c|  1 +
 arch/sparc/kernel/pci_common.c | 59 ++
 arch/sparc/kernel/pci_impl.h   |  1 +
 3 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index c5cf813..adb9653 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -686,6 +686,7 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
pci_bus_register_of_sysfs(bus);
 
pci_claim_bus_resources(bus);
+   pci_register_legacy_regions(bus);
pci_bus_add_devices(bus);
return bus;
 }
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 76998f8..1ebc7ff 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -328,41 +328,46 @@ void pci_get_pbm_props(struct pci_pbm_info *pbm)
}
 }
 
-static void pci_register_legacy_regions(struct resource *io_res,
-   struct resource *mem_res)
+static void pci_register_region(struct pci_bus *bus, const char *name,
+   resource_size_t rstart, resource_size_t size)
 {
-   struct resource *p;
+   struct resource *res, *conflict, *bus_res;
+   struct pci_bus_region region;
 
-   /* VGA Video RAM. */
-   p = kzalloc(sizeof(*p), GFP_KERNEL);
-   if (!p)
+   res = kzalloc(sizeof(*res), GFP_KERNEL);
+   if (!res)
return;
 
-   p->name = "Video RAM area";
-   p->start = mem_res->start + 0xaUL;
-   p->end = p->start + 0x1UL;
-   p->flags = IORESOURCE_BUSY;
-   request_resource(mem_res, p);
+   res->flags = IORESOURCE_MEM;
 
-   p = kzalloc(sizeof(*p), GFP_KERNEL);
-   if (!p)
+   region.start = rstart;
+   region.end = rstart + size - 1UL;
+   pcibios_bus_to_resource(bus, res, );
+   bus_res = pci_find_bus_resource(bus, res);
+   if (!bus_res) {
+   kfree(res);
return;
+   }
+
+   res->name = name;
+   res->flags |= IORESOURCE_BUSY;
+   conflict = request_resource_conflict(bus_res, res);
+   if (conflict) {
+   dev_printk(KERN_DEBUG, >dev,
+   " can't claim %s %pR: address conflict with %s %pR\n",
+   res->name, res, conflict->name, conflict);
+   kfree(res);
+   }
+}
 
-   p->name = "System ROM";
-   

Re: linux-next: build failure after merge of the drm-misc tree

[Logan Gunthorpe]

Thanks Stephen. Looks good to me.

Logan

On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in 
> initializer
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>   ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>  ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 
> 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in 
> initializer
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 
> 'tee_shm_dma_buf_ops.end_cpu_access')
> 
> Caused by commit
> 
>   f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with 
> kunmap_atomic macro")
> 
> interacting with commit
> 
>   967c9cca2cc5 ("tee: generic TEE subsystem")
> 
> from the arm-soc tree.
> 
> I applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/tee/tee_shm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
>   .map_dma_buf = tee_shm_op_map_dma_buf,
>   .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
>   .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
>   .mmap = tee_shm_op_mmap,
>  };
>  
> 

Re: linux-next: build failure after merge of the drm-misc tree

[Logan Gunthorpe]

Thanks Stephen. Looks good to me.

Logan

On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in 
> initializer
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>   ^
> drivers/tee/tee_shm.c:87:17: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap_atomic = tee_shm_op_kmap_atomic,
>  ^
> drivers/tee/tee_shm.c:87:17: note: (near initialization for 
> 'tee_shm_dma_buf_ops.begin_cpu_access')
> drivers/tee/tee_shm.c:88:2: error: unknown field 'kmap' specified in 
> initializer
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .kmap = tee_shm_op_kmap,
>   ^
> drivers/tee/tee_shm.c:88:10: note: (near initialization for 
> 'tee_shm_dma_buf_ops.end_cpu_access')
> 
> Caused by commit
> 
>   f9b67f0014cb ("dma-buf: Rename dma-ops to prevent conflict with 
> kunmap_atomic macro")
> 
> interacting with commit
> 
>   967c9cca2cc5 ("tee: generic TEE subsystem")
> 
> from the arm-soc tree.
> 
> I applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Fri, 21 Apr 2017 12:06:32 +1000
> Subject: [PATCH] tee: merge fix for dma-ops field name changes
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/tee/tee_shm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 0be1e3e93bee..4e14c9c9cb1c 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -84,8 +84,8 @@ static struct dma_buf_ops tee_shm_dma_buf_ops = {
>   .map_dma_buf = tee_shm_op_map_dma_buf,
>   .unmap_dma_buf = tee_shm_op_unmap_dma_buf,
>   .release = tee_shm_op_release,
> - .kmap_atomic = tee_shm_op_kmap_atomic,
> - .kmap = tee_shm_op_kmap,
> + .map_atomic = tee_shm_op_kmap_atomic,
> + .map = tee_shm_op_kmap,
>   .mmap = tee_shm_op_mmap,
>  };
>  
> 

[PATCH] ASoC: rsnd: fix semicolon.cocci warnings

[kbuild test robot]

sound/soc/sh/rcar/adg.c:462:54-55: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Kuninori Morimoto 
Signed-off-by: Fengguang Wu 
---

 adg.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -459,7 +459,7 @@ static void rsnd_adg_get_clkout(struct r
 * ADG supports BRRA/BRRB output only
 * this means all clkout0/1/2/3 will be same rate
 */
-   prop = of_find_property(np, "clock-frequency", NULL);;
+   prop = of_find_property(np, "clock-frequency", NULL);
req_size = prop->length / sizeof(u32);
 
of_property_read_u32_array(np, "clock-frequency", req_rate, req_size);

[PATCH] ASoC: rsnd: fix semicolon.cocci warnings

[kbuild test robot]

sound/soc/sh/rcar/adg.c:462:54-55: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Kuninori Morimoto 
Signed-off-by: Fengguang Wu 
---

 adg.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/sh/rcar/adg.c
+++ b/sound/soc/sh/rcar/adg.c
@@ -459,7 +459,7 @@ static void rsnd_adg_get_clkout(struct r
 * ADG supports BRRA/BRRB output only
 * this means all clkout0/1/2/3 will be same rate
 */
-   prop = of_find_property(np, "clock-frequency", NULL);;
+   prop = of_find_property(np, "clock-frequency", NULL);
req_size = prop->length / sizeof(u32);
 
of_property_read_u32_array(np, "clock-frequency", req_rate, req_size);

Re: [PATCH v3] kbuild: Add support to generate LLVM bitcode files

[Masahiro Yamada]

Hi Matthias,


2017-04-05 2:27 GMT+09:00 Matthias Kaehlcke :
> From: Vinícius Tinti 
>
> Add rules to kbuild in order to generate LLVM bitcode files with the .ll
> extension when using clang.


First, I'd like to be sure about the terminology "LLVM bitcode"
because "bitcode" sounds like human-unreadable binary.


For example, 'man llvm-as' says:
llvm-as  is  the  LLVM  assembler.  It reads a file containing
human-readable LLVM assembly language, translates it to LLVM
bitcode, and writes the result into a file or to standard output.


As far as I understood:

*.ll   -  LLVM assembly  (human readable file)
*.bc   -  LLVM bitcode   (binary file)

Is this correct?






>   # from c code
>   CC=clang make kernel/pid.ll

This does not work because CC is overridden in the top-level Makefile.
It should be
make CC=clang kernel/pid.ll




>   # from asm code
>   CC=clang make arch/x86/kernel/preempt.ll

arch/x86/kernel/preempt.* does not exist
(at least in the latest tree).




> +
> +quiet_cmd_as_ll_S = CPP $(quiet_modtag) $@
> +  cmd_as_ll_S = $(CPP) $(a_flags)   -o $@ $<
> +
> +$(obj)/%.ll: $(src)/%.S FORCE
> +   $(call if_changed_dep,as_ll_S)
> +

I could not understand how this rule can convert
architecture-specific assembly to LLVM intermediate expression.

This is just pre-processing *.S file.


Actually, this is completely the same as the rule *.S -> *.s

quiet_cmd_cpp_s_S = CPP $(quiet_modtag) $@
cmd_cpp_s_S   = $(CPP) $(a_flags) -o $@ $<

$(obj)/%.s: $(src)/%.S FORCE
  $(call if_changed_dep,cpp_s_S)





-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3] kbuild: Add support to generate LLVM bitcode files

[Masahiro Yamada]

Hi Matthias,


2017-04-05 2:27 GMT+09:00 Matthias Kaehlcke :
> From: Vinícius Tinti 
>
> Add rules to kbuild in order to generate LLVM bitcode files with the .ll
> extension when using clang.


First, I'd like to be sure about the terminology "LLVM bitcode"
because "bitcode" sounds like human-unreadable binary.


For example, 'man llvm-as' says:
llvm-as  is  the  LLVM  assembler.  It reads a file containing
human-readable LLVM assembly language, translates it to LLVM
bitcode, and writes the result into a file or to standard output.


As far as I understood:

*.ll   -  LLVM assembly  (human readable file)
*.bc   -  LLVM bitcode   (binary file)

Is this correct?






>   # from c code
>   CC=clang make kernel/pid.ll

This does not work because CC is overridden in the top-level Makefile.
It should be
make CC=clang kernel/pid.ll




>   # from asm code
>   CC=clang make arch/x86/kernel/preempt.ll

arch/x86/kernel/preempt.* does not exist
(at least in the latest tree).




> +
> +quiet_cmd_as_ll_S = CPP $(quiet_modtag) $@
> +  cmd_as_ll_S = $(CPP) $(a_flags)   -o $@ $<
> +
> +$(obj)/%.ll: $(src)/%.S FORCE
> +   $(call if_changed_dep,as_ll_S)
> +

I could not understand how this rule can convert
architecture-specific assembly to LLVM intermediate expression.

This is just pre-processing *.S file.


Actually, this is completely the same as the rule *.S -> *.s

quiet_cmd_cpp_s_S = CPP $(quiet_modtag) $@
cmd_cpp_s_S   = $(CPP) $(a_flags) -o $@ $<

$(obj)/%.s: $(src)/%.S FORCE
  $(call if_changed_dep,cpp_s_S)





-- 
Best Regards
Masahiro Yamada

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Dan Williams]

On Thu, Apr 20, 2017 at 4:07 PM, Stephen  Bates  wrote:
>>> Yes, this makes sense I think we really just want to distinguish host
>>> memory or not in terms of the dev_pagemap type.
>>
>>> I would like to see mutually exclusive flags for host memory (or not) and 
>>> persistence (or not).
>>>
>>
>> Why persistence? It has zero meaning to the mm.
>
> I like the idea of having properties of the memory in one place.

We do have memory type data in the global iomem_resource tree, see
IORES_DESC_PERSISTENT_MEMORY.

> While mm might not use persistence today it may make use certain things that
> persistence implies (like finite endurance and/or higher write latency) in 
> the future.

A persistence flag does not convey endurance or latency information.

> Also the persistence of the memory must have issues for mm security?

Not for the mm, data at rest security might be a property of the
device, but that's not the mm's concern.

>Again not addressed today but useful in the future.

Maybe, but to me "Useful for the future" == "don't add it to the
kernel until that future arrives".

> In addition I am not sure where else would be an appropriate place to put 
> something like a persistence property flag. I know the NVDIMM section of the 
> kernel uses things like NFIT to describe properties of the memory but we 
> don’t yet (to my knowledge) have something similar for IO memory.

Do the IORES_DESC flags give you what you need?

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

[Dan Williams]

On Thu, Apr 20, 2017 at 4:07 PM, Stephen  Bates  wrote:
>>> Yes, this makes sense I think we really just want to distinguish host
>>> memory or not in terms of the dev_pagemap type.
>>
>>> I would like to see mutually exclusive flags for host memory (or not) and 
>>> persistence (or not).
>>>
>>
>> Why persistence? It has zero meaning to the mm.
>
> I like the idea of having properties of the memory in one place.

We do have memory type data in the global iomem_resource tree, see
IORES_DESC_PERSISTENT_MEMORY.

> While mm might not use persistence today it may make use certain things that
> persistence implies (like finite endurance and/or higher write latency) in 
> the future.

A persistence flag does not convey endurance or latency information.

> Also the persistence of the memory must have issues for mm security?

Not for the mm, data at rest security might be a property of the
device, but that's not the mm's concern.

>Again not addressed today but useful in the future.

Maybe, but to me "Useful for the future" == "don't add it to the
kernel until that future arrives".

> In addition I am not sure where else would be an appropriate place to put 
> something like a persistence property flag. I know the NVDIMM section of the 
> kernel uses things like NFIT to describe properties of the memory but we 
> don’t yet (to my knowledge) have something similar for IO memory.

Do the IORES_DESC flags give you what you need?

Re: linux-next: manual merge of the char-misc tree with the pci tree

[Greg KH]

On Fri, Apr 21, 2017 at 02:45:40PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got a conflict in:
> 
>   drivers/misc/Makefile
> 
> between commit:
> 
>   58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")
> 
> from the pci tree and commits:
> 
>   6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
>   51c1e9b554c9 ("auxdisplay: Move panel.c to drivers/auxdisplay folder")
> 
> from the char-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/misc/Makefile
> index 6e139cd70421,4fb10af2ea1c..
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@@ -53,8 -52,7 +52,8 @@@ obj-$(CONFIG_GENWQE)+= genwqe
>   obj-$(CONFIG_ECHO)  += echo/
>   obj-$(CONFIG_VEXPRESS_SYSCFG)   += vexpress-syscfg.o
>   obj-$(CONFIG_CXL_BASE)  += cxl/
> - obj-$(CONFIG_PANEL) += panel.o
> + obj-$(CONFIG_ASPEED_LPC_CTRL)   += aspeed-lpc-ctrl.o
>  +obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
>   
>   lkdtm-$(CONFIG_LKDTM)   += lkdtm_core.o
>   lkdtm-$(CONFIG_LKDTM)   += lkdtm_bugs.o

Looks good to me!

thanks,

greg k-h

Re: linux-next: manual merge of the char-misc tree with the pci tree

[Greg KH]

On Fri, Apr 21, 2017 at 02:45:40PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got a conflict in:
> 
>   drivers/misc/Makefile
> 
> between commit:
> 
>   58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")
> 
> from the pci tree and commits:
> 
>   6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
>   51c1e9b554c9 ("auxdisplay: Move panel.c to drivers/auxdisplay folder")
> 
> from the char-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/misc/Makefile
> index 6e139cd70421,4fb10af2ea1c..
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@@ -53,8 -52,7 +52,8 @@@ obj-$(CONFIG_GENWQE)+= genwqe
>   obj-$(CONFIG_ECHO)  += echo/
>   obj-$(CONFIG_VEXPRESS_SYSCFG)   += vexpress-syscfg.o
>   obj-$(CONFIG_CXL_BASE)  += cxl/
> - obj-$(CONFIG_PANEL) += panel.o
> + obj-$(CONFIG_ASPEED_LPC_CTRL)   += aspeed-lpc-ctrl.o
>  +obj-$(CONFIG_PCI_ENDPOINT_TEST) += pci_endpoint_test.o
>   
>   lkdtm-$(CONFIG_LKDTM)   += lkdtm_core.o
>   lkdtm-$(CONFIG_LKDTM)   += lkdtm_bugs.o

Looks good to me!

thanks,

greg k-h

[GIT PULL] Please pull powerpc/linux.git powerpc-4.11-8 tag

[Michael Ellerman]

Hi Linus,

Please pull two final powerpc fixes for 4.11:

The following changes since commit 4749228f022893faf54a3dbc70796f78b7d4f342:

  powerpc/crypto/crc32c-vpmsum: Fix missing preempt_disable() (2017-04-07 
21:12:58 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.11-8

for you to fetch changes up to be5c5e843c4afa1c8397cb740b6032bd4142f32d:

  powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=y (2017-04-18 
20:19:52 +1000)


powerpc fixes for 4.11 #8

Just two fixes. The first fixes kprobing a stdu, and is marked for stable as
it's been broken for ~ever. In hindsight this could have gone in next.

The other is a fix for a change we merged this cycle, where if we take a certain
exception when the kernel is running relocated (currently only used for kdump),
we checkstop the box.

Thanks to:
  Ravi Bangoria.


Michael Ellerman (1):
  powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=y

Ravi Bangoria (1):
  powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction

 arch/powerpc/include/asm/exception-64s.h | 8 
 arch/powerpc/kernel/entry_64.S   | 6 +++---
 arch/powerpc/kernel/exceptions-64s.S | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)


signature.asc
Description: PGP signature

[GIT PULL] Please pull powerpc/linux.git powerpc-4.11-8 tag

[Michael Ellerman]

Hi Linus,

Please pull two final powerpc fixes for 4.11:

The following changes since commit 4749228f022893faf54a3dbc70796f78b7d4f342:

  powerpc/crypto/crc32c-vpmsum: Fix missing preempt_disable() (2017-04-07 
21:12:58 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.11-8

for you to fetch changes up to be5c5e843c4afa1c8397cb740b6032bd4142f32d:

  powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=y (2017-04-18 
20:19:52 +1000)


powerpc fixes for 4.11 #8

Just two fixes. The first fixes kprobing a stdu, and is marked for stable as
it's been broken for ~ever. In hindsight this could have gone in next.

The other is a fix for a change we merged this cycle, where if we take a certain
exception when the kernel is running relocated (currently only used for kdump),
we checkstop the box.

Thanks to:
  Ravi Bangoria.


Michael Ellerman (1):
  powerpc/64: Fix HMI exception on LE with CONFIG_RELOCATABLE=y

Ravi Bangoria (1):
  powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction

 arch/powerpc/include/asm/exception-64s.h | 8 
 arch/powerpc/kernel/entry_64.S   | 6 +++---
 arch/powerpc/kernel/exceptions-64s.S | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)


signature.asc
Description: PGP signature

linux-next: manual merge of the char-misc tree with the pci tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/misc/Makefile

between commit:

  58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")

from the pci tree and commits:

  6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
  51c1e9b554c9 ("auxdisplay: Move panel.c to drivers/auxdisplay folder")

from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/misc/Makefile
index 6e139cd70421,4fb10af2ea1c..
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@@ -53,8 -52,7 +52,8 @@@ obj-$(CONFIG_GENWQE)  += genwqe
  obj-$(CONFIG_ECHO)+= echo/
  obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
  obj-$(CONFIG_CXL_BASE)+= cxl/
- obj-$(CONFIG_PANEL) += panel.o
+ obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
 +obj-$(CONFIG_PCI_ENDPOINT_TEST)   += pci_endpoint_test.o
  
  lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
  lkdtm-$(CONFIG_LKDTM) += lkdtm_bugs.o

linux-next: manual merge of the char-misc tree with the pci tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in:

  drivers/misc/Makefile

between commit:

  58c89c8aa0e8 ("misc: Add host side PCI driver for PCI test function device")

from the pci tree and commits:

  6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver")
  51c1e9b554c9 ("auxdisplay: Move panel.c to drivers/auxdisplay folder")

from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/misc/Makefile
index 6e139cd70421,4fb10af2ea1c..
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@@ -53,8 -52,7 +52,8 @@@ obj-$(CONFIG_GENWQE)  += genwqe
  obj-$(CONFIG_ECHO)+= echo/
  obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
  obj-$(CONFIG_CXL_BASE)+= cxl/
- obj-$(CONFIG_PANEL) += panel.o
+ obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
 +obj-$(CONFIG_PCI_ENDPOINT_TEST)   += pci_endpoint_test.o
  
  lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
  lkdtm-$(CONFIG_LKDTM) += lkdtm_bugs.o

Re: [LTP] [lkp-robot] [KEYS] bdf7c0f8bf: ltp.add_key02.fail

[Eric Biggers]

Hi Cyril,

On Thu, Apr 20, 2017 at 02:57:50PM +0200, Cyril Hrubis wrote:
> > 
> > In my opinion this is a valid behavior, and the test is just weird; it's 
> > passing
> > in *both* an unaddressable payload and an invalid description, so it's not 
> > clear
> > which case it's meant to be testing.  (Generally, if a syscall will fail for
> > more than one reason, it's not guaranteed which error code you'll get.)
> 
> That is quite common problem with LTP testcases. Do you care to send a
> patch or should I fix that?
> 

I'll plan to send a patch.  Also, it looks like the testing that LTP does of
add_key() is very sparse, so I'll try to extend it a bit.

> > In any case, once we have a fix merged, it would be nice for there to be an 
> > ltp
> > test added for the "NULL payload with nonzero length" case with one of the 
> > key
> > types that crashed the kernel.
> 
> Here as well, feel free to send a patch or at least point us to a
> reproducer that could be turned into a testcase.
> 

I'll plan to send a patch for that as well.

Thanks,

Eric

Re: [LTP] [lkp-robot] [KEYS] bdf7c0f8bf: ltp.add_key02.fail

[Eric Biggers]

Hi Cyril,

On Thu, Apr 20, 2017 at 02:57:50PM +0200, Cyril Hrubis wrote:
> > 
> > In my opinion this is a valid behavior, and the test is just weird; it's 
> > passing
> > in *both* an unaddressable payload and an invalid description, so it's not 
> > clear
> > which case it's meant to be testing.  (Generally, if a syscall will fail for
> > more than one reason, it's not guaranteed which error code you'll get.)
> 
> That is quite common problem with LTP testcases. Do you care to send a
> patch or should I fix that?
> 

I'll plan to send a patch.  Also, it looks like the testing that LTP does of
add_key() is very sparse, so I'll try to extend it a bit.

> > In any case, once we have a fix merged, it would be nice for there to be an 
> > ltp
> > test added for the "NULL payload with nonzero length" case with one of the 
> > key
> > types that crashed the kernel.
> 
> Here as well, feel free to send a patch or at least point us to a
> reproducer that could be turned into a testcase.
> 

I'll plan to send a patch for that as well.

Thanks,

Eric

Re: your mail

[Joonsoo Kim]

On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> [...]
> > > Which pfn walkers you have in mind?
> > 
> > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > using pfn_valid().
> 
> Yeah, I've checked that one and in fact this is a good example of the
> case where you do not really care about holes. It just checks the page
> count which is a valid information under any circumstances.

I don't think so. First, it checks the page *map* count. Is it still valid
even if PageReserved() is set? What I'd like to ask in this example is
that what information is valid if PageReserved() is set. Is there any
design document on this? I think that we need to define/document it first.

And, I hope that all the information in flags field is valid in all
cases if pfn_valid() return true. By the design.

This makes all the exsiting pfn walkers happy since we don't need an
additional check for PageReserved().

> 
> > > > The other problem I found is that your change will makes some
> > > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > > by memblock API is also marked as PageResereved. If we consider this as
> > > > a hole, we will set such a zone as non-contiguous.
> > > 
> > > Why would that be a problem? We shouldn't touch those pages anyway?
> > 
> > Skipping those pages in compaction are valid so no problem in this
> > case.
> > 
> > The problem I mentioned above is that adding PageReserved() check in
> > __pageblock_pfn_to_page() invalidates optimization by
> > set_zone_contiguous(). In compaction, we need to get a valid struct
> > page and it requires a lot of work. There is performance problem
> > report due to this so set_zone_contiguous() optimization is added. It
> > checks if the zone is contiguous or not in boot time. If zone is
> > determined as contiguous, we can easily get a valid struct page in
> > runtime without expensive checks.
> 
> OK, I see. I've had some vague understading and the clarification helps.
> 
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
> 
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
>   - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
>   - drop this patch
>   - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
> 
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?

I like #1 among of above options and I already see your patch for #1.
It's much better than your first attempt but I'm still not happy due
to the semantic of pfn_valid().

> [..]
> > Let me clarify my desire(?) for this issue.
> > 
> > 1. If pfn_valid() returns true, struct page has valid information, at
> > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > without checking PageResereved().
> 
> This is no longer true after my rework. Pages are associated with the
> zone during _onlining_ rather than when they are physically hotpluged.

If your rework make information valid during _onlining_, my
suggestion is making pfn_valid() return false until onlining.

Caller of pfn_valid() expects that they can get valid information from
the struct page. There is no reason to access the struct page if they
can't get valid information from it. So, passing pfn_valid() should
guarantee that, at least, some kind of information is valid.

If pfn_valid() doesn't guarantee it, most of the pfn walker should
check PageResereved() to make sure that validity of information from
the struct page.

> Basically only the nid is set properly. Strictly speaking this is the
> case also without my rework because the zone might change during online
> phase so you cannot assume it is correct even now. It just happens that
> it more or less works just fine.
>
> > 2. pfn_valid() for offlined holes returns false. This can be easily
> > (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> > guess that there is no reason that pfn_valid() returns true for
> > offlined holes. If there is, please let me know.
> 
> There is some code which really expects that pfn_valid returns true iff
> there is a struct page and it doesn't care about the online status.
> E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
> do though is to add 

Re: your mail

[Joonsoo Kim]

On Thu, Apr 20, 2017 at 09:28:20AM +0200, Michal Hocko wrote:
> On Thu 20-04-17 10:27:55, Joonsoo Kim wrote:
> > On Mon, Apr 17, 2017 at 10:15:15AM +0200, Michal Hocko wrote:
> [...]
> > > Which pfn walkers you have in mind?
> > 
> > For example, kpagecount_read() in fs/proc/page.c. I searched it by
> > using pfn_valid().
> 
> Yeah, I've checked that one and in fact this is a good example of the
> case where you do not really care about holes. It just checks the page
> count which is a valid information under any circumstances.

I don't think so. First, it checks the page *map* count. Is it still valid
even if PageReserved() is set? What I'd like to ask in this example is
that what information is valid if PageReserved() is set. Is there any
design document on this? I think that we need to define/document it first.

And, I hope that all the information in flags field is valid in all
cases if pfn_valid() return true. By the design.

This makes all the exsiting pfn walkers happy since we don't need an
additional check for PageReserved().

> 
> > > > The other problem I found is that your change will makes some
> > > > contiguous zones to be considered as non-contiguous. Memory allocated
> > > > by memblock API is also marked as PageResereved. If we consider this as
> > > > a hole, we will set such a zone as non-contiguous.
> > > 
> > > Why would that be a problem? We shouldn't touch those pages anyway?
> > 
> > Skipping those pages in compaction are valid so no problem in this
> > case.
> > 
> > The problem I mentioned above is that adding PageReserved() check in
> > __pageblock_pfn_to_page() invalidates optimization by
> > set_zone_contiguous(). In compaction, we need to get a valid struct
> > page and it requires a lot of work. There is performance problem
> > report due to this so set_zone_contiguous() optimization is added. It
> > checks if the zone is contiguous or not in boot time. If zone is
> > determined as contiguous, we can easily get a valid struct page in
> > runtime without expensive checks.
> 
> OK, I see. I've had some vague understading and the clarification helps.
> 
> > Your patch try to add PageReserved() to __pageblock_pfn_to_page(). It
> > woule make that zone->contiguous usually returns false since memory
> > used by memblock API is marked as PageReserved() and your patch regard
> > it as a hole. It invalidates set_zone_contiguous() optimization and I
> > worry about it.
> 
> OK, fair enough. I did't consider memblock allocations. I will rethink
> this patch but there are essentially 3 options
>   - use a different criterion for the offline holes dection. I
> have just realized we might do it by storing the online
> information into the mem sections
>   - drop this patch
>   - move the PageReferenced check down the chain into
> isolate_freepages_block resp. isolate_migratepages_block
> 
> I would prefer 3 over 2 over 1. I definitely want to make this more
> robust so 1 is preferable long term but I do not want this to be a
> roadblock to the rest of the rework. Does that sound acceptable to you?

I like #1 among of above options and I already see your patch for #1.
It's much better than your first attempt but I'm still not happy due
to the semantic of pfn_valid().

> [..]
> > Let me clarify my desire(?) for this issue.
> > 
> > 1. If pfn_valid() returns true, struct page has valid information, at
> > least, in flags (zone id, node id, flags, etc...). So, we can use them
> > without checking PageResereved().
> 
> This is no longer true after my rework. Pages are associated with the
> zone during _onlining_ rather than when they are physically hotpluged.

If your rework make information valid during _onlining_, my
suggestion is making pfn_valid() return false until onlining.

Caller of pfn_valid() expects that they can get valid information from
the struct page. There is no reason to access the struct page if they
can't get valid information from it. So, passing pfn_valid() should
guarantee that, at least, some kind of information is valid.

If pfn_valid() doesn't guarantee it, most of the pfn walker should
check PageResereved() to make sure that validity of information from
the struct page.

> Basically only the nid is set properly. Strictly speaking this is the
> case also without my rework because the zone might change during online
> phase so you cannot assume it is correct even now. It just happens that
> it more or less works just fine.
>
> > 2. pfn_valid() for offlined holes returns false. This can be easily
> > (?) implemented by manipulating SECTION_MAP_MASK in hotplug code. I
> > guess that there is no reason that pfn_valid() returns true for
> > offlined holes. If there is, please let me know.
> 
> There is some code which really expects that pfn_valid returns true iff
> there is a struct page and it doesn't care about the online status.
> E.g. hotplug code itself so no, we cannot change pfn_valid. What we can
> do though is to add 

Re: [PATCH v5 04/11] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION

[Anshuman Khandual]

On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi 
> 
> Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration
> functionality to x86_64, which should be safer at the first step.
> 
> Signed-off-by: Naoya Horiguchi 

Aneesh's latest HugeTLB migration enablement on powerpc should
make this work on powerpc platform as well. Will test it out
in some time but for now enabling only on x86 where you have
tested the series makes sense.

Reviewed-by: Anshuman Khandual 

Re: [PATCH v5 04/11] mm: thp: introduce CONFIG_ARCH_ENABLE_THP_MIGRATION

[Anshuman Khandual]

On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi 
> 
> Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration
> functionality to x86_64, which should be safer at the first step.
> 
> Signed-off-by: Naoya Horiguchi 

Aneesh's latest HugeTLB migration enablement on powerpc should
make this work on powerpc platform as well. Will test it out
in some time but for now enabling only on x86 where you have
tested the series makes sense.

Reviewed-by: Anshuman Khandual 

Re: [PATCH 3.18 000/124] 3.18.50-stable review

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 08:38:16PM -0700, Guenter Roeck wrote:
> On 04/20/2017 12:53 PM, Greg Kroah-Hartman wrote:
> > On Thu, Apr 20, 2017 at 04:28:03PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Apr 20, 2017 at 06:46:11AM -0700, Guenter Roeck wrote:
> > > > On 04/19/2017 11:34 PM, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 3.18.50 release.
> > > > > There are 124 patches in this series, all will be posted as a response
> > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > please
> > > > > let me know.
> > > > > 
> > > > > Responses should be made by Sat Apr 22 06:35:33 UTC 2017.
> > > > > Anything received after that time might be too late.
> > > > > 
> > > > 
> > > > Build results:
> > > > total: 139 pass: 133 fail: 6
> > > > Failed builds:
> > > > arm:at91_dt_defconfig
> > > > arm:sama5_defconfig
> > > > avr32:defconfig
> > > > avr32:merisc_defconfig
> > > > avr32:atngw100mkii_evklcd101_defconfig
> > > > mips:cavium_octeon_defconfig
> > > > 
> > > > Qemu test results:
> > > > total: 111 pass: 111 fail: 0
> > > > 
> > > > Build errors:
> > > > 
> > > > drivers/tty/serial/atmel_serial.c: In function 'atmel_flush_buffer':
> > > > drivers/tty/serial/atmel_serial.c:1874: error: 'struct atmel_uart_port' 
> > > > has no member named 'tx_len'
> > > > 
> > > > Culprit: 2ac3772fd20e ("tty/serial: atmel: fix race condition (TX+DMA)")
> > > 
> > > I've just fixed this one.
> > > 
> > > > arch/mips/mm/tlbex.c: In function 'build_huge_handler_tail':
> > > > arch/mips/mm/tlbex.c:767:6: error: 'cpu_has_ftlb' undeclared
> > > > 
> > > > Culprit: 9c2c357eb4aa ("MIPS: Flush wrong invalid FTLB entry for huge 
> > > > page")
> > > 
> > > Odd, let me dig into this one...
> > 
> > That looks to fix an issue that showed up in 4.3, so I've dropped it
> > from the 3.18 stable queue now.
> > 
> > thanks for the report, all should be good now.
> > 
> 
> Are you sure ?
> 
> groeck@server:~/src/linux-stable$ git grep cpu_has_ftlb
> arch/mips/mm/tlbex.c:   if (cpu_has_ftlb && flush) {
> groeck@server:~/src/linux-stable$ git describe
> v3.18.49-125-g7379419992fb

{sigh} it would help if I actually pushed the commit to kernel.org :(

The patch has been deleted from the stable-queue now.

thanks,

greg k-h

Re: [PATCH 3.18 000/124] 3.18.50-stable review

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 08:38:16PM -0700, Guenter Roeck wrote:
> On 04/20/2017 12:53 PM, Greg Kroah-Hartman wrote:
> > On Thu, Apr 20, 2017 at 04:28:03PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Apr 20, 2017 at 06:46:11AM -0700, Guenter Roeck wrote:
> > > > On 04/19/2017 11:34 PM, Greg Kroah-Hartman wrote:
> > > > > This is the start of the stable review cycle for the 3.18.50 release.
> > > > > There are 124 patches in this series, all will be posted as a response
> > > > > to this one.  If anyone has any issues with these being applied, 
> > > > > please
> > > > > let me know.
> > > > > 
> > > > > Responses should be made by Sat Apr 22 06:35:33 UTC 2017.
> > > > > Anything received after that time might be too late.
> > > > > 
> > > > 
> > > > Build results:
> > > > total: 139 pass: 133 fail: 6
> > > > Failed builds:
> > > > arm:at91_dt_defconfig
> > > > arm:sama5_defconfig
> > > > avr32:defconfig
> > > > avr32:merisc_defconfig
> > > > avr32:atngw100mkii_evklcd101_defconfig
> > > > mips:cavium_octeon_defconfig
> > > > 
> > > > Qemu test results:
> > > > total: 111 pass: 111 fail: 0
> > > > 
> > > > Build errors:
> > > > 
> > > > drivers/tty/serial/atmel_serial.c: In function 'atmel_flush_buffer':
> > > > drivers/tty/serial/atmel_serial.c:1874: error: 'struct atmel_uart_port' 
> > > > has no member named 'tx_len'
> > > > 
> > > > Culprit: 2ac3772fd20e ("tty/serial: atmel: fix race condition (TX+DMA)")
> > > 
> > > I've just fixed this one.
> > > 
> > > > arch/mips/mm/tlbex.c: In function 'build_huge_handler_tail':
> > > > arch/mips/mm/tlbex.c:767:6: error: 'cpu_has_ftlb' undeclared
> > > > 
> > > > Culprit: 9c2c357eb4aa ("MIPS: Flush wrong invalid FTLB entry for huge 
> > > > page")
> > > 
> > > Odd, let me dig into this one...
> > 
> > That looks to fix an issue that showed up in 4.3, so I've dropped it
> > from the 3.18 stable queue now.
> > 
> > thanks for the report, all should be good now.
> > 
> 
> Are you sure ?
> 
> groeck@server:~/src/linux-stable$ git grep cpu_has_ftlb
> arch/mips/mm/tlbex.c:   if (cpu_has_ftlb && flush) {
> groeck@server:~/src/linux-stable$ git describe
> v3.18.49-125-g7379419992fb

{sigh} it would help if I actually pushed the commit to kernel.org :(

The patch has been deleted from the stable-queue now.

thanks,

greg k-h

[PATCH] hwmon: (ibmpowernv) Add min/max attributes and current sensors

[Shilpasri G Bhat]

Add support for adding min/max values for the inband sensors copied by
OCC to main memory. And also add current(mA) sensors to the list.

Signed-off-by: Shilpasri G Bhat 
---
 drivers/hwmon/ibmpowernv.c | 55 --
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d2e660..1f329fa8 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -50,6 +50,7 @@ enum sensors {
TEMP,
POWER_SUPPLY,
POWER_INPUT,
+   CURRENT,
MAX_SENSOR_TYPE,
 };
 
@@ -65,7 +66,8 @@ enum sensors {
{"fan", "ibm,opal-sensor-cooling-fan"},
{"temp", "ibm,opal-sensor-amb-temp"},
{"in", "ibm,opal-sensor-power-supply"},
-   {"power", "ibm,opal-sensor-power"}
+   {"power", "ibm,opal-sensor-power"},
+   {"curr"}, /* Follows newer device tree compatible ibm,opal-sensor */
 };
 
 struct sensor_data {
@@ -287,6 +289,7 @@ static int populate_attr_groups(struct platform_device 
*pdev)
opal = of_find_node_by_path("/ibm,opal/sensors");
for_each_child_of_node(opal, np) {
const char *label;
+   int len;
 
if (np->name == NULL)
continue;
@@ -298,10 +301,14 @@ static int populate_attr_groups(struct platform_device 
*pdev)
sensor_groups[type].attr_count++;
 
/*
-* add a new attribute for labels
+* add attributes for labels, min and max
 */
if (!of_property_read_string(np, "label", ))
sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-min", ))
+   sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-max", ))
+   sensor_groups[type].attr_count++;
}
 
of_node_put(opal);
@@ -428,6 +435,50 @@ static int create_device_attrs(struct platform_device 
*pdev)
pgroups[type]->attrs[sensor_groups[type].attr_count++] =
[count++].dev_attr.attr;
}
+
+   if (!of_property_read_u32(np, "sensor-data-max", _id)) {
+   switch (type) {
+   case POWER_INPUT:
+   attr_name = "input_highest";
+   break;
+   case TEMP:
+   attr_name = "max";
+   break;
+   default:
+   attr_name = "highest";
+   break;
+   }
+
+   sdata[count].id = sensor_id;
+   sdata[count].type = type;
+   sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
+   create_hwmon_attr([count], attr_name,
+ show_sensor);
+   pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+   [count++].dev_attr.attr;
+   }
+
+   if (!of_property_read_u32(np, "sensor-data-min", _id)) {
+   switch (type) {
+   case POWER_INPUT:
+   attr_name = "input_lowest";
+   break;
+   case TEMP:
+   attr_name = "min";
+   break;
+   default:
+   attr_name = "lowest";
+   break;
+   }
+
+   sdata[count].id = sensor_id;
+   sdata[count].type = type;
+   sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
+   create_hwmon_attr([count], attr_name,
+ show_sensor);
+   pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+   [count++].dev_attr.attr;
+   }
}
 
 exit_put_node:
-- 
1.8.3.1

[PATCH] hwmon: (ibmpowernv) Add min/max attributes and current sensors

[Shilpasri G Bhat]

Add support for adding min/max values for the inband sensors copied by
OCC to main memory. And also add current(mA) sensors to the list.

Signed-off-by: Shilpasri G Bhat 
---
 drivers/hwmon/ibmpowernv.c | 55 --
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d2e660..1f329fa8 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -50,6 +50,7 @@ enum sensors {
TEMP,
POWER_SUPPLY,
POWER_INPUT,
+   CURRENT,
MAX_SENSOR_TYPE,
 };
 
@@ -65,7 +66,8 @@ enum sensors {
{"fan", "ibm,opal-sensor-cooling-fan"},
{"temp", "ibm,opal-sensor-amb-temp"},
{"in", "ibm,opal-sensor-power-supply"},
-   {"power", "ibm,opal-sensor-power"}
+   {"power", "ibm,opal-sensor-power"},
+   {"curr"}, /* Follows newer device tree compatible ibm,opal-sensor */
 };
 
 struct sensor_data {
@@ -287,6 +289,7 @@ static int populate_attr_groups(struct platform_device 
*pdev)
opal = of_find_node_by_path("/ibm,opal/sensors");
for_each_child_of_node(opal, np) {
const char *label;
+   int len;
 
if (np->name == NULL)
continue;
@@ -298,10 +301,14 @@ static int populate_attr_groups(struct platform_device 
*pdev)
sensor_groups[type].attr_count++;
 
/*
-* add a new attribute for labels
+* add attributes for labels, min and max
 */
if (!of_property_read_string(np, "label", ))
sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-min", ))
+   sensor_groups[type].attr_count++;
+   if (of_find_property(np, "sensor-data-max", ))
+   sensor_groups[type].attr_count++;
}
 
of_node_put(opal);
@@ -428,6 +435,50 @@ static int create_device_attrs(struct platform_device 
*pdev)
pgroups[type]->attrs[sensor_groups[type].attr_count++] =
[count++].dev_attr.attr;
}
+
+   if (!of_property_read_u32(np, "sensor-data-max", _id)) {
+   switch (type) {
+   case POWER_INPUT:
+   attr_name = "input_highest";
+   break;
+   case TEMP:
+   attr_name = "max";
+   break;
+   default:
+   attr_name = "highest";
+   break;
+   }
+
+   sdata[count].id = sensor_id;
+   sdata[count].type = type;
+   sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
+   create_hwmon_attr([count], attr_name,
+ show_sensor);
+   pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+   [count++].dev_attr.attr;
+   }
+
+   if (!of_property_read_u32(np, "sensor-data-min", _id)) {
+   switch (type) {
+   case POWER_INPUT:
+   attr_name = "input_lowest";
+   break;
+   case TEMP:
+   attr_name = "min";
+   break;
+   default:
+   attr_name = "lowest";
+   break;
+   }
+
+   sdata[count].id = sensor_id;
+   sdata[count].type = type;
+   sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
+   create_hwmon_attr([count], attr_name,
+ show_sensor);
+   pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+   [count++].dev_attr.attr;
+   }
}
 
 exit_put_node:
-- 
1.8.3.1

Re: [PATCH v5 03/11] mm: thp: introduce separate TTU flag for thp freezing

[Anshuman Khandual]

On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi 
> 
> TTU_MIGRATION is used to convert pte into migration entry until thp split
> completes. This behavior conflicts with thp migration added later patches,
> so let's introduce a new TTU flag specifically for freezing.
> 
> try_to_unmap() is used both for thp split (via freeze_page()) and page
> migration (via __unmap_and_move()). In freeze_page(), ttu_flag given for
> head page is like below (assuming anonymous thp):
> 
> (TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS | TTU_RMAP_LOCKED | \
>  TTU_MIGRATION | TTU_SPLIT_HUGE_PMD)
> 
> and ttu_flag given for tail pages is:
> 
> (TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS | TTU_RMAP_LOCKED | \
>  TTU_MIGRATION)
> 
> __unmap_and_move() calls try_to_unmap() with ttu_flag:
> 
> (TTU_MIGRATION | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS)
> 
> Now I'm trying to insert a branch for thp migration at the top of
> try_to_unmap_one() like below
> 
> static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
>unsigned long address, void *arg)
>   {
>   ...
>   if (flags & TTU_MIGRATION) {
>   if (!pvmw.pte && page) {
>   set_pmd_migration_entry(, page);
>   continue;
>   }
>   }
> 
> , so try_to_unmap() for tail pages called by thp split can go into thp
> migration code path (which converts *pmd* into migration entry), while
> the expectation is to freeze thp (which converts *pte* into migration entry.)
> 
> I detected this failure as a "bad page state" error in a testcase where
> split_huge_page() is called from queue_pages_pte_range().
> 
> Signed-off-by: Naoya Horiguchi 

It had Kirril's acked-by (https://patchwork.kernel.org/patch/9416221/)
last time around. Please include again.

Re: [PATCH v5 03/11] mm: thp: introduce separate TTU flag for thp freezing

[Anshuman Khandual]

On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi 
> 
> TTU_MIGRATION is used to convert pte into migration entry until thp split
> completes. This behavior conflicts with thp migration added later patches,
> so let's introduce a new TTU flag specifically for freezing.
> 
> try_to_unmap() is used both for thp split (via freeze_page()) and page
> migration (via __unmap_and_move()). In freeze_page(), ttu_flag given for
> head page is like below (assuming anonymous thp):
> 
> (TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS | TTU_RMAP_LOCKED | \
>  TTU_MIGRATION | TTU_SPLIT_HUGE_PMD)
> 
> and ttu_flag given for tail pages is:
> 
> (TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS | TTU_RMAP_LOCKED | \
>  TTU_MIGRATION)
> 
> __unmap_and_move() calls try_to_unmap() with ttu_flag:
> 
> (TTU_MIGRATION | TTU_IGNORE_MLOCK | TTU_IGNORE_ACCESS)
> 
> Now I'm trying to insert a branch for thp migration at the top of
> try_to_unmap_one() like below
> 
> static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
>unsigned long address, void *arg)
>   {
>   ...
>   if (flags & TTU_MIGRATION) {
>   if (!pvmw.pte && page) {
>   set_pmd_migration_entry(, page);
>   continue;
>   }
>   }
> 
> , so try_to_unmap() for tail pages called by thp split can go into thp
> migration code path (which converts *pmd* into migration entry), while
> the expectation is to freeze thp (which converts *pte* into migration entry.)
> 
> I detected this failure as a "bad page state" error in a testcase where
> split_huge_page() is called from queue_pages_pte_range().
> 
> Signed-off-by: Naoya Horiguchi 

It had Kirril's acked-by (https://patchwork.kernel.org/patch/9416221/)
last time around. Please include again.

linux-next: manual merge of the usb tree with the jc_docs tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the usb tree got a conflict in:

  Documentation/media/v4l-drivers/philips.rst

between commit:

  9b06f754133c ("convert philips.txt to ReST and add to media docs")

from the jc_docs tree and commit:

  21470e32ca7f ("usb: fix some references for /proc/bus/usb")

from the usb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/media/v4l-drivers/philips.rst
index 620bcfea7af0,be8c80eff374..
--- a/Documentation/media/v4l-drivers/philips.rst
+++ b/Documentation/media/v4l-drivers/philips.rst
@@@ -145,8 -140,8 +145,8 @@@ dev_hin
  
 A camera is specified by its type (the number from the camera model,
 like PCA645, PCVC750VC, etc) and optionally the serial number (visible
-in /proc/bus/usb/devices). A hint consists of a string with the following
+in /sys/kernel/debug/usb/devices). A hint consists of a string with the 
following
 -   format:
 +   format::
  
[type[.serialnumber]:]node
  

linux-next: manual merge of the usb tree with the jc_docs tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the usb tree got a conflict in:

  Documentation/media/v4l-drivers/philips.rst

between commit:

  9b06f754133c ("convert philips.txt to ReST and add to media docs")

from the jc_docs tree and commit:

  21470e32ca7f ("usb: fix some references for /proc/bus/usb")

from the usb tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/media/v4l-drivers/philips.rst
index 620bcfea7af0,be8c80eff374..
--- a/Documentation/media/v4l-drivers/philips.rst
+++ b/Documentation/media/v4l-drivers/philips.rst
@@@ -145,8 -140,8 +145,8 @@@ dev_hin
  
 A camera is specified by its type (the number from the camera model,
 like PCA645, PCVC750VC, etc) and optionally the serial number (visible
-in /proc/bus/usb/devices). A hint consists of a string with the following
+in /sys/kernel/debug/usb/devices). A hint consists of a string with the 
following
 -   format:
 +   format::
  
[type[.serialnumber]:]node
  

Re: powerpc KVM build break in linux-next (was Re: [PATCH tip/core/rcu 40/40] srcu: Parallelize callback handling)

[Paul E. McKenney]

On Fri, Apr 21, 2017 at 11:42:01AM +1000, Michael Ellerman wrote:
> "Paul E. McKenney"  writes:
> > On Thu, Apr 20, 2017 at 05:28:32PM +0200, Paolo Bonzini wrote:
> >> On 20/04/2017 05:40, Michael Ellerman wrote:
> >> > "Paul E. McKenney"  writes:
> >> > 
> >> > This change seems to have had the non-obvious effect of breaking the
> >> > powerpc KVM build.
> ...
> >> 
> >> Michael, if you want to move the two srcu structs at the end of struct
> >> kvm, that would be fine by me.  Please send a patch yourself so you can
> >> test it on PPC.  Thanks,
> >
> > On the off-chance that it is at all helpful, I have added the commit
> > shown below to -rcu.
> 
> As shown below :)
> 
> > If it helps, I am happy to push this, but am just as happy to drop it
> > in favor of some other fix. If at all possible, I would like to get
> > this into the upcoming merge window.
> 
> Thanks, this looks perfect to me, and if you're happy to put it on top
> of your tree that would limit the breakage to a smaller history window,
> so that would be ideal.
> 
> Tested-by: Michael Ellerman 

Thank you, Michael!

Paolo, does this look good to you?  My upstream maintainer will be much
more likely to take this with your ack.  ;-)

Thanx, Paul

> cheers
> 
> 
> >From a19a6617e2817e485ccc2f7cc5a97bd7ff769b87 Mon Sep 17 00:00:00 2001
> From: "Paul E. McKenney" 
> Date: Thu, 20 Apr 2017 17:30:06 -0700
> Subject: kvm: Move srcu_struct fields to end of struct kvm
> 
> Parallelizing SRCU callback handling increased the size of srcu_struct,
> which moved the kvm_arch field within the kvm struct out of reach of
> powerpc's current assembly code, resulting in the following sort of
> build error:
> 
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range 
> (0xb328 is not between 0x8000 and 0x7fff)
> 
> This commit moves the srcu_struct fields in the kvm structure to follow
> the kvm_arch field, which again allows powerpc's assembly code to
> reach it.
> 
> Reported-by: Stephen Rothwell 
> Reported-by: Michael Ellerman 
> Reported-by: kbuild test robot 
> Suggested-by: Paolo Bonzini 
> Signed-off-by: Paul E. McKenney 
> ---
>  include/linux/kvm_host.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 2c14ad9..96c8e29 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -375,8 +375,6 @@ struct kvm {
>   struct mutex slots_lock;
>   struct mm_struct *mm; /* userspace tied to this vm */
>   struct kvm_memslots *memslots[KVM_ADDRESS_SPACE_NUM];
> - struct srcu_struct srcu;
> - struct srcu_struct irq_srcu;
>   struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
> 
>   /*
> @@ -429,6 +427,8 @@ struct kvm {
>   struct list_head devices;
>   struct dentry *debugfs_dentry;
>   struct kvm_stat_data **debugfs_stat_data;
> + struct srcu_struct srcu;
> + struct srcu_struct irq_srcu;
>  };
> 
>  #define kvm_err(fmt, ...) \
> -- 
> cgit v1.1

Re: powerpc KVM build break in linux-next (was Re: [PATCH tip/core/rcu 40/40] srcu: Parallelize callback handling)

[Paul E. McKenney]

On Fri, Apr 21, 2017 at 11:42:01AM +1000, Michael Ellerman wrote:
> "Paul E. McKenney"  writes:
> > On Thu, Apr 20, 2017 at 05:28:32PM +0200, Paolo Bonzini wrote:
> >> On 20/04/2017 05:40, Michael Ellerman wrote:
> >> > "Paul E. McKenney"  writes:
> >> > 
> >> > This change seems to have had the non-obvious effect of breaking the
> >> > powerpc KVM build.
> ...
> >> 
> >> Michael, if you want to move the two srcu structs at the end of struct
> >> kvm, that would be fine by me.  Please send a patch yourself so you can
> >> test it on PPC.  Thanks,
> >
> > On the off-chance that it is at all helpful, I have added the commit
> > shown below to -rcu.
> 
> As shown below :)
> 
> > If it helps, I am happy to push this, but am just as happy to drop it
> > in favor of some other fix. If at all possible, I would like to get
> > this into the upcoming merge window.
> 
> Thanks, this looks perfect to me, and if you're happy to put it on top
> of your tree that would limit the breakage to a smaller history window,
> so that would be ideal.
> 
> Tested-by: Michael Ellerman 

Thank you, Michael!

Paolo, does this look good to you?  My upstream maintainer will be much
more likely to take this with your ack.  ;-)

Thanx, Paul

> cheers
> 
> 
> >From a19a6617e2817e485ccc2f7cc5a97bd7ff769b87 Mon Sep 17 00:00:00 2001
> From: "Paul E. McKenney" 
> Date: Thu, 20 Apr 2017 17:30:06 -0700
> Subject: kvm: Move srcu_struct fields to end of struct kvm
> 
> Parallelizing SRCU callback handling increased the size of srcu_struct,
> which moved the kvm_arch field within the kvm struct out of reach of
> powerpc's current assembly code, resulting in the following sort of
> build error:
> 
> arch/powerpc/kvm/book3s_hv_rmhandlers.S:617: Error: operand out of range 
> (0xb328 is not between 0x8000 and 0x7fff)
> 
> This commit moves the srcu_struct fields in the kvm structure to follow
> the kvm_arch field, which again allows powerpc's assembly code to
> reach it.
> 
> Reported-by: Stephen Rothwell 
> Reported-by: Michael Ellerman 
> Reported-by: kbuild test robot 
> Suggested-by: Paolo Bonzini 
> Signed-off-by: Paul E. McKenney 
> ---
>  include/linux/kvm_host.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 2c14ad9..96c8e29 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -375,8 +375,6 @@ struct kvm {
>   struct mutex slots_lock;
>   struct mm_struct *mm; /* userspace tied to this vm */
>   struct kvm_memslots *memslots[KVM_ADDRESS_SPACE_NUM];
> - struct srcu_struct srcu;
> - struct srcu_struct irq_srcu;
>   struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
> 
>   /*
> @@ -429,6 +427,8 @@ struct kvm {
>   struct list_head devices;
>   struct dentry *debugfs_dentry;
>   struct kvm_stat_data **debugfs_stat_data;
> + struct srcu_struct srcu;
> + struct srcu_struct irq_srcu;
>  };
> 
>  #define kvm_err(fmt, ...) \
> -- 
> cgit v1.1

Re: [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree

[Minghsiu Tsai]

On Wed, 2017-04-19 at 16:35 -0500, Rob Herring wrote:
> On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> > 
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems.  This also simplifies the
> > device tree.
> 
> It may simplify the DT, but it also breaks compatibility with old DT. 
> Not sure if that's a problem on Mediatek platforms, but please be 
> explicit here that you are breaking compatibility and why that is okay.
> 

I will add the following description for more information.
"
Although it fixes iommu assignment issue, it also break compatibility
with old device tree, so driver patch[1] is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
In mtk_mdp_probe()
Old: for_each_child_of_node(dev->of_node, node)
New: for_each_child_of_node(dev->of_node->parent, node)

[1]https://patchwork.kernel.org/patch/9678833/
"

> > 
> > Signed-off-by: Daniel Kurtz 
> > Signed-off-by: Minghsiu Tsai 
> 
> Should this have Daniel as the author?

This patch is provided by Daniel, so I keep he is the author.
I just split his patch into two parts. One is dts only, and the other is
for driver. I also provide another patch to modify dts bindings
according to this patch.


> 
> > 
> > ---
> >  Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++-
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > index 4182063..0d03e3a 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -2,7 +2,7 @@
> >  
> >  Media Data Path is used for scaling and color space conversion.
> >  
> > -Required properties (controller (parent) node):
> > +Required properties (controller node):
> >  - compatible: "mediatek,mt8173-mdp"
> >  - mediatek,vpu: the node of video processor unit, see
> >Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> > @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> >for details.
> >  
> >  Example:
> > -mdp {
> > -   compatible = "mediatek,mt8173-mdp";
> > -   #address-cells = <2>;
> > -   #size-cells = <2>;
> > -   ranges;
> > -   mediatek,vpu = <>;
> > -
> > mdp_rdma0: rdma@14001000 {
> > compatible = "mediatek,mt8173-mdp-rdma";
> > +"mediatek,mt8173-mdp";
> > reg = <0 0x14001000 0 0x1000>;
> > clocks = < CLK_MM_MDP_RDMA0>,
> >  < CLK_MM_MUTEX_32K>;
> > power-domains = < MT8173_POWER_DOMAIN_MM>;
> > iommus = < M4U_PORT_MDP_RDMA0>;
> > mediatek,larb = <>;
> > +   mediatek,vpu = <>;
> > };
> >  
> > mdp_rdma1: rdma@14002000 {
> > @@ -106,4 +101,3 @@ mdp {
> > iommus = < M4U_PORT_MDP_WROT1>;
> > mediatek,larb = <>;
> > };
> > -};
> > -- 
> > 1.9.1
> > 

Re: [PATCH v5 02/11] mm: mempolicy: add queue_pages_node_check()

[Anshuman Khandual]

On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi 
> 
> Introduce a separate check routine related to MPOL_MF_INVERT flag.
> This patch just does cleanup, no behavioral change.

Can you please send it separately first, this should be debated
and merged quickly and not hang on to the series if we have to
respin again.

Reviewed-by: Anshuman Khandual 

Re: [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree

[Minghsiu Tsai]

On Wed, 2017-04-19 at 16:35 -0500, Rob Herring wrote:
> On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> > 
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems.  This also simplifies the
> > device tree.
> 
> It may simplify the DT, but it also breaks compatibility with old DT. 
> Not sure if that's a problem on Mediatek platforms, but please be 
> explicit here that you are breaking compatibility and why that is okay.
> 

I will add the following description for more information.
"
Although it fixes iommu assignment issue, it also break compatibility
with old device tree, so driver patch[1] is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
In mtk_mdp_probe()
Old: for_each_child_of_node(dev->of_node, node)
New: for_each_child_of_node(dev->of_node->parent, node)

[1]https://patchwork.kernel.org/patch/9678833/
"

> > 
> > Signed-off-by: Daniel Kurtz 
> > Signed-off-by: Minghsiu Tsai 
> 
> Should this have Daniel as the author?

This patch is provided by Daniel, so I keep he is the author.
I just split his patch into two parts. One is dts only, and the other is
for driver. I also provide another patch to modify dts bindings
according to this patch.


> 
> > 
> > ---
> >  Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++-
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > index 4182063..0d03e3a 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -2,7 +2,7 @@
> >  
> >  Media Data Path is used for scaling and color space conversion.
> >  
> > -Required properties (controller (parent) node):
> > +Required properties (controller node):
> >  - compatible: "mediatek,mt8173-mdp"
> >  - mediatek,vpu: the node of video processor unit, see
> >Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> > @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> >for details.
> >  
> >  Example:
> > -mdp {
> > -   compatible = "mediatek,mt8173-mdp";
> > -   #address-cells = <2>;
> > -   #size-cells = <2>;
> > -   ranges;
> > -   mediatek,vpu = <>;
> > -
> > mdp_rdma0: rdma@14001000 {
> > compatible = "mediatek,mt8173-mdp-rdma";
> > +"mediatek,mt8173-mdp";
> > reg = <0 0x14001000 0 0x1000>;
> > clocks = < CLK_MM_MDP_RDMA0>,
> >  < CLK_MM_MUTEX_32K>;
> > power-domains = < MT8173_POWER_DOMAIN_MM>;
> > iommus = < M4U_PORT_MDP_RDMA0>;
> > mediatek,larb = <>;
> > +   mediatek,vpu = <>;
> > };
> >  
> > mdp_rdma1: rdma@14002000 {
> > @@ -106,4 +101,3 @@ mdp {
> > iommus = < M4U_PORT_MDP_WROT1>;
> > mediatek,larb = <>;
> > };
> > -};
> > -- 
> > 1.9.1
> > 

Re: [PATCH v5 02/11] mm: mempolicy: add queue_pages_node_check()

[Anshuman Khandual]

On 04/21/2017 02:17 AM, Zi Yan wrote:
> From: Naoya Horiguchi 
> 
> Introduce a separate check routine related to MPOL_MF_INVERT flag.
> This patch just does cleanup, no behavioral change.

Can you please send it separately first, this should be debated
and merged quickly and not hang on to the series if we have to
respin again.

Reviewed-by: Anshuman Khandual 

[PATCH] staging : rtl8188eu : remove void function return

[surenderpolsani]

kernel coding style doesn't allow the return statement
in void function.

Signed-off-by: Surenderp 
---
Changes for v2:
corrected subject line as suggested
Changes for v3:
modified from line as suggested by Greg KH
placed a semicolon in label for fixing build error
---
 drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
index d04b7fb..428996e 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
@@ -165,7 +165,7 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter)
 skip_dm:
/*  Check GPIO to determine current RF on/off and Pbc status. */
/*  Check Hardware Radio ON/OFF or not */
-   return;
+   ;
 }
 
 void rtw_hal_dm_init(struct adapter *Adapter)
-- 
1.9.1

[PATCH] staging : rtl8188eu : remove void function return

[surenderpolsani]

kernel coding style doesn't allow the return statement
in void function.

Signed-off-by: Surenderp 
---
Changes for v2:
corrected subject line as suggested
Changes for v3:
modified from line as suggested by Greg KH
placed a semicolon in label for fixing build error
---
 drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
index d04b7fb..428996e 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
@@ -165,7 +165,7 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter)
 skip_dm:
/*  Check GPIO to determine current RF on/off and Pbc status. */
/*  Check Hardware Radio ON/OFF or not */
-   return;
+   ;
 }
 
 void rtw_hal_dm_init(struct adapter *Adapter)
-- 
1.9.1

Re: [PATCH v6 1/6] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

[Chen-Yu Tsai]

On Thu, Apr 20, 2017 at 11:58 PM, Rob Herring  wrote:
> On Tue, Apr 18, 2017 at 09:34:16AM +0200, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz 
>> Acked-by: Chen-Yu Tsai 
>> Acked-by: Maxime Ripard 
>> ---
>> v6:
>>   - removed mention to monitored-battery, will be sent when the battery
>>   framework has been merged,
>>
>> v5:
>>   - removed DT property example from monitored-battery,
>>
>> v4:
>>  - added monitored-battery optional property,
>>  - added example with battery,
>>
>> v3:
>>  - removed constant charge current property, now should use the WIP
>>  battery framework,
>>
>> v2:
>>  - changed DT node name from ac_power_supply to ac-power-supply,
>>  - removed io-channels and io-channel-names from DT (the IIO mapping is
>>  done in the IIO ADC driver now),
>>  - added x-powers,constant-charge-current property to set the maximal
>>  default constant current charge of the battery,
>>
>>  .../bindings/power/supply/axp20x_battery.txt | 20 
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> Acked-by: Rob Herring 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v6 1/6] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

[Chen-Yu Tsai]

On Thu, Apr 20, 2017 at 11:58 PM, Rob Herring  wrote:
> On Tue, Apr 18, 2017 at 09:34:16AM +0200, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz 
>> Acked-by: Chen-Yu Tsai 
>> Acked-by: Maxime Ripard 
>> ---
>> v6:
>>   - removed mention to monitored-battery, will be sent when the battery
>>   framework has been merged,
>>
>> v5:
>>   - removed DT property example from monitored-battery,
>>
>> v4:
>>  - added monitored-battery optional property,
>>  - added example with battery,
>>
>> v3:
>>  - removed constant charge current property, now should use the WIP
>>  battery framework,
>>
>> v2:
>>  - changed DT node name from ac_power_supply to ac-power-supply,
>>  - removed io-channels and io-channel-names from DT (the IIO mapping is
>>  done in the IIO ADC driver now),
>>  - added x-powers,constant-charge-current property to set the maximal
>>  default constant current charge of the battery,
>>
>>  .../bindings/power/supply/axp20x_battery.txt | 20 
>> 
>>  1 file changed, 20 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> Acked-by: Rob Herring 

Acked-by: Chen-Yu Tsai 

[PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

From: Orson Zhai 

SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.

According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.

Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
Reviewed-by: Mathieu Poirier 
---
 arch/arm64/boot/dts/sprd/Makefile |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi  | 569 ++
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi  |  71 
 4 files changed, 698 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+   sp9860g-1h10.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 000..7b7d8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+#include "whale2.dtsi"
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   CPU0: cpu@53 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x53>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU1: cpu@530001 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530001>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU2: cpu@530002 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530002>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU3: cpu@530003 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530003>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU4: cpu@530100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530100>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU5: cpu@530101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530101>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU6: cpu@530102 {
+   device_type = "cpu";
+ 

[PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

From: Orson Zhai 

SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.

According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.

Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
Reviewed-by: Mathieu Poirier 
---
 arch/arm64/boot/dts/sprd/Makefile |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi  | 569 ++
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi  |  71 
 4 files changed, 698 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+   sp9860g-1h10.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 000..7b7d8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+#include "whale2.dtsi"
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   CPU0: cpu@53 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x53>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU1: cpu@530001 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530001>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU2: cpu@530002 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530002>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU3: cpu@530003 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530003>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU4: cpu@530100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530100>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU5: cpu@530101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530101>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU6: cpu@530102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530102>;

[PATCH 1/2] dax: prevent invalidation of mapped DAX entries

[Ross Zwisler]

dax_invalidate_mapping_entry() currently removes DAX exceptional entries
only if they are clean and unlocked.  This is done via:

invalidate_mapping_pages()
  invalidate_exceptional_entry()
dax_invalidate_mapping_entry()

However, for page cache pages removed in invalidate_mapping_pages() there
is an additional criteria which is that the page must not be mapped.  This
is noted in the comments above invalidate_mapping_pages() and is checked in
invalidate_inode_page().

For DAX entries this means that we can can end up in a situation where a
DAX exceptional entry, either a huge zero page or a regular DAX entry,
could end up mapped but without an associated radix tree entry. This is
inconsistent with the rest of the DAX code and with what happens in the
page cache case.

We aren't able to unmap the DAX exceptional entry because according to its
comments invalidate_mapping_pages() isn't allowed to block, and
unmap_mapping_range() takes a write lock on the mapping->i_mmap_rwsem.

Since we essentially never have unmapped DAX entries to evict from the
radix tree, just remove dax_invalidate_mapping_entry().

Signed-off-by: Ross Zwisler 
Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if 
appropriate")
Reported-by: Jan Kara 
Cc: [4.10+]
---

This series applies cleanly to the current v4.11-rc7 based linux/master,
and has passed an xfstests run with DAX on ext4 and XFS.

These patches also apply to v4.10.9 with a little work from the 3-way
merge feature.

 fs/dax.c| 29 -
 include/linux/dax.h |  1 -
 mm/truncate.c   |  9 +++--
 3 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 85abd74..166504c 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -507,35 +507,6 @@ int dax_delete_mapping_entry(struct address_space 
*mapping, pgoff_t index)
 }
 
 /*
- * Invalidate exceptional DAX entry if easily possible. This handles DAX
- * entries for invalidate_inode_pages() so we evict the entry only if we can
- * do so without blocking.
- */
-int dax_invalidate_mapping_entry(struct address_space *mapping, pgoff_t index)
-{
-   int ret = 0;
-   void *entry, **slot;
-   struct radix_tree_root *page_tree = >page_tree;
-
-   spin_lock_irq(>tree_lock);
-   entry = __radix_tree_lookup(page_tree, index, NULL, );
-   if (!entry || !radix_tree_exceptional_entry(entry) ||
-   slot_locked(mapping, slot))
-   goto out;
-   if (radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_DIRTY) ||
-   radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_TOWRITE))
-   goto out;
-   radix_tree_delete(page_tree, index);
-   mapping->nrexceptional--;
-   ret = 1;
-out:
-   spin_unlock_irq(>tree_lock);
-   if (ret)
-   dax_wake_mapping_entry_waiter(mapping, index, entry, true);
-   return ret;
-}
-
-/*
  * Invalidate exceptional DAX entry if it is clean.
  */
 int dax_invalidate_mapping_entry_sync(struct address_space *mapping,
diff --git a/include/linux/dax.h b/include/linux/dax.h
index d8a3dc0..f8e1833 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -41,7 +41,6 @@ ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter 
*iter,
 int dax_iomap_fault(struct vm_fault *vmf, enum page_entry_size pe_size,
const struct iomap_ops *ops);
 int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index);
-int dax_invalidate_mapping_entry(struct address_space *mapping, pgoff_t index);
 int dax_invalidate_mapping_entry_sync(struct address_space *mapping,
  pgoff_t index);
 void dax_wake_mapping_entry_waiter(struct address_space *mapping,
diff --git a/mm/truncate.c b/mm/truncate.c
index 6263aff..c537184 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -67,17 +67,14 @@ static void truncate_exceptional_entry(struct address_space 
*mapping,
 
 /*
  * Invalidate exceptional entry if easily possible. This handles exceptional
- * entries for invalidate_inode_pages() so for DAX it evicts only unlocked and
- * clean entries.
+ * entries for invalidate_inode_pages().
  */
 static int invalidate_exceptional_entry(struct address_space *mapping,
pgoff_t index, void *entry)
 {
-   /* Handled by shmem itself */
-   if (shmem_mapping(mapping))
+   /* Handled by shmem itself, or for DAX we do nothing. */
+   if (shmem_mapping(mapping) || dax_mapping(mapping))
return 1;
-   if (dax_mapping(mapping))
-   return dax_invalidate_mapping_entry(mapping, index);
clear_shadow_entry(mapping, index, entry);
return 1;
 }
-- 
2.9.3

[PATCH 1/2] dax: prevent invalidation of mapped DAX entries

[Ross Zwisler]

dax_invalidate_mapping_entry() currently removes DAX exceptional entries
only if they are clean and unlocked.  This is done via:

invalidate_mapping_pages()
  invalidate_exceptional_entry()
dax_invalidate_mapping_entry()

However, for page cache pages removed in invalidate_mapping_pages() there
is an additional criteria which is that the page must not be mapped.  This
is noted in the comments above invalidate_mapping_pages() and is checked in
invalidate_inode_page().

For DAX entries this means that we can can end up in a situation where a
DAX exceptional entry, either a huge zero page or a regular DAX entry,
could end up mapped but without an associated radix tree entry. This is
inconsistent with the rest of the DAX code and with what happens in the
page cache case.

We aren't able to unmap the DAX exceptional entry because according to its
comments invalidate_mapping_pages() isn't allowed to block, and
unmap_mapping_range() takes a write lock on the mapping->i_mmap_rwsem.

Since we essentially never have unmapped DAX entries to evict from the
radix tree, just remove dax_invalidate_mapping_entry().

Signed-off-by: Ross Zwisler 
Fixes: c6dcf52c23d2 ("mm: Invalidate DAX radix tree entries only if 
appropriate")
Reported-by: Jan Kara 
Cc: [4.10+]
---

This series applies cleanly to the current v4.11-rc7 based linux/master,
and has passed an xfstests run with DAX on ext4 and XFS.

These patches also apply to v4.10.9 with a little work from the 3-way
merge feature.

 fs/dax.c| 29 -
 include/linux/dax.h |  1 -
 mm/truncate.c   |  9 +++--
 3 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 85abd74..166504c 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -507,35 +507,6 @@ int dax_delete_mapping_entry(struct address_space 
*mapping, pgoff_t index)
 }
 
 /*
- * Invalidate exceptional DAX entry if easily possible. This handles DAX
- * entries for invalidate_inode_pages() so we evict the entry only if we can
- * do so without blocking.
- */
-int dax_invalidate_mapping_entry(struct address_space *mapping, pgoff_t index)
-{
-   int ret = 0;
-   void *entry, **slot;
-   struct radix_tree_root *page_tree = >page_tree;
-
-   spin_lock_irq(>tree_lock);
-   entry = __radix_tree_lookup(page_tree, index, NULL, );
-   if (!entry || !radix_tree_exceptional_entry(entry) ||
-   slot_locked(mapping, slot))
-   goto out;
-   if (radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_DIRTY) ||
-   radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_TOWRITE))
-   goto out;
-   radix_tree_delete(page_tree, index);
-   mapping->nrexceptional--;
-   ret = 1;
-out:
-   spin_unlock_irq(>tree_lock);
-   if (ret)
-   dax_wake_mapping_entry_waiter(mapping, index, entry, true);
-   return ret;
-}
-
-/*
  * Invalidate exceptional DAX entry if it is clean.
  */
 int dax_invalidate_mapping_entry_sync(struct address_space *mapping,
diff --git a/include/linux/dax.h b/include/linux/dax.h
index d8a3dc0..f8e1833 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -41,7 +41,6 @@ ssize_t dax_iomap_rw(struct kiocb *iocb, struct iov_iter 
*iter,
 int dax_iomap_fault(struct vm_fault *vmf, enum page_entry_size pe_size,
const struct iomap_ops *ops);
 int dax_delete_mapping_entry(struct address_space *mapping, pgoff_t index);
-int dax_invalidate_mapping_entry(struct address_space *mapping, pgoff_t index);
 int dax_invalidate_mapping_entry_sync(struct address_space *mapping,
  pgoff_t index);
 void dax_wake_mapping_entry_waiter(struct address_space *mapping,
diff --git a/mm/truncate.c b/mm/truncate.c
index 6263aff..c537184 100644
--- a/mm/truncate.c
+++ b/mm/truncate.c
@@ -67,17 +67,14 @@ static void truncate_exceptional_entry(struct address_space 
*mapping,
 
 /*
  * Invalidate exceptional entry if easily possible. This handles exceptional
- * entries for invalidate_inode_pages() so for DAX it evicts only unlocked and
- * clean entries.
+ * entries for invalidate_inode_pages().
  */
 static int invalidate_exceptional_entry(struct address_space *mapping,
pgoff_t index, void *entry)
 {
-   /* Handled by shmem itself */
-   if (shmem_mapping(mapping))
+   /* Handled by shmem itself, or for DAX we do nothing. */
+   if (shmem_mapping(mapping) || dax_mapping(mapping))
return 1;
-   if (dax_mapping(mapping))
-   return dax_invalidate_mapping_entry(mapping, index);
clear_shadow_entry(mapping, index, entry);
return 1;
 }
-- 
2.9.3