Re: Microchip USB Hub Driver Harmonization

[Richard Leitner]

On 05/17/2017 06:01 PM, Krzysztof Kozlowski wrote:

On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:

...

1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
usb4604 uses i2c_master_* functions for the hub configuration. What
would be the preferred solution?


regmap? It is already widely used for I2C drivers. I think most (or even
all?) new I2C drivers use regmap. It hides the real bus between common
regmap API.


Ok. Thanks for that information. Then I will go for regmap.




2. What would be a good prefix for common headers/functions/macros/etc.?
I thought of "mcusbhub"... Would that be OK? Or are there any
conventions/better proposals on that?


If you are going to develop one driver for entire family, then you could
even choose just one name. Let's say the most generic.

I don't quite understand the meaning behind "harmonizing drivers".


I'm currently evaluating if it is feasible to create one common driver 
for all USB hubs. Due to the fact there are currently only 3 hub 
types implemented mainline (the Microchip homepage lists 36 USB Hub 
products [1]) it involves quite a lot data-sheet reading ;-)


As a first step (and also the final one if implementing a common driver 
is not feasible) I thought of creating a common header/source file which 
implements all "re-useable" functions/macros/etc. Would that also be an 
accepted solution?





3. Currently only usb3503 supports "platform data". Is this still needed
or may it be removed?


I think it is still used, e.g. by:
arch/arm/boot/dts/exynos5250-spring.dts


Please correct me if I'm wrong, but isn't that DT only?

The reason why I'm asking if it may be removed is because the only file 
including "linux/platform_data/usb3503.h" is the usb3503.c driver itself 
and it's also the only file using "struct usb3503_platform_data".


Thanks & kind regards,
RichardL

[1] 
https://www.microchip.com/design-centers/usb/usb-hubs-and-devices/products/overview

Re: Microchip USB Hub Driver Harmonization

[Richard Leitner]

On 05/17/2017 06:01 PM, Krzysztof Kozlowski wrote:

On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:

...

1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
usb4604 uses i2c_master_* functions for the hub configuration. What
would be the preferred solution?


regmap? It is already widely used for I2C drivers. I think most (or even
all?) new I2C drivers use regmap. It hides the real bus between common
regmap API.


Ok. Thanks for that information. Then I will go for regmap.




2. What would be a good prefix for common headers/functions/macros/etc.?
I thought of "mcusbhub"... Would that be OK? Or are there any
conventions/better proposals on that?


If you are going to develop one driver for entire family, then you could
even choose just one name. Let's say the most generic.

I don't quite understand the meaning behind "harmonizing drivers".


I'm currently evaluating if it is feasible to create one common driver 
for all USB hubs. Due to the fact there are currently only 3 hub 
types implemented mainline (the Microchip homepage lists 36 USB Hub 
products [1]) it involves quite a lot data-sheet reading ;-)


As a first step (and also the final one if implementing a common driver 
is not feasible) I thought of creating a common header/source file which 
implements all "re-useable" functions/macros/etc. Would that also be an 
accepted solution?





3. Currently only usb3503 supports "platform data". Is this still needed
or may it be removed?


I think it is still used, e.g. by:
arch/arm/boot/dts/exynos5250-spring.dts


Please correct me if I'm wrong, but isn't that DT only?

The reason why I'm asking if it may be removed is because the only file 
including "linux/platform_data/usb3503.h" is the usb3503.c driver itself 
and it's also the only file using "struct usb3503_platform_data".


Thanks & kind regards,
RichardL

[1] 
https://www.microchip.com/design-centers/usb/usb-hubs-and-devices/products/overview

Re: [net-intel-i40e] question about assignment overwrite

[Jeff Kirsher]

On Wed, 2017-05-17 at 15:48 -0500, Gustavo A. R. Silva wrote:
> While looking into Coverity ID 1408956 I ran into the following
> piece  
> of code at drivers/net/ethernet/intel/i40e/i40e_main.c:8807:
> 
> 8807    if (pf->hw.mac.type == I40E_MAC_X722) {
> 8808    pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE
> 8809 | I40E_FLAG_128_QP_RSS_CAPABLE
> 8810 | I40E_FLAG_HW_ATR_EVICT_CAPABLE
> 8811 | I40E_FLAG_OUTER_UDP_CSUM_CAPABLE
> 8812 | I40E_FLAG_WB_ON_ITR_CAPABLE
> 8813 |
> I40E_FLAG_MULTIPLE_TCP_UDP_RSS_PCTYPE
> 8814 | I40E_FLAG_NO_PCI_LINK_CHECK
> 8815 | I40E_FLAG_USE_SET_LLDP_MIB
> 8816 | I40E_FLAG_GENEVE_OFFLOAD_CAPABLE
> 8817 | I40E_FLAG_PTP_L4_CAPABLE
> 8818 | I40E_FLAG_WOL_MC_MAGIC_PKT_WAKE;
> 8819    } else if ((pf->hw.aq.api_maj_ver > 1) ||
> 8820   ((pf->hw.aq.api_maj_ver == 1) &&
> 8821    (pf->hw.aq.api_min_ver > 4))) {
> 8822    /* Supported in FW API version higher than 1.4 */
> 8823    pf->flags |= I40E_FLAG_GENEVE_OFFLOAD_CAPABLE;
> 8824    pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> 8825    } else {
> 8826    pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> 8827    }
> 
> The issue here is that the assignment at line 8823 is overwritten
> by  
> the code at line 8824.
> 
> I'm suspicious that line 8824 should be remove and a patch like the  
> following can be applied:
> 
> index d5c9c9e..48ffa73 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -8821,7 +8821,6 @@ static int i40e_sw_init(struct i40e_pf *pf)
>  (pf->hw.aq.api_min_ver > 4))) {
>  /* Supported in FW API version higher than 1.4 */
>  pf->flags |= I40E_FLAG_GENEVE_OFFLOAD_CAPABLE;
> -   pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
>  } else {
>  pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
>  }
> 
> What do you think?

This issue is already fixed in my dev-queue branch on my next-queue
tree.

signature.asc
Description: This is a digitally signed message part

Re: [net-intel-i40e] question about assignment overwrite

[Jeff Kirsher]

On Wed, 2017-05-17 at 15:48 -0500, Gustavo A. R. Silva wrote:
> While looking into Coverity ID 1408956 I ran into the following
> piece  
> of code at drivers/net/ethernet/intel/i40e/i40e_main.c:8807:
> 
> 8807    if (pf->hw.mac.type == I40E_MAC_X722) {
> 8808    pf->flags |= I40E_FLAG_RSS_AQ_CAPABLE
> 8809 | I40E_FLAG_128_QP_RSS_CAPABLE
> 8810 | I40E_FLAG_HW_ATR_EVICT_CAPABLE
> 8811 | I40E_FLAG_OUTER_UDP_CSUM_CAPABLE
> 8812 | I40E_FLAG_WB_ON_ITR_CAPABLE
> 8813 |
> I40E_FLAG_MULTIPLE_TCP_UDP_RSS_PCTYPE
> 8814 | I40E_FLAG_NO_PCI_LINK_CHECK
> 8815 | I40E_FLAG_USE_SET_LLDP_MIB
> 8816 | I40E_FLAG_GENEVE_OFFLOAD_CAPABLE
> 8817 | I40E_FLAG_PTP_L4_CAPABLE
> 8818 | I40E_FLAG_WOL_MC_MAGIC_PKT_WAKE;
> 8819    } else if ((pf->hw.aq.api_maj_ver > 1) ||
> 8820   ((pf->hw.aq.api_maj_ver == 1) &&
> 8821    (pf->hw.aq.api_min_ver > 4))) {
> 8822    /* Supported in FW API version higher than 1.4 */
> 8823    pf->flags |= I40E_FLAG_GENEVE_OFFLOAD_CAPABLE;
> 8824    pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> 8825    } else {
> 8826    pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
> 8827    }
> 
> The issue here is that the assignment at line 8823 is overwritten
> by  
> the code at line 8824.
> 
> I'm suspicious that line 8824 should be remove and a patch like the  
> following can be applied:
> 
> index d5c9c9e..48ffa73 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -8821,7 +8821,6 @@ static int i40e_sw_init(struct i40e_pf *pf)
>  (pf->hw.aq.api_min_ver > 4))) {
>  /* Supported in FW API version higher than 1.4 */
>  pf->flags |= I40E_FLAG_GENEVE_OFFLOAD_CAPABLE;
> -   pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
>  } else {
>  pf->flags = I40E_FLAG_HW_ATR_EVICT_CAPABLE;
>  }
> 
> What do you think?

This issue is already fixed in my dev-queue branch on my next-queue
tree.

signature.asc
Description: This is a digitally signed message part

[PATCH v1] drivers/staging/ccree: fix coding style issues

[Dhiru Kholia]

This patch fixes the "please, no space before tabs" warnings emitted by
checkpatch.pl script.

Signed-off-by: Dhiru Kholia 
---
 drivers/staging/ccree/cc_crypto_ctx.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 216d247..ac39d34 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -54,13 +54,13 @@
 #define CC_AES_KEY_SIZE_MAXCC_AES_256_BIT_KEY_SIZE
 #define CC_AES_KEY_SIZE_WORDS_MAX  (CC_AES_KEY_SIZE_MAX >> 2)
 
-#define CC_MD5_DIGEST_SIZE 16
-#define CC_SHA1_DIGEST_SIZE20
-#define CC_SHA224_DIGEST_SIZE  28
-#define CC_SHA256_DIGEST_SIZE  32
+#define CC_MD5_DIGEST_SIZE 16
+#define CC_SHA1_DIGEST_SIZE20
+#define CC_SHA224_DIGEST_SIZE  28
+#define CC_SHA256_DIGEST_SIZE  32
 #define CC_SHA256_DIGEST_SIZE_IN_WORDS 8
-#define CC_SHA384_DIGEST_SIZE  48
-#define CC_SHA512_DIGEST_SIZE  64
+#define CC_SHA384_DIGEST_SIZE  48
+#define CC_SHA512_DIGEST_SIZE  64
 
 #define CC_SHA1_BLOCK_SIZE 64
 #define CC_SHA1_BLOCK_SIZE_IN_WORDS 16
@@ -83,9 +83,9 @@
 
 #define CC_HMAC_BLOCK_SIZE_MAX CC_HASH_BLOCK_SIZE_MAX
 
-#define CC_MULTI2_SYSTEM_KEY_SIZE  32
-#define CC_MULTI2_DATA_KEY_SIZE8
-#define CC_MULTI2_SYSTEM_N_DATA_KEY_SIZE   (CC_MULTI2_SYSTEM_KEY_SIZE + 
CC_MULTI2_DATA_KEY_SIZE)
+#define CC_MULTI2_SYSTEM_KEY_SIZE  32
+#define CC_MULTI2_DATA_KEY_SIZE8
+#define CC_MULTI2_SYSTEM_N_DATA_KEY_SIZE   (CC_MULTI2_SYSTEM_KEY_SIZE + 
CC_MULTI2_DATA_KEY_SIZE)
 #defineCC_MULTI2_BLOCK_SIZE8
 #defineCC_MULTI2_IV_SIZE   8
 #defineCC_MULTI2_MIN_NUM_ROUNDS8
-- 
2.7.4

[PATCH v1] drivers/staging/ccree: fix coding style issues

[Dhiru Kholia]

This patch fixes the "please, no space before tabs" warnings emitted by
checkpatch.pl script.

Signed-off-by: Dhiru Kholia 
---
 drivers/staging/ccree/cc_crypto_ctx.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 216d247..ac39d34 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -54,13 +54,13 @@
 #define CC_AES_KEY_SIZE_MAXCC_AES_256_BIT_KEY_SIZE
 #define CC_AES_KEY_SIZE_WORDS_MAX  (CC_AES_KEY_SIZE_MAX >> 2)
 
-#define CC_MD5_DIGEST_SIZE 16
-#define CC_SHA1_DIGEST_SIZE20
-#define CC_SHA224_DIGEST_SIZE  28
-#define CC_SHA256_DIGEST_SIZE  32
+#define CC_MD5_DIGEST_SIZE 16
+#define CC_SHA1_DIGEST_SIZE20
+#define CC_SHA224_DIGEST_SIZE  28
+#define CC_SHA256_DIGEST_SIZE  32
 #define CC_SHA256_DIGEST_SIZE_IN_WORDS 8
-#define CC_SHA384_DIGEST_SIZE  48
-#define CC_SHA512_DIGEST_SIZE  64
+#define CC_SHA384_DIGEST_SIZE  48
+#define CC_SHA512_DIGEST_SIZE  64
 
 #define CC_SHA1_BLOCK_SIZE 64
 #define CC_SHA1_BLOCK_SIZE_IN_WORDS 16
@@ -83,9 +83,9 @@
 
 #define CC_HMAC_BLOCK_SIZE_MAX CC_HASH_BLOCK_SIZE_MAX
 
-#define CC_MULTI2_SYSTEM_KEY_SIZE  32
-#define CC_MULTI2_DATA_KEY_SIZE8
-#define CC_MULTI2_SYSTEM_N_DATA_KEY_SIZE   (CC_MULTI2_SYSTEM_KEY_SIZE + 
CC_MULTI2_DATA_KEY_SIZE)
+#define CC_MULTI2_SYSTEM_KEY_SIZE  32
+#define CC_MULTI2_DATA_KEY_SIZE8
+#define CC_MULTI2_SYSTEM_N_DATA_KEY_SIZE   (CC_MULTI2_SYSTEM_KEY_SIZE + 
CC_MULTI2_DATA_KEY_SIZE)
 #defineCC_MULTI2_BLOCK_SIZE8
 #defineCC_MULTI2_IV_SIZE   8
 #defineCC_MULTI2_MIN_NUM_ROUNDS8
-- 
2.7.4

Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

[Baoquan He]

On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used for ARM64.
> 
> Signed-off-by: Bharat Bhushan 
> ---
>  Documentation/kdump/kdump.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 615434d..522ce13 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
>  2) Or use the system kernel binary itself as dump-capture kernel and there is
> no need to build a separate dump-capture kernel. This is possible
> only with the architectures which support a relocatable kernel. As
> -   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
> relocatable
> -   kernel.
> +   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
> +   relocatable kernel.
>  
>  Building a relocatable kernel is advantageous from the point of view that
>  one does not have to build a second kernel for capturing the dump. But
> @@ -361,6 +361,12 @@ to load dump-capture kernel.
> --dtb= \
> --append="root= "
>  
> +If you are using a uncompressed Image, then use following command
~ an
> +to load dump-capture kernel.
> +
> +   kexec -p  \
> +   --initrd= \
> +   --append="root= "
>  
>  Please note, that --args-linux does not need to be specified for ia64.
>  It is planned to make this a no-op on that architecture, but for now
> -- 
> 1.9.3
> 

Re: [PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

[Baoquan He]

On 05/18/17 at 11:03am, Bharat Bhushan wrote:
> This patch have minor updates in Documentation for arm64i as
> relocatable kernel.
> Also this patch updates documentation for using uncompressed
> image "Image" which is used for ARM64.
> 
> Signed-off-by: Bharat Bhushan 
> ---
>  Documentation/kdump/kdump.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index 615434d..522ce13 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
>  2) Or use the system kernel binary itself as dump-capture kernel and there is
> no need to build a separate dump-capture kernel. This is possible
> only with the architectures which support a relocatable kernel. As
> -   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
> relocatable
> -   kernel.
> +   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
> +   relocatable kernel.
>  
>  Building a relocatable kernel is advantageous from the point of view that
>  one does not have to build a second kernel for capturing the dump. But
> @@ -361,6 +361,12 @@ to load dump-capture kernel.
> --dtb= \
> --append="root= "
>  
> +If you are using a uncompressed Image, then use following command
~ an
> +to load dump-capture kernel.
> +
> +   kexec -p  \
> +   --initrd= \
> +   --append="root= "
>  
>  Please note, that --args-linux does not need to be specified for ia64.
>  It is planned to make this a no-op on that architecture, but for now
> -- 
> 1.9.3
> 

Re: [PATCH v1 2/2] hw_random: timeriomem_rng: Allow setting RNG quality from platform data

[PrasannaKumar Muralidharan]

Hi Rick,

Minor comment below.

On 18 May 2017 at 03:59, Rick Altherr  wrote:
> When a hw_random device's quality is non-zero, it will automatically be
> used to fill the kernel's entropy pool.  Since timeriomem_rng is used by
> many different devices, the quality needs to be provided by platform
> data or device tree.
>
> Signed-off-by: Rick Altherr 
> ---
>
>  drivers/char/hw_random/timeriomem-rng.c | 7 +++
>  include/linux/timeriomem-rng.h  | 3 +++
>  2 files changed, 10 insertions(+)
>
> diff --git a/drivers/char/hw_random/timeriomem-rng.c 
> b/drivers/char/hw_random/timeriomem-rng.c
> index a0faa5f05deb..03ff5483d865 100644
> --- a/drivers/char/hw_random/timeriomem-rng.c
> +++ b/drivers/char/hw_random/timeriomem-rng.c
> @@ -151,8 +151,15 @@ static int timeriomem_rng_probe(struct platform_device 
> *pdev)
> dev_err(>dev, "missing period\n");
> return -EINVAL;
> }
> +
> +   if (!of_property_read_u32(pdev->dev.of_node,
> +   "quality", ))
> +   priv->rng_ops.quality = i;
> +   else
> +   priv->rng_ops.quality = 0;
> } else {
> period = pdata->period;
> +   priv->rng_ops.quality = pdata->quality;
> }
>
> priv->period = ns_to_ktime(period * NSEC_PER_USEC);
> diff --git a/include/linux/timeriomem-rng.h b/include/linux/timeriomem-rng.h
> index 46eb27ddbfab..320f743bf06b 100644
> --- a/include/linux/timeriomem-rng.h
> +++ b/include/linux/timeriomem-rng.h
> @@ -13,4 +13,7 @@ struct timeriomem_rng_data {
>
> /* measures in usecs */
> unsigned intperiod;
> +
> +   /* bits of entropy per 1000 bits read */

Your dt-bindings patch says 'entropy per 1024 bits'. Please be consistent.

> +   unsigned intquality;
>  };
> --
> 2.13.0.303.g4ebf302169-goog
>

Regards,
PrasannaKumar

Re: [PATCH v1 2/2] hw_random: timeriomem_rng: Allow setting RNG quality from platform data

[PrasannaKumar Muralidharan]

Hi Rick,

Minor comment below.

On 18 May 2017 at 03:59, Rick Altherr  wrote:
> When a hw_random device's quality is non-zero, it will automatically be
> used to fill the kernel's entropy pool.  Since timeriomem_rng is used by
> many different devices, the quality needs to be provided by platform
> data or device tree.
>
> Signed-off-by: Rick Altherr 
> ---
>
>  drivers/char/hw_random/timeriomem-rng.c | 7 +++
>  include/linux/timeriomem-rng.h  | 3 +++
>  2 files changed, 10 insertions(+)
>
> diff --git a/drivers/char/hw_random/timeriomem-rng.c 
> b/drivers/char/hw_random/timeriomem-rng.c
> index a0faa5f05deb..03ff5483d865 100644
> --- a/drivers/char/hw_random/timeriomem-rng.c
> +++ b/drivers/char/hw_random/timeriomem-rng.c
> @@ -151,8 +151,15 @@ static int timeriomem_rng_probe(struct platform_device 
> *pdev)
> dev_err(>dev, "missing period\n");
> return -EINVAL;
> }
> +
> +   if (!of_property_read_u32(pdev->dev.of_node,
> +   "quality", ))
> +   priv->rng_ops.quality = i;
> +   else
> +   priv->rng_ops.quality = 0;
> } else {
> period = pdata->period;
> +   priv->rng_ops.quality = pdata->quality;
> }
>
> priv->period = ns_to_ktime(period * NSEC_PER_USEC);
> diff --git a/include/linux/timeriomem-rng.h b/include/linux/timeriomem-rng.h
> index 46eb27ddbfab..320f743bf06b 100644
> --- a/include/linux/timeriomem-rng.h
> +++ b/include/linux/timeriomem-rng.h
> @@ -13,4 +13,7 @@ struct timeriomem_rng_data {
>
> /* measures in usecs */
> unsigned intperiod;
> +
> +   /* bits of entropy per 1000 bits read */

Your dt-bindings patch says 'entropy per 1024 bits'. Please be consistent.

> +   unsigned intquality;
>  };
> --
> 2.13.0.303.g4ebf302169-goog
>

Regards,
PrasannaKumar

Re: [PATCH v2 00/29] gpu/drm: remove -Iinclude/drm compiler flags from Makefile

[Daniel Vetter]

On Mon, Apr 24, 2017 at 01:50:18PM +0900, Masahiro Yamada wrote:
> Many Makefiles needed to add -Iinclude/drm as an include path,
> but the right thing to do is to include headers in the form
>   #include 
> 
> This series fixes the source files, then rip off -Iinclude/drm flags.
> 
> 
> Masahiro Yamada (29):
>   drm: make drm_panel.h self-contained
>   drm/ttm: fix include notation and remove -Iinclude/drm flag
>   drm/amd: fix include notation and remove -Iinclude/drm flag
>   drm/ast: fix include notation and remove -Iinclude/drm flag
>   drm/bochs: fix include notation and remove -Iinclude/drm flag
>   drm/bridge: fix include notation and remove -Iinclude/drm flag
>   drm/cirrus: fix include notation and remove -Iinclude/drm flag
>   drm/hisilicon: fix include notation and remove -Iinclude/drm flag
>   drm/mgag200: fix include notation and remove -Iinclude/drm flag
>   drm/msm: fix include notation and remove -Iinclude/drm flag
>   drm/nouveau: fix include notation and remove -Iinclude/drm flag
>   drm/qxl: fix include notation and remove -Iinclude/drm flag
>   drm/radeon: fix include notation and remove -Iinclude/drm flag
>   drm/tilcdc: fix include notation and remove -Iinclude/drm flag
>   drm/vc4: fix include notation and remove -Iinclude/drm flag
>   drm/virtio: fix include notation and remove -Iinclude/drm flag
>   drm/vmwgfx: fix include notation and remove -Iinclude/drm flag
>   drm/gma500: remove unneeded -Iinclude/drm compiler flag
>   drm/i810: remove unneeded -Iinclude/drm compiler flag
>   drm/i2c: remove unneeded -Iinclude/drm compiler flag
>   drm/mga: remove unneeded -Iinclude/drm compiler flag
>   drm/omap: remove unneeded -Iinclude/drm compiler flag
>   drm/r128: remove unneeded -Iinclude/drm compiler flag
>   drm/savage: remove unneeded -Iinclude/drm compiler flag
>   drm/sis: remove unneeded -Iinclude/drm compiler flag
>   drm/tdfx: remove unneeded -Iinclude/drm compiler flag
>   drm/udl: remove unneeded -Iinclude/drm compiler flag
>   drm/vgem: remove unneeded -Iinclude/drm compiler flag
>   drm/via: remove unneeded -Iinclude/drm compiler flag

Ok, I think I merged them all except the vc4 one. Can you please
rebase that one?

Thanks, Daniel

> 
>  drivers/gpu/drm/amd/amdgpu/Makefile  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 10 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 10 -
>  drivers/gpu/drm/amd/amdgpu/ci_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/ci_smc.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/cik.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/cik_ih.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/cz_ih.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/iceland_ih.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/kv_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/kv_smc.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/psp_v3_1.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/si.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/si_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/si_ih.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/si_smc.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/soc15.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/tonga_ih.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/vega10_ih.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/vi.c  |  2 +-
>  drivers/gpu/drm/amd/amdkfd/Makefile  |  2 +-
>  drivers/gpu/drm/amd/powerplay/Makefile   |  2 +-
>  drivers/gpu/drm/ast/Makefile |  2 --
>  drivers/gpu/drm/ast/ast_ttm.c|  3 ++-
>  drivers/gpu/drm/bochs/Makefile   |  1 -
>  drivers/gpu/drm/bochs/bochs.h|  4 ++--
>  drivers/gpu/drm/bridge/Makefile  |  2 --
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 12 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 10 -
>  drivers/gpu/drm/cirrus/Makefile  |  1 -
>  drivers/gpu/drm/cirrus/cirrus_ttm.c  |  3 ++-
>  drivers/gpu/drm/gma500/Makefile  |  1 -

Re: [PATCH v2 00/29] gpu/drm: remove -Iinclude/drm compiler flags from Makefile

[Daniel Vetter]

On Mon, Apr 24, 2017 at 01:50:18PM +0900, Masahiro Yamada wrote:
> Many Makefiles needed to add -Iinclude/drm as an include path,
> but the right thing to do is to include headers in the form
>   #include 
> 
> This series fixes the source files, then rip off -Iinclude/drm flags.
> 
> 
> Masahiro Yamada (29):
>   drm: make drm_panel.h self-contained
>   drm/ttm: fix include notation and remove -Iinclude/drm flag
>   drm/amd: fix include notation and remove -Iinclude/drm flag
>   drm/ast: fix include notation and remove -Iinclude/drm flag
>   drm/bochs: fix include notation and remove -Iinclude/drm flag
>   drm/bridge: fix include notation and remove -Iinclude/drm flag
>   drm/cirrus: fix include notation and remove -Iinclude/drm flag
>   drm/hisilicon: fix include notation and remove -Iinclude/drm flag
>   drm/mgag200: fix include notation and remove -Iinclude/drm flag
>   drm/msm: fix include notation and remove -Iinclude/drm flag
>   drm/nouveau: fix include notation and remove -Iinclude/drm flag
>   drm/qxl: fix include notation and remove -Iinclude/drm flag
>   drm/radeon: fix include notation and remove -Iinclude/drm flag
>   drm/tilcdc: fix include notation and remove -Iinclude/drm flag
>   drm/vc4: fix include notation and remove -Iinclude/drm flag
>   drm/virtio: fix include notation and remove -Iinclude/drm flag
>   drm/vmwgfx: fix include notation and remove -Iinclude/drm flag
>   drm/gma500: remove unneeded -Iinclude/drm compiler flag
>   drm/i810: remove unneeded -Iinclude/drm compiler flag
>   drm/i2c: remove unneeded -Iinclude/drm compiler flag
>   drm/mga: remove unneeded -Iinclude/drm compiler flag
>   drm/omap: remove unneeded -Iinclude/drm compiler flag
>   drm/r128: remove unneeded -Iinclude/drm compiler flag
>   drm/savage: remove unneeded -Iinclude/drm compiler flag
>   drm/sis: remove unneeded -Iinclude/drm compiler flag
>   drm/tdfx: remove unneeded -Iinclude/drm compiler flag
>   drm/udl: remove unneeded -Iinclude/drm compiler flag
>   drm/vgem: remove unneeded -Iinclude/drm compiler flag
>   drm/via: remove unneeded -Iinclude/drm compiler flag

Ok, I think I merged them all except the vc4 one. Can you please
rebase that one?

Thanks, Daniel

> 
>  drivers/gpu/drm/amd/amdgpu/Makefile  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 10 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 10 -
>  drivers/gpu/drm/amd/amdgpu/ci_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/ci_smc.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/cik.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/cik_ih.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/cz_ih.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/iceland_ih.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/kv_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/kv_smc.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/psp_v3_1.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/si.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/si_dpm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/si_ih.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/si_smc.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/soc15.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/tonga_ih.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/vega10_ih.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/vi.c  |  2 +-
>  drivers/gpu/drm/amd/amdkfd/Makefile  |  2 +-
>  drivers/gpu/drm/amd/powerplay/Makefile   |  2 +-
>  drivers/gpu/drm/ast/Makefile |  2 --
>  drivers/gpu/drm/ast/ast_ttm.c|  3 ++-
>  drivers/gpu/drm/bochs/Makefile   |  1 -
>  drivers/gpu/drm/bochs/bochs.h|  4 ++--
>  drivers/gpu/drm/bridge/Makefile  |  2 --
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 12 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 10 -
>  drivers/gpu/drm/cirrus/Makefile  |  1 -
>  drivers/gpu/drm/cirrus/cirrus_ttm.c  |  3 ++-
>  drivers/gpu/drm/gma500/Makefile  |  1 -

Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

[Michael Ellerman]

Borislav Petkov  writes:

> Top-posting so that the PPC list can see the whole patch below.
>
> Since I don't know PPC, let me add PPC ML to CC for a confirmation this
> change is correct.
>
> Which brings me to the tangential: this driver is from 2006-ish and
> is for some "Marvell MV64x60 Memory Controller kernel module for PPC
> platforms". If you're going to touch it, then you should test on the PPC
> hardware too, so that you don't break the driver there.
>
> Unless that hardware is obsolete now and we don't care and, and ..?
>
> Maybe someone has some insights...

Not really sorry.

I don't have one of those boards, so I can't test. Maybe someone else on
the list does?

I'd err on the side of the PPC hardware being obsolete and no one really
caring. If the driver is helpful on ARM then we may as well use it
there, if we can also avoid breaking it on PPC then great.

cheers


> On Fri, May 12, 2017 at 04:20:02PM +1200, Chris Packham wrote:
>> To allow this driver to be used on non-powerpc platforms it needs to use
>> io accessors suitable for all platforms.
>> 
>> Signed-off-by: Chris Packham 
>> ---
>>  drivers/edac/mv64x60_edac.c | 84 
>> ++---
>>  1 file changed, 42 insertions(+), 42 deletions(-)
>> 
>> diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
>> index ddc5082f7577..102ec29f864b 100644
>> --- a/drivers/edac/mv64x60_edac.c
>> +++ b/drivers/edac/mv64x60_edac.c
>> @@ -32,21 +32,21 @@ static void mv64x60_pci_check(struct edac_pci_ctl_info 
>> *pci)
>>  struct mv64x60_pci_pdata *pdata = pci->pvt_info;
>>  u32 cause;
>>  
>> -cause = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>> +cause = ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>>  if (!cause)
>>  return;
>>  
>>  printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
>>  printk(KERN_ERR "Cause register: 0x%08x\n", cause);
>>  printk(KERN_ERR "Address Low: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
>>  printk(KERN_ERR "Address High: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
>>  printk(KERN_ERR "Attribute: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
>>  printk(KERN_ERR "Command: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, ~cause);
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
>> +iowrite32(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>>  
>>  if (cause & MV64X60_PCI_PE_MASK)
>>  edac_pci_handle_pe(pci, pci->ctl_name);
>> @@ -61,7 +61,7 @@ static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
>>  struct mv64x60_pci_pdata *pdata = pci->pvt_info;
>>  u32 val;
>>  
>> -val = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>> +val = ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>>  if (!val)
>>  return IRQ_NONE;
>>  
>> @@ -93,7 +93,7 @@ static int __init mv64x60_pci_fixup(struct platform_device 
>> *pdev)
>>  if (!pci_serr)
>>  return -ENOMEM;
>>  
>> -out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
>> +iowrite32(ioread32(pci_serr) & ~0x1, pci_serr);
>>  iounmap(pci_serr);
>>  
>>  return 0;
>> @@ -161,10 +161,10 @@ static int mv64x60_pci_err_probe(struct 
>> platform_device *pdev)
>>  goto err;
>>  }
>>  
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, 0);
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK, 0);
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK,
>> - MV64X60_PCIx_ERR_MASK_VAL);
>> +iowrite32(0, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>> +iowrite32(0, pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
>> +iowrite32(MV64X60_PCIx_ERR_MASK_VAL,
>> +  pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
>>  
>>  if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
>>  edac_dbg(3, "failed edac_pci_add_device()\n");
>> @@ -233,23 +233,23 @@ static void mv64x60_sram_check(struct 
>> edac_device_ctl_info *edac_dev)
>>  struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
>>  u32 cause;
>>  
>> -cause = in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
>> +cause = ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
>>  if (!cause)
>>  return;
>>  
>>  printk(KERN_ERR "Error in internal SRAM\n");
>>  printk(KERN_ERR "Cause register: 0x%08x\n", cause);
>>  printk(KERN_ERR "Address Low: 0x%08x\n",
>> -   in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
>> +  

Re: [PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

[Michael Ellerman]

Borislav Petkov  writes:

> Top-posting so that the PPC list can see the whole patch below.
>
> Since I don't know PPC, let me add PPC ML to CC for a confirmation this
> change is correct.
>
> Which brings me to the tangential: this driver is from 2006-ish and
> is for some "Marvell MV64x60 Memory Controller kernel module for PPC
> platforms". If you're going to touch it, then you should test on the PPC
> hardware too, so that you don't break the driver there.
>
> Unless that hardware is obsolete now and we don't care and, and ..?
>
> Maybe someone has some insights...

Not really sorry.

I don't have one of those boards, so I can't test. Maybe someone else on
the list does?

I'd err on the side of the PPC hardware being obsolete and no one really
caring. If the driver is helpful on ARM then we may as well use it
there, if we can also avoid breaking it on PPC then great.

cheers


> On Fri, May 12, 2017 at 04:20:02PM +1200, Chris Packham wrote:
>> To allow this driver to be used on non-powerpc platforms it needs to use
>> io accessors suitable for all platforms.
>> 
>> Signed-off-by: Chris Packham 
>> ---
>>  drivers/edac/mv64x60_edac.c | 84 
>> ++---
>>  1 file changed, 42 insertions(+), 42 deletions(-)
>> 
>> diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
>> index ddc5082f7577..102ec29f864b 100644
>> --- a/drivers/edac/mv64x60_edac.c
>> +++ b/drivers/edac/mv64x60_edac.c
>> @@ -32,21 +32,21 @@ static void mv64x60_pci_check(struct edac_pci_ctl_info 
>> *pci)
>>  struct mv64x60_pci_pdata *pdata = pci->pvt_info;
>>  u32 cause;
>>  
>> -cause = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>> +cause = ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>>  if (!cause)
>>  return;
>>  
>>  printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
>>  printk(KERN_ERR "Cause register: 0x%08x\n", cause);
>>  printk(KERN_ERR "Address Low: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
>>  printk(KERN_ERR "Address High: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
>>  printk(KERN_ERR "Attribute: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
>>  printk(KERN_ERR "Command: 0x%08x\n",
>> -   in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, ~cause);
>> +   ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
>> +iowrite32(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>>  
>>  if (cause & MV64X60_PCI_PE_MASK)
>>  edac_pci_handle_pe(pci, pci->ctl_name);
>> @@ -61,7 +61,7 @@ static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
>>  struct mv64x60_pci_pdata *pdata = pci->pvt_info;
>>  u32 val;
>>  
>> -val = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>> +val = ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>>  if (!val)
>>  return IRQ_NONE;
>>  
>> @@ -93,7 +93,7 @@ static int __init mv64x60_pci_fixup(struct platform_device 
>> *pdev)
>>  if (!pci_serr)
>>  return -ENOMEM;
>>  
>> -out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
>> +iowrite32(ioread32(pci_serr) & ~0x1, pci_serr);
>>  iounmap(pci_serr);
>>  
>>  return 0;
>> @@ -161,10 +161,10 @@ static int mv64x60_pci_err_probe(struct 
>> platform_device *pdev)
>>  goto err;
>>  }
>>  
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, 0);
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK, 0);
>> -out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK,
>> - MV64X60_PCIx_ERR_MASK_VAL);
>> +iowrite32(0, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
>> +iowrite32(0, pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
>> +iowrite32(MV64X60_PCIx_ERR_MASK_VAL,
>> +  pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
>>  
>>  if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
>>  edac_dbg(3, "failed edac_pci_add_device()\n");
>> @@ -233,23 +233,23 @@ static void mv64x60_sram_check(struct 
>> edac_device_ctl_info *edac_dev)
>>  struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
>>  u32 cause;
>>  
>> -cause = in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
>> +cause = ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
>>  if (!cause)
>>  return;
>>  
>>  printk(KERN_ERR "Error in internal SRAM\n");
>>  printk(KERN_ERR "Cause register: 0x%08x\n", cause);
>>  printk(KERN_ERR "Address Low: 0x%08x\n",
>> -   in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
>> +   ioread32(pdata->sram_vbase + 

[PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

[Bharat Bhushan]

This patch have minor updates in Documentation for arm64i as
relocatable kernel.
Also this patch updates documentation for using uncompressed
image "Image" which is used for ARM64.

Signed-off-by: Bharat Bhushan 
---
 Documentation/kdump/kdump.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 615434d..522ce13 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
 2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
-   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
relocatable
-   kernel.
+   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
+   relocatable kernel.
 
 Building a relocatable kernel is advantageous from the point of view that
 one does not have to build a second kernel for capturing the dump. But
@@ -361,6 +361,12 @@ to load dump-capture kernel.
--dtb= \
--append="root= "
 
+If you are using a uncompressed Image, then use following command
+to load dump-capture kernel.
+
+   kexec -p  \
+   --initrd= \
+   --append="root= "
 
 Please note, that --args-linux does not need to be specified for ia64.
 It is planned to make this a no-op on that architecture, but for now
-- 
1.9.3

[PATCH] kexec/kdump: Minor Documentation updates for arm64 and Image

[Bharat Bhushan]

This patch have minor updates in Documentation for arm64i as
relocatable kernel.
Also this patch updates documentation for using uncompressed
image "Image" which is used for ARM64.

Signed-off-by: Bharat Bhushan 
---
 Documentation/kdump/kdump.txt | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 615434d..522ce13 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -112,8 +112,8 @@ There are two possible methods of using Kdump.
 2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
-   of today, i386, x86_64, ppc64, ia64 and arm architectures support 
relocatable
-   kernel.
+   of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
+   relocatable kernel.
 
 Building a relocatable kernel is advantageous from the point of view that
 one does not have to build a second kernel for capturing the dump. But
@@ -361,6 +361,12 @@ to load dump-capture kernel.
--dtb= \
--append="root= "
 
+If you are using a uncompressed Image, then use following command
+to load dump-capture kernel.
+
+   kexec -p  \
+   --initrd= \
+   --append="root= "
 
 Please note, that --args-linux does not need to be specified for ia64.
 It is planned to make this a no-op on that architecture, but for now
-- 
1.9.3

Re: [PATCH 0/7] crypto: aesni: provide generic gcm(aes)

[Herbert Xu]

On Fri, Apr 28, 2017 at 06:11:55PM +0200, Sabrina Dubroca wrote:
> The current aesni AES-GCM implementation only offers support for
> rfc4106(gcm(aes)).  This makes some things a little bit simpler
> (handling of associated data and authentication tag), but it means
> that non-IPsec users of gcm(aes) have to rely on
> gcm_base(ctr-aes-aesni,ghash-clmulni), which is much slower.
> 
> This patchset adds handling of all valid authentication tag lengths
> and of any associated data length to the assembly code, and exposes a
> generic gcm(aes) AEAD algorithm to the crypto API.
> 
> With these patches, performance of MACsec on a single core increases
> by 40% (from 4.5Gbps to around 6.3Gbps).

All patches applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/7] crypto: aesni: provide generic gcm(aes)

[Herbert Xu]

On Fri, Apr 28, 2017 at 06:11:55PM +0200, Sabrina Dubroca wrote:
> The current aesni AES-GCM implementation only offers support for
> rfc4106(gcm(aes)).  This makes some things a little bit simpler
> (handling of associated data and authentication tag), but it means
> that non-IPsec users of gcm(aes) have to rely on
> gcm_base(ctr-aes-aesni,ghash-clmulni), which is much slower.
> 
> This patchset adds handling of all valid authentication tag lengths
> and of any associated data length to the assembly code, and exposes a
> generic gcm(aes) AEAD algorithm to the crypto API.
> 
> With these patches, performance of MACsec on a single core increases
> by 40% (from 4.5Gbps to around 6.3Gbps).

All patches applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[4.9.28] vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete nr=-2147483624

[Marc Burkhardt]

Hi everybody,

tonight my dmesg was flooded with mesages like 

vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete 
nr=-2147483624

Is that an integer overflow happening in ext4?

It's the first time I see this message. Any help on how to debug/reprocude this
are appreciated. Please advice if you want me to investigate this.

Bestregards,
Marc Burkhardt

-- 
Marc Burkhardt

[4.9.28] vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete nr=-2147483624

[Marc Burkhardt]

Hi everybody,

tonight my dmesg was flooded with mesages like 

vmscan: shrink_slab: ext4_es_scan+0x0/0x150 negative objects to delete 
nr=-2147483624

Is that an integer overflow happening in ext4?

It's the first time I see this message. Any help on how to debug/reprocude this
are appreciated. Please advice if you want me to investigate this.

Bestregards,
Marc Burkhardt

-- 
Marc Burkhardt

Re: [PATCH v5] of/pci: Fix memory leak in of_pci_get_host_bridge_resources

[jeffy]

Hi Bjorn,

On 05/18/2017 05:08 AM, Bjorn Helgaas wrote:

On Wed, Apr 05, 2017 at 10:28:22AM +0800, Jeffy Chen wrote:

Currently we only free the allocated resource struct when error.
This would cause memory leak after pci_free_resource_list.


I think I see the problem here.  The release path is this:

   pci_release_host_bridge_dev
 pci_free_resource_list
   resource_list_free
list_for_each_entry_safe(entry, tmp, head, node)
  resource_list_destroy_entry
resource_list_del
resource_list_free_entry
  kfree(entry)

but that frees only the struct resource_entry, not the struct resource
pointed to by entry->res.  Is that right?

right, that's the leak.



And this patch solves it for of_pci_get_host_bridge_resources() by
always making entry->res point to entry->__res, which is an element in
struct resource_entry, so it's sufficient to free the resource_entry.

The memory management here is pretty tangled.  I wonder if there's
some way to simplify it so it's easier to make sure everybody does it
correctly.  For example, could we remove the entry->res pointer
completely and force everybody to use entry->__res?
i've tried something like this in 
https://patchwork.kernel.org/patch/9638003/


but it turns out there are a few codes trying to use shared 
resources(entry->res pointer point to some common resources), for example:


./arch/tile/kernel/pci.c:307: 
pci_add_resource(, _resource);
./arch/tile/kernel/pci.c:308: 
pci_add_resource(, _resource);


so i tried to use IORESOURCE_AUTO to handle non-common(private) resources.


and i saw drivers/pnp/manager.c tried to handle something like this too, 
by manually free resources marked as IORESOURCE_AUTO:

static void pnp_clean_resource_table(struct pnp_dev *dev)
{
struct pnp_resource *pnp_res, *tmp;

list_for_each_entry_safe(pnp_res, tmp, >resources, list) {
if (pnp_res->res.flags & IORESOURCE_AUTO)
pnp_free_resource(pnp_res);
}
}





Signed-off-by: Jeffy Chen 
---

Changes in v5:
Fix some careless compile errors.

Changes in v4:
Use IORESOURCE_AUTO to mark struct resources which could be copied.

Changes in v3:
Add some comments.

Changes in v2:
Don't change the resource_list_create_entry's behavior.

  drivers/of/of_pci.c | 51 ++-
  drivers/pci/bus.c   |  7 ++-
  2 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..49233bf 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -189,9 +189,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
  {
-   struct resource_entry *window;
-   struct resource *res;
-   struct resource *bus_range;
+   struct resource res;
struct of_pci_range range;
struct of_pci_range_parser parser;
char range_type[4];
@@ -200,24 +198,21 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;

-   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
-   if (!bus_range)
-   return -ENOMEM;
-
pr_info("host bridge %s ranges:\n", dev->full_name);

-   err = of_pci_parse_bus_range(dev, bus_range);
+   err = of_pci_parse_bus_range(dev, );
if (err) {
-   bus_range->start = busno;
-   bus_range->end = bus_max;
-   bus_range->flags = IORESOURCE_BUS;
-   pr_info("  No bus range found for %s, using %pR\n",
-   dev->full_name, bus_range);
+   res.start = busno;
+   res.end = bus_max;
+   res.flags = IORESOURCE_BUS;
+   pr_info("  No bus range found for %s\n", dev->full_name);
} else {
-   if (bus_range->end > bus_range->start + bus_max)
-   bus_range->end = bus_range->start + bus_max;
+   if (res.end > res.start + bus_max)
+   res.end = res.start + bus_max;
}
-   pci_add_resource(resources, bus_range);
+
+   res.flags |= IORESOURCE_AUTO;
+   pci_add_resource(resources, );

/* Check for ranges property */
err = of_pci_range_parser_init(, dev);
@@ -244,24 +239,16 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;

-   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
-   if (!res) {
-   err = -ENOMEM;
-   goto parse_failed;
-   }
-
-   err = of_pci_range_to_resource(, dev, res);
-   if (err) {
-   

Re: [PATCH v5] of/pci: Fix memory leak in of_pci_get_host_bridge_resources

[jeffy]

Hi Bjorn,

On 05/18/2017 05:08 AM, Bjorn Helgaas wrote:

On Wed, Apr 05, 2017 at 10:28:22AM +0800, Jeffy Chen wrote:

Currently we only free the allocated resource struct when error.
This would cause memory leak after pci_free_resource_list.


I think I see the problem here.  The release path is this:

   pci_release_host_bridge_dev
 pci_free_resource_list
   resource_list_free
list_for_each_entry_safe(entry, tmp, head, node)
  resource_list_destroy_entry
resource_list_del
resource_list_free_entry
  kfree(entry)

but that frees only the struct resource_entry, not the struct resource
pointed to by entry->res.  Is that right?

right, that's the leak.



And this patch solves it for of_pci_get_host_bridge_resources() by
always making entry->res point to entry->__res, which is an element in
struct resource_entry, so it's sufficient to free the resource_entry.

The memory management here is pretty tangled.  I wonder if there's
some way to simplify it so it's easier to make sure everybody does it
correctly.  For example, could we remove the entry->res pointer
completely and force everybody to use entry->__res?
i've tried something like this in 
https://patchwork.kernel.org/patch/9638003/


but it turns out there are a few codes trying to use shared 
resources(entry->res pointer point to some common resources), for example:


./arch/tile/kernel/pci.c:307: 
pci_add_resource(, _resource);
./arch/tile/kernel/pci.c:308: 
pci_add_resource(, _resource);


so i tried to use IORESOURCE_AUTO to handle non-common(private) resources.


and i saw drivers/pnp/manager.c tried to handle something like this too, 
by manually free resources marked as IORESOURCE_AUTO:

static void pnp_clean_resource_table(struct pnp_dev *dev)
{
struct pnp_resource *pnp_res, *tmp;

list_for_each_entry_safe(pnp_res, tmp, >resources, list) {
if (pnp_res->res.flags & IORESOURCE_AUTO)
pnp_free_resource(pnp_res);
}
}





Signed-off-by: Jeffy Chen 
---

Changes in v5:
Fix some careless compile errors.

Changes in v4:
Use IORESOURCE_AUTO to mark struct resources which could be copied.

Changes in v3:
Add some comments.

Changes in v2:
Don't change the resource_list_create_entry's behavior.

  drivers/of/of_pci.c | 51 ++-
  drivers/pci/bus.c   |  7 ++-
  2 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..49233bf 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -189,9 +189,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base)
  {
-   struct resource_entry *window;
-   struct resource *res;
-   struct resource *bus_range;
+   struct resource res;
struct of_pci_range range;
struct of_pci_range_parser parser;
char range_type[4];
@@ -200,24 +198,21 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (io_base)
*io_base = (resource_size_t)OF_BAD_ADDR;

-   bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
-   if (!bus_range)
-   return -ENOMEM;
-
pr_info("host bridge %s ranges:\n", dev->full_name);

-   err = of_pci_parse_bus_range(dev, bus_range);
+   err = of_pci_parse_bus_range(dev, );
if (err) {
-   bus_range->start = busno;
-   bus_range->end = bus_max;
-   bus_range->flags = IORESOURCE_BUS;
-   pr_info("  No bus range found for %s, using %pR\n",
-   dev->full_name, bus_range);
+   res.start = busno;
+   res.end = bus_max;
+   res.flags = IORESOURCE_BUS;
+   pr_info("  No bus range found for %s\n", dev->full_name);
} else {
-   if (bus_range->end > bus_range->start + bus_max)
-   bus_range->end = bus_range->start + bus_max;
+   if (res.end > res.start + bus_max)
+   res.end = res.start + bus_max;
}
-   pci_add_resource(resources, bus_range);
+
+   res.flags |= IORESOURCE_AUTO;
+   pci_add_resource(resources, );

/* Check for ranges property */
err = of_pci_range_parser_init(, dev);
@@ -244,24 +239,16 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;

-   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
-   if (!res) {
-   err = -ENOMEM;
-   goto parse_failed;
-   }
-
-   err = of_pci_range_to_resource(, dev, res);
-   if (err) {
-   kfree(res);
+  

Re: [PATCH v3 06/16] drm/i2c: remove unneeded -Iinclude/drm compiler flag

[Archit Taneja]

On 05/18/2017 09:59 AM, Masahiro Yamada wrote:

With the include directives under include/drm/ fixed, this flag is
no longer needed.


Acked-by: Archit Taneja 



Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/i2c/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..a77acfc 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 06/16] drm/i2c: remove unneeded -Iinclude/drm compiler flag

[Archit Taneja]

On 05/18/2017 09:59 AM, Masahiro Yamada wrote:

With the include directives under include/drm/ fixed, this flag is
no longer needed.


Acked-by: Archit Taneja 



Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/i2c/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..a77acfc 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] crypto: tcrypt: don't disable irqs and wait

[Herbert Xu]

On Tue, Apr 25, 2017 at 11:25:40AM +0300, Gilad Ben-Yossef wrote:
> The tcrypt AEAD cycles speed tests disables irqs during the test, which is
> broken at the very least since commit
> '1425d2d17f7309c6 ("crypto: tcrypt - Fix AEAD speed tests")'
> adds a wait for completion as part of the test and probably since
> switching to the new AEAD API.
> 
> While the result of taking a cycle count diff may not mean much on SMP
> systems if the task migrates, it's good enough for tcrypt being the quick
> & dirty dev tool it is. It's also what all the other (i.e. hash) cycle
> speed tests do.
> 
> Signed-off-by: Gilad Ben-Yossef 
> Reported-by: Ofir Drang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: tcrypt: don't disable irqs and wait

[Herbert Xu]

On Tue, Apr 25, 2017 at 11:25:40AM +0300, Gilad Ben-Yossef wrote:
> The tcrypt AEAD cycles speed tests disables irqs during the test, which is
> broken at the very least since commit
> '1425d2d17f7309c6 ("crypto: tcrypt - Fix AEAD speed tests")'
> adds a wait for completion as part of the test and probably since
> switching to the new AEAD API.
> 
> While the result of taking a cycle count diff may not mean much on SMP
> systems if the task migrates, it's good enough for tcrypt being the quick
> & dirty dev tool it is. It's also what all the other (i.e. hash) cycle
> speed tests do.
> 
> Signed-off-by: Gilad Ben-Yossef 
> Reported-by: Ofir Drang 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v8 06/08] iommu/ipmmu-vmsa: Use fwspec iommu_priv on ARM64

[Magnus Damm]

Hi Robin,

On Wed, May 17, 2017 at 11:29 PM, Robin Murphy  wrote:
> Hi Magnus,
>
> On 17/05/17 11:07, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Convert from archdata to iommu_priv via iommu_fwspec on ARM64 but
>> let 32-bit ARM keep on using archdata for now.
>>
>> Once the 32-bit ARM code and the IPMMU driver is able to move over
>> to CONFIG_IOMMU_DMA=y then coverting to fwspec via ->of_xlate() will
>> be easy.
>>
>> For now fwspec ids and num_ids are not used to allow code sharing between
>> 32-bit and 64-bit ARM code inside the driver.
>
> That's not what I meant at all - this just looks like a crazy
> unmaintainable mess that's making things that much harder to unpick in
> future.
>
> Leaving the existing code fossilised and building up half of a second
> separate driver around it wrapped in ifdefs is not only hideous, it's
> more work in the end than simply pulling things into the right shape to
> begin with. What I meant was to start with the below (compile-tested
> only), and add the of_xlate support on top. AFAICS the arm/arm64
> differences overall should only come down to a bit of special-casing in
> add_device(), and (optionally) whether you outright reject
> IOMMU_DOMAIN_DMA or not.
>
> Sorry, but I just can't agree with the two-drivers-in-one approach.

Thanks for checking the code and sorry to disappoint you by not using
->ids[] and ->num_ids right away. The two-drivers-on-one approach
comes from wanting to use the same IOMMU driver on both 32-bit and
64-bit ARM architectures but the former is lacking IOMMU_DMA support
upstream.

Obviously using ->ids[] and ->num_ids is the right forward, and in my
mind it is only a question of time and merge order. I'm more than
happy to make use of your patch but I'm wondering if it will work on
32-bit ARM and R-Car Gen2 that currently does not use ->of_xlate(). I
can see that you're using iommu_fwspec_init() so it might work right
out of the box. Thanks for your help cooking up the patch by the way.

>From my side I was hoping on doing one larger feature jump for 32-bit
ARM by moving over to IOMMU_DMA=y together with ->of_xlate()and fwspec
at the same time. Doing minor increments of the legacy code that is
still using special mapping code instead of OMMU_DMA=y in case of
32-bit ARM just feels like a lot of potential breakage and little gain
to me.

What's the plan for supporting IOMMU_DMA=y on 32-bit ARM? Anything I
can do to help? Or do you prefer minor increments on 32-bit ARM over
larger feature jumps?

Let me know what you think. My plan is to revisit this topic early next week.

Cheers,

/ magnus

Re: [PATCH v8 06/08] iommu/ipmmu-vmsa: Use fwspec iommu_priv on ARM64

[Magnus Damm]

Hi Robin,

On Wed, May 17, 2017 at 11:29 PM, Robin Murphy  wrote:
> Hi Magnus,
>
> On 17/05/17 11:07, Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Convert from archdata to iommu_priv via iommu_fwspec on ARM64 but
>> let 32-bit ARM keep on using archdata for now.
>>
>> Once the 32-bit ARM code and the IPMMU driver is able to move over
>> to CONFIG_IOMMU_DMA=y then coverting to fwspec via ->of_xlate() will
>> be easy.
>>
>> For now fwspec ids and num_ids are not used to allow code sharing between
>> 32-bit and 64-bit ARM code inside the driver.
>
> That's not what I meant at all - this just looks like a crazy
> unmaintainable mess that's making things that much harder to unpick in
> future.
>
> Leaving the existing code fossilised and building up half of a second
> separate driver around it wrapped in ifdefs is not only hideous, it's
> more work in the end than simply pulling things into the right shape to
> begin with. What I meant was to start with the below (compile-tested
> only), and add the of_xlate support on top. AFAICS the arm/arm64
> differences overall should only come down to a bit of special-casing in
> add_device(), and (optionally) whether you outright reject
> IOMMU_DOMAIN_DMA or not.
>
> Sorry, but I just can't agree with the two-drivers-in-one approach.

Thanks for checking the code and sorry to disappoint you by not using
->ids[] and ->num_ids right away. The two-drivers-on-one approach
comes from wanting to use the same IOMMU driver on both 32-bit and
64-bit ARM architectures but the former is lacking IOMMU_DMA support
upstream.

Obviously using ->ids[] and ->num_ids is the right forward, and in my
mind it is only a question of time and merge order. I'm more than
happy to make use of your patch but I'm wondering if it will work on
32-bit ARM and R-Car Gen2 that currently does not use ->of_xlate(). I
can see that you're using iommu_fwspec_init() so it might work right
out of the box. Thanks for your help cooking up the patch by the way.

>From my side I was hoping on doing one larger feature jump for 32-bit
ARM by moving over to IOMMU_DMA=y together with ->of_xlate()and fwspec
at the same time. Doing minor increments of the legacy code that is
still using special mapping code instead of OMMU_DMA=y in case of
32-bit ARM just feels like a lot of potential breakage and little gain
to me.

What's the plan for supporting IOMMU_DMA=y on 32-bit ARM? Anything I
can do to help? Or do you prefer minor increments on 32-bit ARM over
larger feature jumps?

Let me know what you think. My plan is to revisit this topic early next week.

Cheers,

/ magnus

Re: [PATCH v3 2/2] powerpc/mm/hugetlb: Add support for 1G huge pages

[Michael Ellerman]

"Aneesh Kumar K.V"  writes:

> POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch
> enables the usage of 1G page size for hugetlbfs. This also update the helper
> such we can do 1G page allocation at runtime.
>
> We still don't enable 1G page size on DD1 version. This is to avoid doing
> workaround mentioned in commit: 6d3a0379ebdc8 (powerpc/mm: Add
> radix__tlb_flush_pte_p9_dd1()
>
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/include/asm/book3s/64/hugetlb.h | 10 ++
>  arch/powerpc/mm/hugetlbpage.c|  7 +--
>  arch/powerpc/platforms/Kconfig.cputype   |  1 +
>  3 files changed, 16 insertions(+), 2 deletions(-)

I think this patch is OK, but it's very confusing because it doesn't
mention that it's only talking about *generic* gigantic page support.

We have existing support for gigantic pages on powerpc, on several
platforms. This patch appears to break that, but I think doesn't in
practice?

So can you make it a bit clearer in the commit message, and the code,
that this is only about enabling the generic gigantic page support, and
is unrelated to the arch-specific gigantic page support.

cheers

> diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
> b/arch/powerpc/include/asm/book3s/64/hugetlb.h
> index cd366596..5c28bd6f2ae1 100644
> --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
> +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
> @@ -50,4 +50,14 @@ static inline pte_t arch_make_huge_pte(pte_t entry, struct 
> vm_area_struct *vma,
>   else
>   return entry;
>  }
> +
> +#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
> +static inline bool gigantic_page_supported(void)
> +{
> + if (radix_enabled())
> + return true;
> + return false;
> +}
> +#endif
> +
>  #endif
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index a4f33de4008e..80f6d2ed551a 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -763,8 +763,11 @@ static int __init add_huge_page_size(unsigned long long 
> size)
>* Hash: 16M and 16G
>*/
>   if (radix_enabled()) {
> - if (mmu_psize != MMU_PAGE_2M)
> - return -EINVAL;
> + if (mmu_psize != MMU_PAGE_2M) {
> + if (cpu_has_feature(CPU_FTR_POWER9_DD1) ||
> + (mmu_psize != MMU_PAGE_1G))
> + return -EINVAL;
> + }
>   } else {
>   if (mmu_psize != MMU_PAGE_16M && mmu_psize != MMU_PAGE_16G)
>   return -EINVAL;
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index 684e886eaae4..b76ef6637016 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -344,6 +344,7 @@ config PPC_STD_MMU_64
>  config PPC_RADIX_MMU
>   bool "Radix MMU Support"
>   depends on PPC_BOOK3S_64
> + select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
>   default y
>   help
> Enable support for the Power ISA 3.0 Radix style MMU. Currently this
> -- 
> 2.7.4

Re: [PATCH v3 2/2] powerpc/mm/hugetlb: Add support for 1G huge pages

[Michael Ellerman]

"Aneesh Kumar K.V"  writes:

> POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch
> enables the usage of 1G page size for hugetlbfs. This also update the helper
> such we can do 1G page allocation at runtime.
>
> We still don't enable 1G page size on DD1 version. This is to avoid doing
> workaround mentioned in commit: 6d3a0379ebdc8 (powerpc/mm: Add
> radix__tlb_flush_pte_p9_dd1()
>
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/include/asm/book3s/64/hugetlb.h | 10 ++
>  arch/powerpc/mm/hugetlbpage.c|  7 +--
>  arch/powerpc/platforms/Kconfig.cputype   |  1 +
>  3 files changed, 16 insertions(+), 2 deletions(-)

I think this patch is OK, but it's very confusing because it doesn't
mention that it's only talking about *generic* gigantic page support.

We have existing support for gigantic pages on powerpc, on several
platforms. This patch appears to break that, but I think doesn't in
practice?

So can you make it a bit clearer in the commit message, and the code,
that this is only about enabling the generic gigantic page support, and
is unrelated to the arch-specific gigantic page support.

cheers

> diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h 
> b/arch/powerpc/include/asm/book3s/64/hugetlb.h
> index cd366596..5c28bd6f2ae1 100644
> --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
> +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
> @@ -50,4 +50,14 @@ static inline pte_t arch_make_huge_pte(pte_t entry, struct 
> vm_area_struct *vma,
>   else
>   return entry;
>  }
> +
> +#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
> +static inline bool gigantic_page_supported(void)
> +{
> + if (radix_enabled())
> + return true;
> + return false;
> +}
> +#endif
> +
>  #endif
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index a4f33de4008e..80f6d2ed551a 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -763,8 +763,11 @@ static int __init add_huge_page_size(unsigned long long 
> size)
>* Hash: 16M and 16G
>*/
>   if (radix_enabled()) {
> - if (mmu_psize != MMU_PAGE_2M)
> - return -EINVAL;
> + if (mmu_psize != MMU_PAGE_2M) {
> + if (cpu_has_feature(CPU_FTR_POWER9_DD1) ||
> + (mmu_psize != MMU_PAGE_1G))
> + return -EINVAL;
> + }
>   } else {
>   if (mmu_psize != MMU_PAGE_16M && mmu_psize != MMU_PAGE_16G)
>   return -EINVAL;
> diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> b/arch/powerpc/platforms/Kconfig.cputype
> index 684e886eaae4..b76ef6637016 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -344,6 +344,7 @@ config PPC_STD_MMU_64
>  config PPC_RADIX_MMU
>   bool "Radix MMU Support"
>   depends on PPC_BOOK3S_64
> + select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
>   default y
>   help
> Enable support for the Power ISA 3.0 Radix style MMU. Currently this
> -- 
> 2.7.4

[scsi] 66de5f1b19: BUG:unable_to_handle_kernel

[kernel test robot]

FYI, we noticed the following commit:

commit: 66de5f1b197e175840a132f7ee8927bfc3ff92b3 ("scsi: Move 
scsi_device.cmd_list manipulation code")
https://github.com/bvanassche/linux for-next

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G

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


+--+++
|  | 002c9890c6 
| 66de5f1b19 |
+--+++
| boot_successes   | 6  
| 0  |
| boot_failures| 4  
| 10 |
| invoked_oom-killer:gfp_mask=0x   | 4  
||
| Mem-Info | 4  
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 4  
||
| BUG:unable_to_handle_kernel  | 0  
| 10 |
| Oops:#[##]   | 0  
| 10 |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt| 0  
| 10 |
+--+++



[   38.475923] BUG: unable to handle kernel NULL pointer dereference at 
0008
[   38.475979] IP: scsi_put_command+0x31/0x5d
[   38.475981] PGD 0 
[   38.475983] P4D 0 
[   38.475984] 
[   38.475989] Oops: 0002 [#1] SMP
[   38.476013] Modules linked in:
[   38.476021] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-12455-g66de5f1 
#1
[   38.476044] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   38.476048] task: 88022a2c task.stack: c9c54000
[   38.476053] RIP: 0010:scsi_put_command+0x31/0x5d
[   38.476055] RSP: :88023fc03e30 EFLAGS: 00010082
[   38.476081] RAX: 0246 RBX: 880207e70d40 RCX: 
[   38.476084] RDX: 880207e70d80 RSI:  RDI: 
[   38.476086] RBP: 88023fc03e38 R08:  R09: 81121b01
[   38.476110] R10: 88023fc03d68 R11:  R12: 880207e70c00
[   38.476113] R13: 880207e70d40 R14: 88020801 R15: 
[   38.476118] FS:  () GS:88023fc0() 
knlGS:
[   38.476142] CS:  0010 DS:  ES:  CR0: 80050033
[   38.476144] CR2: 0008 CR3: 01e11000 CR4: 06f0
[   38.476175] Call Trace:
[   38.476178]  
[   38.476214]  scsi_end_request+0x130/0x17b
[   38.476241]  scsi_io_completion+0x1ce/0x49f
[   38.476246]  scsi_finish_command+0x113/0x11c
[   38.476272]  scsi_softirq_done+0xe5/0x107
[   38.476280]  blk_done_softirq+0x7c/0x83
[   38.476310]  __do_softirq+0xff/0x267
[   38.476339]  irq_exit+0x58/0x99
[   38.476345]  smp_apic_timer_interrupt+0x3d/0x48
[   38.476372]  apic_timer_interrupt+0x89/0x90
[   38.476402] RIP: 0010:console_unlock+0x221/0x42e
[   38.476404] RSP: :c9c57d58 EFLAGS: 0246 ORIG_RAX: 
ff10
[   38.476410] RAX:  RBX: 8212d220 RCX: 
[   38.476433] RDX: 03f9 RSI: 0046 RDI: 0246
[   38.476436] RBP: c9c57da0 R08:  R09: 
[   38.476439] R10: 81aa0735 R11: 8212d227 R12: 
[   38.476442] R13: 81f561c0 R14:  R15: 0040
[   38.476444]  
[   38.476474]  vprintk_emit+0x215/0x227
[   38.476503]  ? cnic_init+0x7f/0x7f
[   38.476507]  ? set_debug_rodata+0x17/0x17
[   38.476533]  vprintk_default+0x1d/0x1f
[   38.476537]  vprintk_func+0x4a/0x4c
[   38.476564]  printk+0x43/0x4b
[   38.476570]  bnx2x_init+0x1d/0xea
[   38.476574]  ? cnic_init+0x7f/0x7f
[   38.476600]  do_one_initcall+0x90/0x137
[   38.476605]  ? set_debug_rodata+0x17/0x17
[   38.476630]  kernel_init_freeable+0x179/0x1fc
[   38.476636]  ? rest_init+0x87/0x87
[   38.476661]  kernel_init+0xe/0xfa
[   38.47]  ret_from_fork+0x2c/0x40
[   38.476669] Code: 48 89 e5 53 48 8b 47 38 48 89 fb 48 8d 78 38 e8 70 84 4a 
00 48 8b 4b 40 48 8d 53 40 48 39 ca 75 02 0f 0b 48 8b 7b 40 48 8b 4b 48 <48> 89 
4f 08 48 89 39 48 8b 73 38 48 89 53 40 48 89 53 48 48 8d 
[   38.476988] RIP: scsi_put_command+0x31/0x5d RSP: 88023fc03e30
[   38.476990] CR2: 0008
[   38.477022] ---[ end trace ab7b630f48deb907 ]---


To reproduce:

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



Thanks,
Kernel Test Robot
#
# Automatically generated file; 

[scsi] 66de5f1b19: BUG:unable_to_handle_kernel

[kernel test robot]

FYI, we noticed the following commit:

commit: 66de5f1b197e175840a132f7ee8927bfc3ff92b3 ("scsi: Move 
scsi_device.cmd_list manipulation code")
https://github.com/bvanassche/linux for-next

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G

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


+--+++
|  | 002c9890c6 
| 66de5f1b19 |
+--+++
| boot_successes   | 6  
| 0  |
| boot_failures| 4  
| 10 |
| invoked_oom-killer:gfp_mask=0x   | 4  
||
| Mem-Info | 4  
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 4  
||
| BUG:unable_to_handle_kernel  | 0  
| 10 |
| Oops:#[##]   | 0  
| 10 |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt| 0  
| 10 |
+--+++



[   38.475923] BUG: unable to handle kernel NULL pointer dereference at 
0008
[   38.475979] IP: scsi_put_command+0x31/0x5d
[   38.475981] PGD 0 
[   38.475983] P4D 0 
[   38.475984] 
[   38.475989] Oops: 0002 [#1] SMP
[   38.476013] Modules linked in:
[   38.476021] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-12455-g66de5f1 
#1
[   38.476044] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   38.476048] task: 88022a2c task.stack: c9c54000
[   38.476053] RIP: 0010:scsi_put_command+0x31/0x5d
[   38.476055] RSP: :88023fc03e30 EFLAGS: 00010082
[   38.476081] RAX: 0246 RBX: 880207e70d40 RCX: 
[   38.476084] RDX: 880207e70d80 RSI:  RDI: 
[   38.476086] RBP: 88023fc03e38 R08:  R09: 81121b01
[   38.476110] R10: 88023fc03d68 R11:  R12: 880207e70c00
[   38.476113] R13: 880207e70d40 R14: 88020801 R15: 
[   38.476118] FS:  () GS:88023fc0() 
knlGS:
[   38.476142] CS:  0010 DS:  ES:  CR0: 80050033
[   38.476144] CR2: 0008 CR3: 01e11000 CR4: 06f0
[   38.476175] Call Trace:
[   38.476178]  
[   38.476214]  scsi_end_request+0x130/0x17b
[   38.476241]  scsi_io_completion+0x1ce/0x49f
[   38.476246]  scsi_finish_command+0x113/0x11c
[   38.476272]  scsi_softirq_done+0xe5/0x107
[   38.476280]  blk_done_softirq+0x7c/0x83
[   38.476310]  __do_softirq+0xff/0x267
[   38.476339]  irq_exit+0x58/0x99
[   38.476345]  smp_apic_timer_interrupt+0x3d/0x48
[   38.476372]  apic_timer_interrupt+0x89/0x90
[   38.476402] RIP: 0010:console_unlock+0x221/0x42e
[   38.476404] RSP: :c9c57d58 EFLAGS: 0246 ORIG_RAX: 
ff10
[   38.476410] RAX:  RBX: 8212d220 RCX: 
[   38.476433] RDX: 03f9 RSI: 0046 RDI: 0246
[   38.476436] RBP: c9c57da0 R08:  R09: 
[   38.476439] R10: 81aa0735 R11: 8212d227 R12: 
[   38.476442] R13: 81f561c0 R14:  R15: 0040
[   38.476444]  
[   38.476474]  vprintk_emit+0x215/0x227
[   38.476503]  ? cnic_init+0x7f/0x7f
[   38.476507]  ? set_debug_rodata+0x17/0x17
[   38.476533]  vprintk_default+0x1d/0x1f
[   38.476537]  vprintk_func+0x4a/0x4c
[   38.476564]  printk+0x43/0x4b
[   38.476570]  bnx2x_init+0x1d/0xea
[   38.476574]  ? cnic_init+0x7f/0x7f
[   38.476600]  do_one_initcall+0x90/0x137
[   38.476605]  ? set_debug_rodata+0x17/0x17
[   38.476630]  kernel_init_freeable+0x179/0x1fc
[   38.476636]  ? rest_init+0x87/0x87
[   38.476661]  kernel_init+0xe/0xfa
[   38.47]  ret_from_fork+0x2c/0x40
[   38.476669] Code: 48 89 e5 53 48 8b 47 38 48 89 fb 48 8d 78 38 e8 70 84 4a 
00 48 8b 4b 40 48 8d 53 40 48 39 ca 75 02 0f 0b 48 8b 7b 40 48 8b 4b 48 <48> 89 
4f 08 48 89 39 48 8b 73 38 48 89 53 40 48 89 53 48 48 8d 
[   38.476988] RIP: scsi_put_command+0x31/0x5d RSP: 88023fc03e30
[   38.476990] CR2: 0008
[   38.477022] ---[ end trace ab7b630f48deb907 ]---


To reproduce:

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



Thanks,
Kernel Test Robot
#
# Automatically generated file; 

Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

[Jan Kiszka]

On 2017-05-13 15:36, Andy Shevchenko wrote:
> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
>> First, the logic for translating a register bit to the return code of
>> exar_get_direction and exar_get_value were wrong. And second, there was
>> a flip regarding the register bank in exar_get_direction.
> 
> Again, I wish it was tested in the first place.
> 
> After addressing below:
> FWIW:
> Reviewed-by: Andy Shevchenko 
> 
>> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int 
>> reg)
>> value = readb(exar_gpio->regs + reg);
>> mutex_unlock(_gpio->lock);
>>
>> -   return !!value;
>> +   return value;
> 
> This one is correct.
> 
>> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, 
>> unsigned int offset)
>> addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
>> val = exar_get(chip, addr) >> (offset % 8);
>>
>> -   return !!val;
>> +   return val & 1;
> 
> It should be rather
> 
> val = exar_get(chip, addr) & BIT(offset % 8);

That won't give us 0 or 1 as return value, thus would be incorrect.

> 
>>  }
>>
>>  static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
>> @@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, 
>> unsigned int offset)
>> unsigned int addr;
>> int val;
>>
>> -   addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
>> +   addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
> 
> Good catch!
> 
>> val = exar_get(chip, addr) >> (offset % 8);
>>
>> -   return !!val;
>> +   return val & 1;
> 
> Ditto (see above).
> 

Same here.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

[Jan Kiszka]

On 2017-05-13 15:36, Andy Shevchenko wrote:
> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
>> First, the logic for translating a register bit to the return code of
>> exar_get_direction and exar_get_value were wrong. And second, there was
>> a flip regarding the register bank in exar_get_direction.
> 
> Again, I wish it was tested in the first place.
> 
> After addressing below:
> FWIW:
> Reviewed-by: Andy Shevchenko 
> 
>> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int 
>> reg)
>> value = readb(exar_gpio->regs + reg);
>> mutex_unlock(_gpio->lock);
>>
>> -   return !!value;
>> +   return value;
> 
> This one is correct.
> 
>> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, 
>> unsigned int offset)
>> addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
>> val = exar_get(chip, addr) >> (offset % 8);
>>
>> -   return !!val;
>> +   return val & 1;
> 
> It should be rather
> 
> val = exar_get(chip, addr) & BIT(offset % 8);

That won't give us 0 or 1 as return value, thus would be incorrect.

> 
>>  }
>>
>>  static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
>> @@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, 
>> unsigned int offset)
>> unsigned int addr;
>> int val;
>>
>> -   addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
>> +   addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
> 
> Good catch!
> 
>> val = exar_get(chip, addr) >> (offset % 8);
>>
>> -   return !!val;
>> +   return val & 1;
> 
> Ditto (see above).
> 

Same here.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 0/7] perf tool: add meta-data header support for pipe-mode

[Andi Kleen]

> The difficulty in pipe mode is that information needs to be written
> sequentially to the pipe. Meta data headers are usually generated
> (and also expected) at the beginning of the file (or piped output).
> To solve this problem, we introduce new synthetic record types,
> one for each meta-data type. The approach is similar to what
> is *ALREADY* used for BUILD_ID and TRACING_DATA.

The new headers need documentation in Documentation/perf.data-file-format.txt

-Andi

Re: [PATCH 0/7] perf tool: add meta-data header support for pipe-mode

[Andi Kleen]

> The difficulty in pipe mode is that information needs to be written
> sequentially to the pipe. Meta data headers are usually generated
> (and also expected) at the beginning of the file (or piped output).
> To solve this problem, we introduce new synthetic record types,
> one for each meta-data type. The approach is similar to what
> is *ALREADY* used for BUILD_ID and TRACING_DATA.

The new headers need documentation in Documentation/perf.data-file-format.txt

-Andi

Re: [PATCH 2/4] crypto: drbg wait for crypto op not signal safe

[Herbert Xu]

On Thu, May 11, 2017 at 02:53:43PM +0300, Gilad Ben-Yossef wrote:
> drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
> wait for completion of async crypto op but if a signal occurs it
> may return before DMA ops of HW crypto provider finish, thus
> corrupting the output buffer.
> 
> Resolve this by using wait_for_completion() instead.
> 
> Reported-by: Eric Biggers 
> Signed-off-by: Gilad Ben-Yossef 
> CC: sta...@vger.kernel.org

This patch doesn't even compile.  Please test your work first.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 2/4] crypto: drbg wait for crypto op not signal safe

[Herbert Xu]

On Thu, May 11, 2017 at 02:53:43PM +0300, Gilad Ben-Yossef wrote:
> drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
> wait for completion of async crypto op but if a signal occurs it
> may return before DMA ops of HW crypto provider finish, thus
> corrupting the output buffer.
> 
> Resolve this by using wait_for_completion() instead.
> 
> Reported-by: Eric Biggers 
> Signed-off-by: Gilad Ben-Yossef 
> CC: sta...@vger.kernel.org

This patch doesn't even compile.  Please test your work first.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 8/8] serial: exar: Add support for IOT2040 device

[Jan Kiszka]

On 2017-05-13 15:54, Andy Shevchenko wrote:
> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
>> This implements the setup of RS232 and the switch-over to RS485 or RS422
>> for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
>> to switch between the different modes. The external logic is controlled
>> via MPIO pins of the EXAR controller.
>>
>> Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
>> an LED.
>>
>> As the XR17V352 used on the IOT2040 is not equipped with an external
>> EEPROM, it cannot present itself as IOT2040-variant via subvendor/
>> subdevice IDs. Thus, we have to check via DMI for the target platform.
>>
>> Co-developed with Sascha Weisenberger.
>>
> 
> Please, refactor that using properly formed DMI structrure and use its
> callback and driver data facilities/

Could you point to a specific example? The callback of the dmi_system_id
structure is not designed to handle device initializations like this one
- not to speak of having those two different initialization points here.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 8/8] serial: exar: Add support for IOT2040 device

[Jan Kiszka]

On 2017-05-13 15:54, Andy Shevchenko wrote:
> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
>> This implements the setup of RS232 and the switch-over to RS485 or RS422
>> for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
>> to switch between the different modes. The external logic is controlled
>> via MPIO pins of the EXAR controller.
>>
>> Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
>> an LED.
>>
>> As the XR17V352 used on the IOT2040 is not equipped with an external
>> EEPROM, it cannot present itself as IOT2040-variant via subvendor/
>> subdevice IDs. Thus, we have to check via DMI for the target platform.
>>
>> Co-developed with Sascha Weisenberger.
>>
> 
> Please, refactor that using properly formed DMI structrure and use its
> callback and driver data facilities/

Could you point to a specific example? The callback of the dmi_system_id
structure is not designed to handle device initializations like this one
- not to speak of having those two different initialization points here.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

[Bjorn Andersson]

On Wed 17 May 06:14 PDT 2017, Johannes Berg wrote:

> On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote:
> > 
> > > > This code intentionally checked if TX status was requested, and
> > > > if not then it doesn't go to the effort of building it.
> > > > 
> > > 
> > > What I'm finding puzzling is the fact that the only caller of
> > > ieee80211_led_tx() is ieee80211_tx_status() and it seems like
> > > drivers, such as ath10k, call this for each packet handled - but
> > > I'm likely missing something.
> 
> Yes, many drivers do call it for each packet, and as such, this
> deficiency was never noted.
> 
> > > > As it is with your patch, it'll go and report the TX status
> > > > without any
> > > > TX status information - which is handled in
> > > > wcn36xx_dxe_tx_ack_ind()
> > > > for those frames needing it.
> > > > 
> > > 
> > > Right, it doesn't sound desired. However, during normal operation
> > > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> > > ieee80211_led_tx() is never called.
> > 
> > So what's the conclusion? How do we get leds working?
> 
> Well, frankly, I never thought the TX LED was a super good idea - but
> it had been supported by the original code IIRC, so never removed. Some
> people like frantic blinking I guess ;-)
> 

It seems very important to a lot of people...


But if ieee80211_free_txskb() is the counterpart of
ieee80211_tx_status() then we should be able to push the
ieee80211_led_tx() call down into ieee80211_report_used_skb() and handle
both cases.

The ieee80211_free_txskb() seems to be used in various cases where we
discard skbs, but perhaps this is not an issue in reality.

> But I think the problem also applies to the throughput trigger thing,
> so perhaps we need to stick some LED feedback calls into other places,
> like _noskb() or provide an extra way to do it?
> 

Looking around it seems that we either have a call to free_txskb() or
one of the tx_status(); where the _noskb() would need some special
handling. Are there others or would it be reasonable to add a call in
this one "special" case?

Regards,
Bjorn

Re: [PATCH 1/2] wcn36xx: Pass used skb to ieee80211_tx_status()

[Bjorn Andersson]

On Wed 17 May 06:14 PDT 2017, Johannes Berg wrote:

> On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote:
> > 
> > > > This code intentionally checked if TX status was requested, and
> > > > if not then it doesn't go to the effort of building it.
> > > > 
> > > 
> > > What I'm finding puzzling is the fact that the only caller of
> > > ieee80211_led_tx() is ieee80211_tx_status() and it seems like
> > > drivers, such as ath10k, call this for each packet handled - but
> > > I'm likely missing something.
> 
> Yes, many drivers do call it for each packet, and as such, this
> deficiency was never noted.
> 
> > > > As it is with your patch, it'll go and report the TX status
> > > > without any
> > > > TX status information - which is handled in
> > > > wcn36xx_dxe_tx_ack_ind()
> > > > for those frames needing it.
> > > > 
> > > 
> > > Right, it doesn't sound desired. However, during normal operation
> > > I'm not seeing IEEE80211_TX_CTL_REQ_TX_STATUS being set and as such
> > > ieee80211_led_tx() is never called.
> > 
> > So what's the conclusion? How do we get leds working?
> 
> Well, frankly, I never thought the TX LED was a super good idea - but
> it had been supported by the original code IIRC, so never removed. Some
> people like frantic blinking I guess ;-)
> 

It seems very important to a lot of people...


But if ieee80211_free_txskb() is the counterpart of
ieee80211_tx_status() then we should be able to push the
ieee80211_led_tx() call down into ieee80211_report_used_skb() and handle
both cases.

The ieee80211_free_txskb() seems to be used in various cases where we
discard skbs, but perhaps this is not an issue in reality.

> But I think the problem also applies to the throughput trigger thing,
> so perhaps we need to stick some LED feedback calls into other places,
> like _noskb() or provide an extra way to do it?
> 

Looking around it seems that we either have a call to free_txskb() or
one of the tx_status(); where the _noskb() would need some special
handling. Are there others or would it be reasonable to add a call in
this one "special" case?

Regards,
Bjorn

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

[David Carrillo-Cisneros]

On Tue, May 16, 2017 at 7:38 AM, Peter Zijlstra  wrote:
> On Thu, May 04, 2017 at 10:31:43AM +0800, Zefan Li wrote:
>> It is assumed that the head of cache_groups always has valid RMID,
>> which isn't true.
>>
>> When we deallocate RMID from conflicting events currently we don't
>> move them to the tail, and one of those events can happen to be in
>> the head. Another case is we allocate RMIDs for all the events except
>> the head event in intel_cqm_sched_in_event().
>>
>> Besides there's another bug that we retry rotating without resetting
>> nr_needed and start in __intel_cqm_rmid_rotate().
>>
>> Those bugs combined together led to the following oops.
>>
>> WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 
>> __put_rmid+0x28/0x80()
>> ...
>>  [] __put_rmid+0x28/0x80
>>  [] intel_cqm_rmid_rotate+0xba/0x440
>>  [] process_one_work+0x17b/0x470
>>  [] worker_thread+0x11b/0x400
>> ...
>> BUG: unable to handle kernel NULL pointer dereference at   (null)

I ran into this bug long time ago but never found an easy way to
reproduce. Do you have one?

>> ...
>>  [] intel_cqm_rmid_rotate+0xba/0x440
>>  [] process_one_work+0x17b/0x470
>>  [] worker_thread+0x11b/0x400
>
> I've managed to forgot most if not all of that horror show. Vikas and
> David seem to be working on a replacement, but until such a time it
> would be good if this thing would not crash the kernel.
>
> Guys, could you have a look? To me it appears to mostly have the right
> shape, but like I said, I forgot most details...

The patch LGTM. I ran into this issues before and fixed them in a
similar but messier way, then the re-write started ...

>
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Zefan Li 
Acked-by: David Carrillo-Cisneros 

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

[David Carrillo-Cisneros]

On Tue, May 16, 2017 at 7:38 AM, Peter Zijlstra  wrote:
> On Thu, May 04, 2017 at 10:31:43AM +0800, Zefan Li wrote:
>> It is assumed that the head of cache_groups always has valid RMID,
>> which isn't true.
>>
>> When we deallocate RMID from conflicting events currently we don't
>> move them to the tail, and one of those events can happen to be in
>> the head. Another case is we allocate RMIDs for all the events except
>> the head event in intel_cqm_sched_in_event().
>>
>> Besides there's another bug that we retry rotating without resetting
>> nr_needed and start in __intel_cqm_rmid_rotate().
>>
>> Those bugs combined together led to the following oops.
>>
>> WARNING: at arch/x86/kernel/cpu/perf_event_intel_cqm.c:186 
>> __put_rmid+0x28/0x80()
>> ...
>>  [] __put_rmid+0x28/0x80
>>  [] intel_cqm_rmid_rotate+0xba/0x440
>>  [] process_one_work+0x17b/0x470
>>  [] worker_thread+0x11b/0x400
>> ...
>> BUG: unable to handle kernel NULL pointer dereference at   (null)

I ran into this bug long time ago but never found an easy way to
reproduce. Do you have one?

>> ...
>>  [] intel_cqm_rmid_rotate+0xba/0x440
>>  [] process_one_work+0x17b/0x470
>>  [] worker_thread+0x11b/0x400
>
> I've managed to forgot most if not all of that horror show. Vikas and
> David seem to be working on a replacement, but until such a time it
> would be good if this thing would not crash the kernel.
>
> Guys, could you have a look? To me it appears to mostly have the right
> shape, but like I said, I forgot most details...

The patch LGTM. I ran into this issues before and fixed them in a
similar but messier way, then the re-write started ...

>
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Zefan Li 
Acked-by: David Carrillo-Cisneros 

Re: [PATCH RFC 0/3] Improve stability of system clock

[Richard Cochran]

On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote:
> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar  
> wrote:
> > Is there a better way to run the timekeeping code in an userspace
> > application? I suspect it would need something like the Linux Kernel
> > Library project.
> 
> I dunno. There's probably a cleaner way to go about it, but I also
> feel like the benefit of just having the test in the kernel tree is
> that it can be managed as a unified whole, rather then the test being
> a separate thing and always playing catchup to kernel changes.

I vaguely recall a rant on the list years ago from a Linux bigwhig
saying how we don't support that kind of thing.  But maybe it is my
imagination.  In any case, IMHO running user space tests for chunks of
kernel code can be quite useful.

Thanks,
Richard

Re: [PATCH RFC 0/3] Improve stability of system clock

[Richard Cochran]

On Wed, May 17, 2017 at 04:06:07PM -0700, John Stultz wrote:
> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar  
> wrote:
> > Is there a better way to run the timekeeping code in an userspace
> > application? I suspect it would need something like the Linux Kernel
> > Library project.
> 
> I dunno. There's probably a cleaner way to go about it, but I also
> feel like the benefit of just having the test in the kernel tree is
> that it can be managed as a unified whole, rather then the test being
> a separate thing and always playing catchup to kernel changes.

I vaguely recall a rant on the list years ago from a Linux bigwhig
saying how we don't support that kind of thing.  But maybe it is my
imagination.  In any case, IMHO running user space tests for chunks of
kernel code can be quite useful.

Thanks,
Richard

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Minchan Kim]

Hi Sergey,

On Wed, May 17, 2017 at 06:14:23PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
> 
> On (05/17/17 17:32), Minchan Kim wrote:
> [..]
> > > what we can return now is a `partially updated' data, with some new
> > > and some stale pages. this is quite unlikely to end up anywhere good.
> > > am I wrong?
> > > 
> > > why does `rd block 4' in your case causes Oops? as a worst case scenario?
> > > application does not expect page to be 'all A' at this point. pages are
> > > likely to belong to some mappings/files/etc., and there is likely a data
> > > dependency between them, dunno C++ objects that span across pages or
> > > JPEG images, etc. so returning "new data   new data   stale data" is a bit
> > > fishy.
> > 
> > I thought more about it and start to confuse. :/
> 
> sorry, I'm not sure I see what's the source of your confusion :)
> 
> my point is - we should not let READ succeed if we know that WRITE
> failed. assume JPEG image example,

I don't think we shoul do it. I will write down my thought below. :)

> 
> 
> over-write block 1 aaa->xxx OK
> over-write block 2 bbb->yyy OK
> over-write block 3 ccc->zzz error
> 
> reading that JPEG file
> 
> read block 1 xxx OK
> read block 2 yyy OK
> read block 3 ccc OK   << we should not return OK here. because
>  "xxxyyyccc" is not the correct JPEG file
>  anyway.
> 
> do you agree that telling application that read() succeeded and at
> the same returning corrupted "xxxyyyccc" instead of "xxxyyyzzz" is
> not correct?

I don't agree. I *think* block device is a just dumb device so
zram doesn't need to know about any objects from the upper layer.
What zram should consider is basically read/write success or fail of
IO unit(maybe, BIO).

So if we assume each step from above example is bio unit, I think
it's no problem returns "xxxyyyccc".

What I meant "started confused" was about atomicity, not above
thing.

I think it's okay to return ccc instead of zzz but is it okay
zram to return "000", not "ccc" and "zzz"?
My conclusion is that it's okay now after discussion from one
of my FS friends.

Let's think about it.

FS requests write "aaa" to block 4 and fails by somethings
(H/W failure, S/W failure like ENOMEM). The interface to catch
the failure is the function registered by bio_endio which is
normally handles by AS_EIO by mappint_set_error as well as
PG_error flags of the page. In this case, FS assumes the block
4 can have stale data, not 'zzz' and 'ccc' because the device
was broken in the middle of write some data to a block if
the block device doesn't support atomic write(I guess it's
more popular) so it would be safe to consider the block
has garbage now rather than old value, new value.
(I hope I explain my thought well :/)

Having said that, I think everyone likes block device supports
atomicity(ie, old or new). so I am reluctant to change the
behavior for simple refactoring.

Thanks.

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Minchan Kim]

Hi Sergey,

On Wed, May 17, 2017 at 06:14:23PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
> 
> On (05/17/17 17:32), Minchan Kim wrote:
> [..]
> > > what we can return now is a `partially updated' data, with some new
> > > and some stale pages. this is quite unlikely to end up anywhere good.
> > > am I wrong?
> > > 
> > > why does `rd block 4' in your case causes Oops? as a worst case scenario?
> > > application does not expect page to be 'all A' at this point. pages are
> > > likely to belong to some mappings/files/etc., and there is likely a data
> > > dependency between them, dunno C++ objects that span across pages or
> > > JPEG images, etc. so returning "new data   new data   stale data" is a bit
> > > fishy.
> > 
> > I thought more about it and start to confuse. :/
> 
> sorry, I'm not sure I see what's the source of your confusion :)
> 
> my point is - we should not let READ succeed if we know that WRITE
> failed. assume JPEG image example,

I don't think we shoul do it. I will write down my thought below. :)

> 
> 
> over-write block 1 aaa->xxx OK
> over-write block 2 bbb->yyy OK
> over-write block 3 ccc->zzz error
> 
> reading that JPEG file
> 
> read block 1 xxx OK
> read block 2 yyy OK
> read block 3 ccc OK   << we should not return OK here. because
>  "xxxyyyccc" is not the correct JPEG file
>  anyway.
> 
> do you agree that telling application that read() succeeded and at
> the same returning corrupted "xxxyyyccc" instead of "xxxyyyzzz" is
> not correct?

I don't agree. I *think* block device is a just dumb device so
zram doesn't need to know about any objects from the upper layer.
What zram should consider is basically read/write success or fail of
IO unit(maybe, BIO).

So if we assume each step from above example is bio unit, I think
it's no problem returns "xxxyyyccc".

What I meant "started confused" was about atomicity, not above
thing.

I think it's okay to return ccc instead of zzz but is it okay
zram to return "000", not "ccc" and "zzz"?
My conclusion is that it's okay now after discussion from one
of my FS friends.

Let's think about it.

FS requests write "aaa" to block 4 and fails by somethings
(H/W failure, S/W failure like ENOMEM). The interface to catch
the failure is the function registered by bio_endio which is
normally handles by AS_EIO by mappint_set_error as well as
PG_error flags of the page. In this case, FS assumes the block
4 can have stale data, not 'zzz' and 'ccc' because the device
was broken in the middle of write some data to a block if
the block device doesn't support atomic write(I guess it's
more popular) so it would be safe to consider the block
has garbage now rather than old value, new value.
(I hope I explain my thought well :/)

Having said that, I think everyone likes block device supports
atomicity(ie, old or new). so I am reluctant to change the
behavior for simple refactoring.

Thanks.

[PATCH] drm/stm: add COMPILE_TEST to Kconfig

[Masahiro Yamada]

Add COMPILE_TEST for the compilation test coverage.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/stm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 2c4817f..722ad11 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -1,6 +1,6 @@
 config DRM_STM
tristate "DRM Support for STMicroelectronics SoC Series"
-   depends on DRM && (ARCH_STM32 || ARCH_MULTIPLATFORM)
+   depends on DRM && (ARCH_STM32 || ARCH_MULTIPLATFORM || COMPILE_TEST)
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-- 
2.7.4

[PATCH] drm/stm: add COMPILE_TEST to Kconfig

[Masahiro Yamada]

Add COMPILE_TEST for the compilation test coverage.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/stm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 2c4817f..722ad11 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -1,6 +1,6 @@
 config DRM_STM
tristate "DRM Support for STMicroelectronics SoC Series"
-   depends on DRM && (ARCH_STM32 || ARCH_MULTIPLATFORM)
+   depends on DRM && (ARCH_STM32 || ARCH_MULTIPLATFORM || COMPILE_TEST)
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-- 
2.7.4

[PATCH] drm/amd: include instead of "linux/delay.h"

[Masahiro Yamada]

Use <...> notation to include headers located in include/linux.
While we are here, tweak the includes order a bit to sort them
alphabetically.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c  | 2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
 drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c   | 8 +---
 drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  | 5 +++--
 6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ff4ae3d..963a9e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -22,10 +22,10 @@
  */
 
 #include "pp_debug.h"
-#include "linux/delay.h"
-#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include "cgs_common.h"
 #include "power_state.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index f5e8fda..f6b4dd9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -21,8 +21,8 @@
  *
  */
 
+#include 
 #include 
-#include "linux/delay.h"
 #include "hwmgr.h"
 #include "amd_acpi.h"
 #include "pp_acpi.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8f663ab..581374d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -21,11 +21,11 @@
  *
  */
 #include "pp_debug.h"
+#include 
+#include 
 #include 
 #include 
-#include 
 #include 
-#include "linux/delay.h"
 #include "pp_acpi.h"
 #include "ppatomctrl.h"
 #include "atombios.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 8394955..f4ab81b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -20,10 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
+
+#include 
+#include 
 #include 
 #include 
-#include 
-#include "linux/delay.h"
 
 #include "hwmgr.h"
 #include "amd_powerplay.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index 1f6744a..39c7091 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -20,11 +20,13 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
-#include 
+
+#include 
+#include 
 #include 
 #include 
-#include 
-#include "linux/delay.h"
+#include 
+
 #include "cgs_common.h"
 #include "smu/smu_8_0_d.h"
 #include "smu/smu_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c0d7576..2e954a4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
@@ -20,15 +20,16 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
-#include 
+
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pp_instance.h"
 #include "smumgr.h"
 #include "cgs_common.h"
-#include "linux/delay.h"
 
 MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
 MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");
-- 
2.7.4

[PATCH] drm/amd: include instead of "linux/delay.h"

[Masahiro Yamada]

Use <...> notation to include headers located in include/linux.
While we are here, tweak the includes order a bit to sort them
alphabetically.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c  | 2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
 drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c   | 8 +---
 drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  | 5 +++--
 6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ff4ae3d..963a9e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -22,10 +22,10 @@
  */
 
 #include "pp_debug.h"
-#include "linux/delay.h"
-#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include "cgs_common.h"
 #include "power_state.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index f5e8fda..f6b4dd9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -21,8 +21,8 @@
  *
  */
 
+#include 
 #include 
-#include "linux/delay.h"
 #include "hwmgr.h"
 #include "amd_acpi.h"
 #include "pp_acpi.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8f663ab..581374d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -21,11 +21,11 @@
  *
  */
 #include "pp_debug.h"
+#include 
+#include 
 #include 
 #include 
-#include 
 #include 
-#include "linux/delay.h"
 #include "pp_acpi.h"
 #include "ppatomctrl.h"
 #include "atombios.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 8394955..f4ab81b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -20,10 +20,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
+
+#include 
+#include 
 #include 
 #include 
-#include 
-#include "linux/delay.h"
 
 #include "hwmgr.h"
 #include "amd_powerplay.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index 1f6744a..39c7091 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -20,11 +20,13 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
-#include 
+
+#include 
+#include 
 #include 
 #include 
-#include 
-#include "linux/delay.h"
+#include 
+
 #include "cgs_common.h"
 #include "smu/smu_8_0_d.h"
 #include "smu/smu_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c0d7576..2e954a4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
@@ -20,15 +20,16 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
-#include 
+
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "pp_instance.h"
 #include "smumgr.h"
 #include "cgs_common.h"
-#include "linux/delay.h"
 
 MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
 MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");
-- 
2.7.4

Re: [PATCH 0/3] staging: android: ion: Minor clean ups and fixes

[Sumit Semwal]

Hi Archit,

On 17 May 2017 at 13:45, Archit Taneja  wrote:
> The recent ION clean ups introduced some leftover code that can be
> removed, and a bug that comes up if the call to dma_buf_map_attachment()
> from an importer fails. Fix these.
>
> Archit Taneja (3):
>   staging: android: ion: Remove unused members from ion_buffer
>   staging: android: ion: Remove ION_FLAG_CACHED_NEEDS_SYNC
>   staging: android: ion: Avoid calling free_duped_table() twice
>
Thanks for these patches! Please feel free to add my
Reviewed-by: Sumit Semwal 

>  drivers/staging/android/ion/ion.c  | 14 +++---
>  drivers/staging/android/ion/ion.h  | 14 --
>  drivers/staging/android/uapi/ion.h |  6 --
>  3 files changed, 3 insertions(+), 31 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>

Best,
Sumit.

Re: [PATCH 0/3] staging: android: ion: Minor clean ups and fixes

[Sumit Semwal]

Hi Archit,

On 17 May 2017 at 13:45, Archit Taneja  wrote:
> The recent ION clean ups introduced some leftover code that can be
> removed, and a bug that comes up if the call to dma_buf_map_attachment()
> from an importer fails. Fix these.
>
> Archit Taneja (3):
>   staging: android: ion: Remove unused members from ion_buffer
>   staging: android: ion: Remove ION_FLAG_CACHED_NEEDS_SYNC
>   staging: android: ion: Avoid calling free_duped_table() twice
>
Thanks for these patches! Please feel free to add my
Reviewed-by: Sumit Semwal 

>  drivers/staging/android/ion/ion.c  | 14 +++---
>  drivers/staging/android/ion/ion.h  | 14 --
>  drivers/staging/android/uapi/ion.h |  6 --
>  3 files changed, 3 insertions(+), 31 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>

Best,
Sumit.

Re: [PATCH] scsi: remove useless variable assignment

[James Bottomley]

On Wed, 2017-05-17 at 19:30 -0500, Gustavo A. R. Silva wrote:
> Remove this assignment once the value stored in variable _k_ is
> overwritten after a few lines.
> 
> Addresses-Coverity-ID: 1226927
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/scsi/qlogicfas408.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/scsi/qlogicfas408.c
> b/drivers/scsi/qlogicfas408.c
> index c3a9151..269440a 100644
> --- a/drivers/scsi/qlogicfas408.c
> +++ b/drivers/scsi/qlogicfas408.c
> @@ -329,7 +329,6 @@ static unsigned int ql_pcmd(struct scsi_cmnd
> *cmd)
>*/
>   if ((k = ql_wai(priv)))
>   return (k << 16);
> - k = inb(qbase + 5); /* should be 0x10, bus
> service */

That doesn't look right to me.  inb() is a statement which has an
effect on the I/O device regardless of whether the returned value is
used or discarded.  In this case I think it's being used to clear
pending interrupts, so removing it will likely cause a phase error.

James

Re: [PATCH] scsi: remove useless variable assignment

[James Bottomley]

On Wed, 2017-05-17 at 19:30 -0500, Gustavo A. R. Silva wrote:
> Remove this assignment once the value stored in variable _k_ is
> overwritten after a few lines.
> 
> Addresses-Coverity-ID: 1226927
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/scsi/qlogicfas408.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/scsi/qlogicfas408.c
> b/drivers/scsi/qlogicfas408.c
> index c3a9151..269440a 100644
> --- a/drivers/scsi/qlogicfas408.c
> +++ b/drivers/scsi/qlogicfas408.c
> @@ -329,7 +329,6 @@ static unsigned int ql_pcmd(struct scsi_cmnd
> *cmd)
>*/
>   if ((k = ql_wai(priv)))
>   return (k << 16);
> - k = inb(qbase + 5); /* should be 0x10, bus
> service */

That doesn't look right to me.  inb() is a statement which has an
effect on the I/O device regardless of whether the returned value is
used or discarded.  In this case I think it's being used to clear
pending interrupts, so removing it will likely cause a phase error.

James

Re: [PATCH 4/4] mtd: mchp23k256: Add support for mchp23lcv1024

[Chris Packham]

On 17/05/17 17:39, Chris Packham wrote:
> The mchp23lcv1024 is software compatible with the mchp23k256, the
> only difference (from a software point of view) is the size. There
> is no way to detect the size so we must be told via a Device Tree.


I've just noticed that another difference between the 2 chips is 16-bit 
vs 24-bit addressing. So that will also need to be handled.


> 
> Signed-off-by: Chris Packham 
> ---
>   .../bindings/mtd/microchip,mchp23k256.txt   |  2 +-
>   drivers/mtd/devices/mchp23k256.c| 21 
> +++--
>   2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
> b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
> index 25e5ad38b0f0..7328eb92a03c 100644
> --- a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
> +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
> @@ -3,7 +3,7 @@
>   Required properties:
>   - #address-cells, #size-cells : Must be present if the device has sub-nodes
> representing partitions.
> -- compatible : Must be "microchip,mchp23k256"
> +- compatible : Must be one of "microchip,mchp23k256" or 
> "microchip,mchp23lcv1024"
>   - reg : Chip-Select number
>   - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate 
> at
>   
> diff --git a/drivers/mtd/devices/mchp23k256.c 
> b/drivers/mtd/devices/mchp23k256.c
> index 02c6b9dcbd3e..d1eba587633c 100644
> --- a/drivers/mtd/devices/mchp23k256.c
> +++ b/drivers/mtd/devices/mchp23k256.c
> @@ -21,6 +21,8 @@
>   #include 
>   #include 
>   
> +enum chips { mchp23k256, mchp23lcv1024 };
> +
>   struct mchp23k256_flash {
>   struct spi_device   *spi;
>   struct mutexlock;
> @@ -128,6 +130,7 @@ static int mchp23k256_probe(struct spi_device *spi)
>   struct mchp23k256_flash *flash;
>   struct flash_platform_data *data;
>   int err;
> + enum chips chip;
>   
>   flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
>   if (!flash)
> @@ -143,15 +146,28 @@ static int mchp23k256_probe(struct spi_device *spi)
>   
>   data = dev_get_platdata(>dev);
>   
> + if (spi->dev.of_node)
> + chip = (enum chips)of_device_get_match_data(>dev);
> + else
> + chip = mchp23k256;
> +
>   mtd_set_of_node(>mtd, spi->dev.of_node);
>   flash->mtd.dev.parent   = >dev;
>   flash->mtd.type = MTD_RAM;
>   flash->mtd.flags= MTD_CAP_RAM;
>   flash->mtd.writesize= 1;
> - flash->mtd.size = SZ_32K;
>   flash->mtd._read= mchp23k256_read;
>   flash->mtd._write   = mchp23k256_write;
>   
> + switch (chip){
> + case mchp23lcv1024:
> + flash->mtd.size = SZ_128K;
> + break;
> + default:
> + flash->mtd.size = SZ_32K;
> + break;
> + }
> +
>   flash->mtd.erasesize = PAGE_SIZE;
>   while (flash->mtd.size & (flash->mtd.erasesize - 1))
>   flash->mtd.erasesize >>= 1;
> @@ -172,7 +188,8 @@ static int mchp23k256_remove(struct spi_device *spi)
>   }
>   
>   static const struct of_device_id mchp23k256_of_table[] = {
> - { .compatible = "microchip,mchp23k256" },
> + { .compatible = "microchip,mchp23k256", .data = (void *)mchp23k256 },
> + { .compatible = "microchip,mchp23lcv1024", .data = (void 
> *)mchp23lcv1024 },
>   {}
>   };
>   MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
> 

Re: [PATCH 4/4] mtd: mchp23k256: Add support for mchp23lcv1024

[Chris Packham]

On 17/05/17 17:39, Chris Packham wrote:
> The mchp23lcv1024 is software compatible with the mchp23k256, the
> only difference (from a software point of view) is the size. There
> is no way to detect the size so we must be told via a Device Tree.


I've just noticed that another difference between the 2 chips is 16-bit 
vs 24-bit addressing. So that will also need to be handled.


> 
> Signed-off-by: Chris Packham 
> ---
>   .../bindings/mtd/microchip,mchp23k256.txt   |  2 +-
>   drivers/mtd/devices/mchp23k256.c| 21 
> +++--
>   2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt 
> b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
> index 25e5ad38b0f0..7328eb92a03c 100644
> --- a/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
> +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp23k256.txt
> @@ -3,7 +3,7 @@
>   Required properties:
>   - #address-cells, #size-cells : Must be present if the device has sub-nodes
> representing partitions.
> -- compatible : Must be "microchip,mchp23k256"
> +- compatible : Must be one of "microchip,mchp23k256" or 
> "microchip,mchp23lcv1024"
>   - reg : Chip-Select number
>   - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate 
> at
>   
> diff --git a/drivers/mtd/devices/mchp23k256.c 
> b/drivers/mtd/devices/mchp23k256.c
> index 02c6b9dcbd3e..d1eba587633c 100644
> --- a/drivers/mtd/devices/mchp23k256.c
> +++ b/drivers/mtd/devices/mchp23k256.c
> @@ -21,6 +21,8 @@
>   #include 
>   #include 
>   
> +enum chips { mchp23k256, mchp23lcv1024 };
> +
>   struct mchp23k256_flash {
>   struct spi_device   *spi;
>   struct mutexlock;
> @@ -128,6 +130,7 @@ static int mchp23k256_probe(struct spi_device *spi)
>   struct mchp23k256_flash *flash;
>   struct flash_platform_data *data;
>   int err;
> + enum chips chip;
>   
>   flash = devm_kzalloc(>dev, sizeof(*flash), GFP_KERNEL);
>   if (!flash)
> @@ -143,15 +146,28 @@ static int mchp23k256_probe(struct spi_device *spi)
>   
>   data = dev_get_platdata(>dev);
>   
> + if (spi->dev.of_node)
> + chip = (enum chips)of_device_get_match_data(>dev);
> + else
> + chip = mchp23k256;
> +
>   mtd_set_of_node(>mtd, spi->dev.of_node);
>   flash->mtd.dev.parent   = >dev;
>   flash->mtd.type = MTD_RAM;
>   flash->mtd.flags= MTD_CAP_RAM;
>   flash->mtd.writesize= 1;
> - flash->mtd.size = SZ_32K;
>   flash->mtd._read= mchp23k256_read;
>   flash->mtd._write   = mchp23k256_write;
>   
> + switch (chip){
> + case mchp23lcv1024:
> + flash->mtd.size = SZ_128K;
> + break;
> + default:
> + flash->mtd.size = SZ_32K;
> + break;
> + }
> +
>   flash->mtd.erasesize = PAGE_SIZE;
>   while (flash->mtd.size & (flash->mtd.erasesize - 1))
>   flash->mtd.erasesize >>= 1;
> @@ -172,7 +188,8 @@ static int mchp23k256_remove(struct spi_device *spi)
>   }
>   
>   static const struct of_device_id mchp23k256_of_table[] = {
> - { .compatible = "microchip,mchp23k256" },
> + { .compatible = "microchip,mchp23k256", .data = (void *)mchp23k256 },
> + { .compatible = "microchip,mchp23lcv1024", .data = (void 
> *)mchp23lcv1024 },
>   {}
>   };
>   MODULE_DEVICE_TABLE(of, mchp23k256_of_table);
> 

Re: [PATCH v2 15/29] drm/vc4: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Hi Daniel,


2017-05-17 21:40 GMT+09:00 Daniel Vetter :
> On Mon, Apr 24, 2017 at 01:50:33PM +0900, Masahiro Yamada wrote:
>> Include  instead of relative path from include/drm, then
>> remove the -Iinclude/drm compiler flag.
>>
>> While we are here, use <...> instead of "..." for include/linux/*.h
>> headers too.
>>
>> Signed-off-by: Masahiro Yamada 
>
> This one doesn't apply anymore cleanly. Can you pls rebase onto latest
> linux-next? I'm going through the remaining patches, up to this all merged
> to drm-misc-next.
>
> Thanks, Daniel

I rebased this one as you suggested
and send v3 for the rest of the series.


Please note I am also adding

12/16 : drm/stm: remove unneeded -Iinclude/drm compiler flag

because a new user of -Iinclude/drm has appeared.


Thanks!




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 15/29] drm/vc4: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Hi Daniel,


2017-05-17 21:40 GMT+09:00 Daniel Vetter :
> On Mon, Apr 24, 2017 at 01:50:33PM +0900, Masahiro Yamada wrote:
>> Include  instead of relative path from include/drm, then
>> remove the -Iinclude/drm compiler flag.
>>
>> While we are here, use <...> instead of "..." for include/linux/*.h
>> headers too.
>>
>> Signed-off-by: Masahiro Yamada 
>
> This one doesn't apply anymore cleanly. Can you pls rebase onto latest
> linux-next? I'm going through the remaining patches, up to this all merged
> to drm-misc-next.
>
> Thanks, Daniel

I rebased this one as you suggested
and send v3 for the rest of the series.


Please note I am also adding

12/16 : drm/stm: remove unneeded -Iinclude/drm compiler flag

because a new user of -Iinclude/drm has appeared.


Thanks!




-- 
Best Regards
Masahiro Yamada

[PATCH v3 12/16] drm/stm: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/stm/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index e114d45..a09ecf4 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 stm-drm-y := \
drv.o \
ltdc.o
-- 
2.7.4

[PATCH v3 07/16] drm/mga: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/mga/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mga/Makefile b/drivers/gpu/drm/mga/Makefile
index 6068478..49e972c 100644
--- a/drivers/gpu/drm/mga/Makefile
+++ b/drivers/gpu/drm/mga/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 mga-y := mga_drv.o mga_dma.o mga_state.o mga_warp.o mga_irq.o
 
 mga-$(CONFIG_COMPAT) += mga_ioc32.o
-- 
2.7.4

[PATCH v3 05/16] drm/i810: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/i810/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i810/Makefile b/drivers/gpu/drm/i810/Makefile
index 43844ec..639f859 100644
--- a/drivers/gpu/drm/i810/Makefile
+++ b/drivers/gpu/drm/i810/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 i810-y := i810_drv.o i810_dma.o
 
 obj-$(CONFIG_DRM_I810) += i810.o
-- 
2.7.4

[PATCH v3 12/16] drm/stm: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/stm/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index e114d45..a09ecf4 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 stm-drm-y := \
drv.o \
ltdc.o
-- 
2.7.4

[PATCH v3 07/16] drm/mga: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/mga/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mga/Makefile b/drivers/gpu/drm/mga/Makefile
index 6068478..49e972c 100644
--- a/drivers/gpu/drm/mga/Makefile
+++ b/drivers/gpu/drm/mga/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 mga-y := mga_drv.o mga_dma.o mga_state.o mga_warp.o mga_irq.o
 
 mga-$(CONFIG_COMPAT) += mga_ioc32.o
-- 
2.7.4

[PATCH v3 05/16] drm/i810: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/i810/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i810/Makefile b/drivers/gpu/drm/i810/Makefile
index 43844ec..639f859 100644
--- a/drivers/gpu/drm/i810/Makefile
+++ b/drivers/gpu/drm/i810/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 i810-y := i810_drv.o i810_dma.o
 
 obj-$(CONFIG_DRM_I810) += i810.o
-- 
2.7.4

[PATCH v3 08/16] drm/omap: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/omapdrm/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm/Makefile
index 48b7b75..b391be7 100644
--- a/drivers/gpu/drm/omapdrm/Makefile
+++ b/drivers/gpu/drm/omapdrm/Makefile
@@ -6,7 +6,6 @@
 obj-y += dss/
 obj-y += displays/
 
-ccflags-y := -Iinclude/drm
 omapdrm-y := omap_drv.o \
omap_irq.o \
omap_debugfs.o \
-- 
2.7.4

[PATCH v3 16/16] drm/via: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/via/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index d59e258..751fa8b 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 via-y:= via_irq.o via_drv.o via_map.o via_mm.o via_dma.o via_verifier.o 
via_video.o via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
-- 
2.7.4

[PATCH v3 08/16] drm/omap: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/omapdrm/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/Makefile b/drivers/gpu/drm/omapdrm/Makefile
index 48b7b75..b391be7 100644
--- a/drivers/gpu/drm/omapdrm/Makefile
+++ b/drivers/gpu/drm/omapdrm/Makefile
@@ -6,7 +6,6 @@
 obj-y += dss/
 obj-y += displays/
 
-ccflags-y := -Iinclude/drm
 omapdrm-y := omap_drv.o \
omap_irq.o \
omap_debugfs.o \
-- 
2.7.4

[PATCH v3 16/16] drm/via: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/via/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index d59e258..751fa8b 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 via-y:= via_irq.o via_drv.o via_map.o via_mm.o via_dma.o via_verifier.o 
via_video.o via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
-- 
2.7.4

[PATCH v3 09/16] drm/r128: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/r128/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/r128/Makefile b/drivers/gpu/drm/r128/Makefile
index 1cc72ae..1a6700e 100644
--- a/drivers/gpu/drm/r128/Makefile
+++ b/drivers/gpu/drm/r128/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 r128-y   := r128_drv.o r128_cce.o r128_state.o r128_irq.o
 
 r128-$(CONFIG_COMPAT)   += r128_ioc32.o
-- 
2.7.4

[PATCH v3 02/16] drm/virtio: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/virtio/Makefile  |  2 --
 drivers/gpu/drm/virtio/virtgpu_debugfs.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c |  4 ++--
 drivers/gpu/drm/virtio/virtgpu_drv.h |  8 
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   |  5 +++--
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 10 +-
 6 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 3fb8eac..7684f61 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -2,8 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
-
 virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c 
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index f51240a..73dc990 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -24,8 +24,8 @@
  */
 
 #include 
+#include 
 
-#include "drmP.h"
 #include "virtgpu_drv.h"
 
 static int
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 2d29b01..63d35c7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -29,8 +29,8 @@
 #include 
 #include 
 #include 
-#include "drmP.h"
-#include "drm/drm.h"
+#include 
+#include 
 
 #include "virtgpu_drv.h"
 static struct drm_driver driver;
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 1328185..3a66abb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -36,10 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #define DRIVER_NAME "virtio_gpu"
 #define DRIVER_DESC "virtio GPU"
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 61f3a96..06cb16d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -26,9 +26,10 @@
  */
 
 #include 
-#include "virtgpu_drv.h"
 #include 
-#include "ttm/ttm_execbuf_util.h"
+#include 
+
+#include "virtgpu_drv.h"
 
 static void convert_to_hw_box(struct virtio_gpu_box *dst,
  const struct drm_virtgpu_3d_box *src)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c 
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index 4e8e27d..c1f2af4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -25,11 +25,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4

[PATCH v3 09/16] drm/r128: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/r128/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/r128/Makefile b/drivers/gpu/drm/r128/Makefile
index 1cc72ae..1a6700e 100644
--- a/drivers/gpu/drm/r128/Makefile
+++ b/drivers/gpu/drm/r128/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 r128-y   := r128_drv.o r128_cce.o r128_state.o r128_irq.o
 
 r128-$(CONFIG_COMPAT)   += r128_ioc32.o
-- 
2.7.4

[PATCH v3 02/16] drm/virtio: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/virtio/Makefile  |  2 --
 drivers/gpu/drm/virtio/virtgpu_debugfs.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c |  4 ++--
 drivers/gpu/drm/virtio/virtgpu_drv.h |  8 
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   |  5 +++--
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 10 +-
 6 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 3fb8eac..7684f61 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -2,8 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
-
 virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c 
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index f51240a..73dc990 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -24,8 +24,8 @@
  */
 
 #include 
+#include 
 
-#include "drmP.h"
 #include "virtgpu_drv.h"
 
 static int
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 2d29b01..63d35c7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -29,8 +29,8 @@
 #include 
 #include 
 #include 
-#include "drmP.h"
-#include "drm/drm.h"
+#include 
+#include 
 
 #include "virtgpu_drv.h"
 static struct drm_driver driver;
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 1328185..3a66abb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -36,10 +36,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #define DRIVER_NAME "virtio_gpu"
 #define DRIVER_DESC "virtio GPU"
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 61f3a96..06cb16d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -26,9 +26,10 @@
  */
 
 #include 
-#include "virtgpu_drv.h"
 #include 
-#include "ttm/ttm_execbuf_util.h"
+#include 
+
+#include "virtgpu_drv.h"
 
 static void convert_to_hw_box(struct virtio_gpu_box *dst,
  const struct drm_virtgpu_3d_box *src)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c 
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index 4e8e27d..c1f2af4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -25,11 +25,11 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.7.4

[PATCH v3 14/16] drm/udl: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/udl/Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
index 195bcac..36f2e82 100644
--- a/drivers/gpu/drm/udl/Makefile
+++ b/drivers/gpu/drm/udl/Makefile
@@ -1,6 +1,3 @@
-
-ccflags-y := -Iinclude/drm
-
 udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o 
udl_fb.o udl_transfer.o udl_gem.o udl_dmabuf.o
 
 obj-$(CONFIG_DRM_UDL) := udl.o
-- 
2.7.4

[PATCH v3 06/16] drm/i2c: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/i2c/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..a77acfc 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
 
-- 
2.7.4

[PATCH v3 04/16] drm/gma500: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/gma500/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 190e55f..c1c8dc1 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -1,7 +1,6 @@
 #
 #  KMS driver for the GMA500
 #
-ccflags-y += -I$(srctree)/include/drm
 
 gma500_gfx-y += \
  accel_2d.o \
-- 
2.7.4

[PATCH v3 14/16] drm/udl: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/udl/Makefile | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
index 195bcac..36f2e82 100644
--- a/drivers/gpu/drm/udl/Makefile
+++ b/drivers/gpu/drm/udl/Makefile
@@ -1,6 +1,3 @@
-
-ccflags-y := -Iinclude/drm
-
 udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o 
udl_fb.o udl_transfer.o udl_gem.o udl_dmabuf.o
 
 obj-$(CONFIG_DRM_UDL) := udl.o
-- 
2.7.4

[PATCH v3 06/16] drm/i2c: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/i2c/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..a77acfc 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
 
-- 
2.7.4

[PATCH v3 04/16] drm/gma500: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/gma500/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 190e55f..c1c8dc1 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -1,7 +1,6 @@
 #
 #  KMS driver for the GMA500
 #
-ccflags-y += -I$(srctree)/include/drm
 
 gma500_gfx-y += \
  accel_2d.o \
-- 
2.7.4

[PATCH v3 15/16] drm/vgem: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/vgem/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
index bfcdea1..cb5d413 100644
--- a/drivers/gpu/drm/vgem/Makefile
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -1,4 +1,3 @@
-ccflags-y := -Iinclude/drm
 vgem-y := vgem_drv.o vgem_fence.o
 
 obj-$(CONFIG_DRM_VGEM) += vgem.o
-- 
2.7.4

[PATCH v3 15/16] drm/vgem: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/vgem/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
index bfcdea1..cb5d413 100644
--- a/drivers/gpu/drm/vgem/Makefile
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -1,4 +1,3 @@
-ccflags-y := -Iinclude/drm
 vgem-y := vgem_drv.o vgem_fence.o
 
 obj-$(CONFIG_DRM_VGEM) += vgem.o
-- 
2.7.4

[PATCH v3 10/16] drm/savage: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/savage/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/savage/Makefile b/drivers/gpu/drm/savage/Makefile
index d8f84ac..cfd436b 100644
--- a/drivers/gpu/drm/savage/Makefile
+++ b/drivers/gpu/drm/savage/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y = -Iinclude/drm
 savage-y := savage_drv.o savage_bci.o savage_state.o
 
 obj-$(CONFIG_DRM_SAVAGE)+= savage.o
-- 
2.7.4

[PATCH v3 00/16] gpu/drm: remove -Iinclude/drm compiler flags from Makefile

[Masahiro Yamada]

Many Makefiles needed to add -Iinclude/drm as an include path,
but the right thing to do is to include headers in the form
  #include 

This series fixes the source files, then rip off -Iinclude/drm flags.

V3: rebased on commit bb2af9bda33 (drm-misc-next)


Masahiro Yamada (16):
  drm/vc4: fix include notation and remove -Iinclude/drm flag
  drm/virtio: fix include notation and remove -Iinclude/drm flag
  drm/vmwgfx: fix include notation and remove -Iinclude/drm flag
  drm/gma500: remove unneeded -Iinclude/drm compiler flag
  drm/i810: remove unneeded -Iinclude/drm compiler flag
  drm/i2c: remove unneeded -Iinclude/drm compiler flag
  drm/mga: remove unneeded -Iinclude/drm compiler flag
  drm/omap: remove unneeded -Iinclude/drm compiler flag
  drm/r128: remove unneeded -Iinclude/drm compiler flag
  drm/savage: remove unneeded -Iinclude/drm compiler flag
  drm/sis: remove unneeded -Iinclude/drm compiler flag
  drm/stm: remove unneeded -Iinclude/drm compiler flag
  drm/tdfx: remove unneeded -Iinclude/drm compiler flag
  drm/udl: remove unneeded -Iinclude/drm compiler flag
  drm/vgem: remove unneeded -Iinclude/drm compiler flag
  drm/via: remove unneeded -Iinclude/drm compiler flag

 drivers/gpu/drm/gma500/Makefile  |  1 -
 drivers/gpu/drm/i2c/Makefile |  2 --
 drivers/gpu/drm/i810/Makefile|  1 -
 drivers/gpu/drm/mga/Makefile |  1 -
 drivers/gpu/drm/omapdrm/Makefile |  1 -
 drivers/gpu/drm/r128/Makefile|  1 -
 drivers/gpu/drm/savage/Makefile  |  1 -
 drivers/gpu/drm/sis/Makefile |  1 -
 drivers/gpu/drm/stm/Makefile |  2 --
 drivers/gpu/drm/tdfx/Makefile|  1 -
 drivers/gpu/drm/udl/Makefile |  3 ---
 drivers/gpu/drm/vc4/Makefile |  2 --
 drivers/gpu/drm/vc4/vc4_crtc.c   | 14 +++---
 drivers/gpu/drm/vc4/vc4_dpi.c| 16 
 drivers/gpu/drm/vc4/vc4_drv.c|  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h|  6 ++
 drivers/gpu/drm/vc4/vc4_dsi.c| 28 ++--
 drivers/gpu/drm/vc4/vc4_hdmi.c   | 30 +++---
 drivers/gpu/drm/vc4/vc4_hvs.c|  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c| 12 ++--
 drivers/gpu/drm/vc4/vc4_plane.c  |  9 +
 drivers/gpu/drm/vc4/vc4_v3d.c|  6 +++---
 drivers/gpu/drm/vgem/Makefile|  1 -
 drivers/gpu/drm/via/Makefile |  1 -
 drivers/gpu/drm/virtio/Makefile  |  2 --
 drivers/gpu/drm/virtio/virtgpu_debugfs.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c |  4 ++--
 drivers/gpu/drm/virtio/virtgpu_drv.h |  8 
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   |  5 +++--
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 10 +-
 drivers/gpu/drm/vmwgfx/Makefile  |  3 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c   |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c  |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |  3 ++-
 37 files changed, 88 insertions(+), 107 deletions(-)

-- 
2.7.4

[PATCH v3 10/16] drm/savage: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/savage/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/savage/Makefile b/drivers/gpu/drm/savage/Makefile
index d8f84ac..cfd436b 100644
--- a/drivers/gpu/drm/savage/Makefile
+++ b/drivers/gpu/drm/savage/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y = -Iinclude/drm
 savage-y := savage_drv.o savage_bci.o savage_state.o
 
 obj-$(CONFIG_DRM_SAVAGE)+= savage.o
-- 
2.7.4

[PATCH v3 00/16] gpu/drm: remove -Iinclude/drm compiler flags from Makefile

[Masahiro Yamada]

Many Makefiles needed to add -Iinclude/drm as an include path,
but the right thing to do is to include headers in the form
  #include 

This series fixes the source files, then rip off -Iinclude/drm flags.

V3: rebased on commit bb2af9bda33 (drm-misc-next)


Masahiro Yamada (16):
  drm/vc4: fix include notation and remove -Iinclude/drm flag
  drm/virtio: fix include notation and remove -Iinclude/drm flag
  drm/vmwgfx: fix include notation and remove -Iinclude/drm flag
  drm/gma500: remove unneeded -Iinclude/drm compiler flag
  drm/i810: remove unneeded -Iinclude/drm compiler flag
  drm/i2c: remove unneeded -Iinclude/drm compiler flag
  drm/mga: remove unneeded -Iinclude/drm compiler flag
  drm/omap: remove unneeded -Iinclude/drm compiler flag
  drm/r128: remove unneeded -Iinclude/drm compiler flag
  drm/savage: remove unneeded -Iinclude/drm compiler flag
  drm/sis: remove unneeded -Iinclude/drm compiler flag
  drm/stm: remove unneeded -Iinclude/drm compiler flag
  drm/tdfx: remove unneeded -Iinclude/drm compiler flag
  drm/udl: remove unneeded -Iinclude/drm compiler flag
  drm/vgem: remove unneeded -Iinclude/drm compiler flag
  drm/via: remove unneeded -Iinclude/drm compiler flag

 drivers/gpu/drm/gma500/Makefile  |  1 -
 drivers/gpu/drm/i2c/Makefile |  2 --
 drivers/gpu/drm/i810/Makefile|  1 -
 drivers/gpu/drm/mga/Makefile |  1 -
 drivers/gpu/drm/omapdrm/Makefile |  1 -
 drivers/gpu/drm/r128/Makefile|  1 -
 drivers/gpu/drm/savage/Makefile  |  1 -
 drivers/gpu/drm/sis/Makefile |  1 -
 drivers/gpu/drm/stm/Makefile |  2 --
 drivers/gpu/drm/tdfx/Makefile|  1 -
 drivers/gpu/drm/udl/Makefile |  3 ---
 drivers/gpu/drm/vc4/Makefile |  2 --
 drivers/gpu/drm/vc4/vc4_crtc.c   | 14 +++---
 drivers/gpu/drm/vc4/vc4_dpi.c| 16 
 drivers/gpu/drm/vc4/vc4_drv.c|  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h|  6 ++
 drivers/gpu/drm/vc4/vc4_dsi.c| 28 ++--
 drivers/gpu/drm/vc4/vc4_hdmi.c   | 30 +++---
 drivers/gpu/drm/vc4/vc4_hvs.c|  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c| 12 ++--
 drivers/gpu/drm/vc4/vc4_plane.c  |  9 +
 drivers/gpu/drm/vc4/vc4_v3d.c|  6 +++---
 drivers/gpu/drm/vgem/Makefile|  1 -
 drivers/gpu/drm/via/Makefile |  1 -
 drivers/gpu/drm/virtio/Makefile  |  2 --
 drivers/gpu/drm/virtio/virtgpu_debugfs.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c |  4 ++--
 drivers/gpu/drm/virtio/virtgpu_drv.h |  8 
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   |  5 +++--
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 10 +-
 drivers/gpu/drm/vmwgfx/Makefile  |  3 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c   |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c  |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c  |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c   |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |  3 ++-
 37 files changed, 88 insertions(+), 107 deletions(-)

-- 
2.7.4

[PATCH v3 01/16] drm/vc4: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

While we are here, use <...> instead of "..." for include/linux/*.h
and include/sound/*.h headers too.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Rebase

 drivers/gpu/drm/vc4/Makefile|  2 --
 drivers/gpu/drm/vc4/vc4_crtc.c  | 14 +++---
 drivers/gpu/drm/vc4/vc4_dpi.c   | 16 
 drivers/gpu/drm/vc4/vc4_drv.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h   |  6 ++
 drivers/gpu/drm/vc4/vc4_dsi.c   | 28 ++--
 drivers/gpu/drm/vc4/vc4_hdmi.c  | 30 +++---
 drivers/gpu/drm/vc4/vc4_hvs.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c   | 12 ++--
 drivers/gpu/drm/vc4/vc4_plane.c |  9 +
 drivers/gpu/drm/vc4/vc4_v3d.c   |  6 +++---
 11 files changed, 62 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index ab687fb..25bd5d3 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 # Please keep these build lists sorted!
 
 # core driver code
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 1b4dbe9..0bfc4d8 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -32,13 +32,13 @@
  * ones that set the clock.
  */
 
-#include "drm_atomic.h"
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "linux/clk.h"
-#include "drm_fb_cma_helper.h"
-#include "linux/component.h"
-#include "linux/of_device.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c6d7039..39d6808 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -22,14 +22,14 @@
  * ALT2 function.
  */
 
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
-#include "drm_panel.h"
-#include "linux/clk.h"
-#include "linux/component.h"
-#include "linux/of_graph.h"
-#include "linux/of_platform.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 8639749..136bb42 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include "drm_fb_cma_helper.h"
+#include 
 #include 
 
 #include "uapi/drm/vc4_drm.h"
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 5ba2813..a97556f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -6,12 +6,10 @@
  * published by the Free Software Foundation.
  */
 
-#include "drmP.h"
-#include "drm_gem_cma_helper.h"
-#include "drm_gem_cma_helper.h"
-
 #include 
+#include 
 #include 
+#include 
 
 struct vc4_dev {
struct drm_device *dev;
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index fdb3877..0ef41df 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -29,20 +29,20 @@
  * hopefully present.
  */
 
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
-#include "drm_mipi_dsi.h"
-#include "drm_panel.h"
-#include "linux/clk.h"
-#include "linux/clk-provider.h"
-#include "linux/completion.h"
-#include "linux/component.h"
-#include "linux/dmaengine.h"
-#include "linux/i2c.h"
-#include "linux/of_address.h"
-#include "linux/of_platform.h"
-#include "linux/pm_runtime.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 3c2723f6..ed63d4e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -42,21 +42,21 @@
  * encoder block has CEC support.
  */
 
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
-#include "linux/clk.h"
-#include "linux/component.h"
-#include "linux/i2c.h"
-#include "linux/of_address.h"
-#include "linux/of_gpio.h"
-#include "linux/of_platform.h"
-#include "linux/pm_runtime.h"
-#include "linux/rational.h"
-#include "sound/dmaengine_pcm.h"
-#include "sound/pcm_drm_eld.h"
-#include "sound/pcm_params.h"
-#include "sound/soc.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index fd421ba..2b62fc5 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -22,7 +22,7 @@
 

[PATCH v3 13/16] drm/tdfx: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/tdfx/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tdfx/Makefile b/drivers/gpu/drm/tdfx/Makefile
index 0379f29..74bd4ae3 100644
--- a/drivers/gpu/drm/tdfx/Makefile
+++ b/drivers/gpu/drm/tdfx/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 tdfx-y := tdfx_drv.o
 
 obj-$(CONFIG_DRM_TDFX) += tdfx.o
-- 
2.7.4

[PATCH v3 01/16] drm/vc4: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

While we are here, use <...> instead of "..." for include/linux/*.h
and include/sound/*.h headers too.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Rebase

 drivers/gpu/drm/vc4/Makefile|  2 --
 drivers/gpu/drm/vc4/vc4_crtc.c  | 14 +++---
 drivers/gpu/drm/vc4/vc4_dpi.c   | 16 
 drivers/gpu/drm/vc4/vc4_drv.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h   |  6 ++
 drivers/gpu/drm/vc4/vc4_dsi.c   | 28 ++--
 drivers/gpu/drm/vc4/vc4_hdmi.c  | 30 +++---
 drivers/gpu/drm/vc4/vc4_hvs.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c   | 12 ++--
 drivers/gpu/drm/vc4/vc4_plane.c |  9 +
 drivers/gpu/drm/vc4/vc4_v3d.c   |  6 +++---
 11 files changed, 62 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index ab687fb..25bd5d3 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -1,5 +1,3 @@
-ccflags-y := -Iinclude/drm
-
 # Please keep these build lists sorted!
 
 # core driver code
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 1b4dbe9..0bfc4d8 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -32,13 +32,13 @@
  * ones that set the clock.
  */
 
-#include "drm_atomic.h"
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "linux/clk.h"
-#include "drm_fb_cma_helper.h"
-#include "linux/component.h"
-#include "linux/of_device.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c6d7039..39d6808 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -22,14 +22,14 @@
  * ALT2 function.
  */
 
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
-#include "drm_panel.h"
-#include "linux/clk.h"
-#include "linux/component.h"
-#include "linux/of_graph.h"
-#include "linux/of_platform.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 8639749..136bb42 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include "drm_fb_cma_helper.h"
+#include 
 #include 
 
 #include "uapi/drm/vc4_drm.h"
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 5ba2813..a97556f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -6,12 +6,10 @@
  * published by the Free Software Foundation.
  */
 
-#include "drmP.h"
-#include "drm_gem_cma_helper.h"
-#include "drm_gem_cma_helper.h"
-
 #include 
+#include 
 #include 
+#include 
 
 struct vc4_dev {
struct drm_device *dev;
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index fdb3877..0ef41df 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -29,20 +29,20 @@
  * hopefully present.
  */
 
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
-#include "drm_mipi_dsi.h"
-#include "drm_panel.h"
-#include "linux/clk.h"
-#include "linux/clk-provider.h"
-#include "linux/completion.h"
-#include "linux/component.h"
-#include "linux/dmaengine.h"
-#include "linux/i2c.h"
-#include "linux/of_address.h"
-#include "linux/of_platform.h"
-#include "linux/pm_runtime.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 3c2723f6..ed63d4e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -42,21 +42,21 @@
  * encoder block has CEC support.
  */
 
-#include "drm_atomic_helper.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
-#include "linux/clk.h"
-#include "linux/component.h"
-#include "linux/i2c.h"
-#include "linux/of_address.h"
-#include "linux/of_gpio.h"
-#include "linux/of_platform.h"
-#include "linux/pm_runtime.h"
-#include "linux/rational.h"
-#include "sound/dmaengine_pcm.h"
-#include "sound/pcm_drm_eld.h"
-#include "sound/pcm_params.h"
-#include "sound/soc.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index fd421ba..2b62fc5 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -22,7 +22,7 @@
  * each CRTC.
  */
 
-#include 

[PATCH v3 13/16] drm/tdfx: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/tdfx/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tdfx/Makefile b/drivers/gpu/drm/tdfx/Makefile
index 0379f29..74bd4ae3 100644
--- a/drivers/gpu/drm/tdfx/Makefile
+++ b/drivers/gpu/drm/tdfx/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y := -Iinclude/drm
 tdfx-y := tdfx_drv.o
 
 obj-$(CONFIG_DRM_TDFX) += tdfx.o
-- 
2.7.4

[PATCH v3 11/16] drm/sis: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/sis/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sis/Makefile b/drivers/gpu/drm/sis/Makefile
index 441c061..7bf4c13 100644
--- a/drivers/gpu/drm/sis/Makefile
+++ b/drivers/gpu/drm/sis/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y = -Iinclude/drm
 sis-y := sis_drv.o sis_mm.o
 
 obj-$(CONFIG_DRM_SIS)   += sis.o
-- 
2.7.4

[PATCH v3 03/16] drm/vmwgfx: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/vmwgfx/Makefile | 3 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 ++-
 7 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index aac17a6..a365330 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,6 +1,3 @@
-
-ccflags-y := -Iinclude/drm
-
 vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_buffer.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 77cb7c6..99a7f4a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -25,8 +25,9 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
-#include "ttm/ttm_bo_api.h"
 
 /*
  * Size of inline command buffers. Try to make sure that a page size is a
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 443d1ed..bcc6d41 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -25,10 +25,11 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_binding.h"
-#include "ttm/ttm_placement.h"
 
 struct vmw_user_context {
struct ttm_base_object base;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index 265c81e..6c026d7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -30,9 +30,10 @@
  * whenever the backing MOB is evicted.
  */
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
-#include 
 #include "vmwgfx_so.h"
 
 /**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index e57a0ba..6063c96 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include "drmP.h"
+#include 
 #include "vmwgfx_msg.h"
 
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
index 92f8b1d..68f135c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
@@ -25,10 +25,11 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_binding.h"
-#include "ttm/ttm_placement.h"
 
 struct vmw_shader {
struct vmw_resource res;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 7681341..5900cff 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -25,11 +25,12 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_so.h"
 #include "vmwgfx_binding.h"
-#include 
 #include "device_include/svga3d_surfacedefs.h"
 
 
-- 
2.7.4

[PATCH v3 11/16] drm/sis: remove unneeded -Iinclude/drm compiler flag

[Masahiro Yamada]

With the include directives under include/drm/ fixed, this flag is
no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/sis/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sis/Makefile b/drivers/gpu/drm/sis/Makefile
index 441c061..7bf4c13 100644
--- a/drivers/gpu/drm/sis/Makefile
+++ b/drivers/gpu/drm/sis/Makefile
@@ -2,7 +2,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ccflags-y = -Iinclude/drm
 sis-y := sis_drv.o sis_mm.o
 
 obj-$(CONFIG_DRM_SIS)   += sis.o
-- 
2.7.4

[PATCH v3 03/16] drm/vmwgfx: fix include notation and remove -Iinclude/drm flag

[Masahiro Yamada]

Include  instead of relative path from include/drm, then
remove the -Iinclude/drm compiler flag.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None

 drivers/gpu/drm/vmwgfx/Makefile | 3 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 ++-
 7 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index aac17a6..a365330 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,6 +1,3 @@
-
-ccflags-y := -Iinclude/drm
-
 vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_buffer.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 77cb7c6..99a7f4a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -25,8 +25,9 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
-#include "ttm/ttm_bo_api.h"
 
 /*
  * Size of inline command buffers. Try to make sure that a page size is a
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 443d1ed..bcc6d41 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -25,10 +25,11 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_binding.h"
-#include "ttm/ttm_placement.h"
 
 struct vmw_user_context {
struct ttm_base_object base;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index 265c81e..6c026d7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -30,9 +30,10 @@
  * whenever the backing MOB is evicted.
  */
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
-#include 
 #include "vmwgfx_so.h"
 
 /**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index e57a0ba..6063c96 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include "drmP.h"
+#include 
 #include "vmwgfx_msg.h"
 
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
index 92f8b1d..68f135c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_shader.c
@@ -25,10 +25,11 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_binding.h"
-#include "ttm/ttm_placement.h"
 
 struct vmw_shader {
struct vmw_resource res;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 7681341..5900cff 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -25,11 +25,12 @@
  *
  **/
 
+#include 
+
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_so.h"
 #include "vmwgfx_binding.h"
-#include 
 #include "device_include/svga3d_surfacedefs.h"
 
 
-- 
2.7.4

[PATCH 0/7] perf tool: add meta-data header support for pipe-mode

[David Carrillo-Cisneros]

(This is a rebased and updated version of Stephane Eranian's version
 in https://patchwork.kernel.org/patch/1499081/)
 
Up until now, meta-data was only available when perf record
was used in "regular" mode, i.e., generating a perf.data file.
For users depending on pipe mode, neither host or event header
information were gathered. This patch addresses this limitation.

The difficulty in pipe mode is that information needs to be written
sequentially to the pipe. Meta data headers are usually generated
(and also expected) at the beginning of the file (or piped output).
To solve this problem, we introduce new synthetic record types,
one for each meta-data type. The approach is similar to what
is *ALREADY* used for BUILD_ID and TRACING_DATA.

We have modified util/header.c such that the same routines are used
to generate and read the meta-data information regardless of pipe-mode
vs. regular mode. To make this work, we added a new struct called
feat_fd which encapsulates all the information necessary to read or
write meta-data information to a file/pipe or from a file/pipe.

With this patch, it is possible to get:
  $ perf record -o - -e cycles -c 10 sleep 1 | perf report --stdio
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.000 MB - ]
  # hostname : myhost
  # os release : 4.11.0-dbx-up_perf
  # perf version : 4.11.rc6.g6277c80
  # arch : x86_64
  # nrcpus online : 72
  # nrcpus avail : 72
  # cpudesc : Intel(R) Xeon(R) CPU E5-2696 v3 @ 2.30GHz
  # cpuid : GenuineIntel,6,63,2
  # total memory : 263457192 kB
  # cmdline : /root/perf record -o - -e cycles -c 10 sleep 1
  # HEADER_CPU_TOPOLOGY info available, use -I to display
  # HEADER_NUMA_TOPOLOGY info available, use -I to display
  # pmu mappings: intel_bts = 6, uncore_imc_4 = 22, uncore_sbox_1 = 47, 
uncore_cbox_5 = 33, uncore_ha_0 = 16, uncore_cbox
  Percent |  Source code & Disassembly of kcore for cycles (9 samples)
  ...


David Carrillo-Cisneros (7):
  perf header: fail on write_padded error
  perf util: add const modifier to buf in "writen" function
  perf header: use struct feat_fd for write
  perf header: use struct feat_fd for print
  perf header: use struct feat_fd for process and read
  perf tool: make show-info in perf report a tool attribute
  perf tools: add feature header record to pipe-mode

 tools/perf/builtin-annotate.c |   1 +
 tools/perf/builtin-inject.c   |   1 +
 tools/perf/builtin-record.c   |   6 +
 tools/perf/builtin-report.c   |   6 +-
 tools/perf/builtin-script.c   |   6 +-
 tools/perf/util/build-id.c|  10 +-
 tools/perf/util/build-id.h|   4 +-
 tools/perf/util/event.c   |  13 +
 tools/perf/util/event.h   |  19 +
 tools/perf/util/header.c  | 905 +++---
 tools/perf/util/header.h  |  17 +-
 tools/perf/util/session.c |  12 +
 tools/perf/util/tool.h|   4 +-
 tools/perf/util/util.c|   6 +-
 tools/perf/util/util.h|   2 +-
 15 files changed, 594 insertions(+), 418 deletions(-)

-- 
2.13.0.303.g4ebf302169-goog

[PATCH 0/7] perf tool: add meta-data header support for pipe-mode

[David Carrillo-Cisneros]

(This is a rebased and updated version of Stephane Eranian's version
 in https://patchwork.kernel.org/patch/1499081/)
 
Up until now, meta-data was only available when perf record
was used in "regular" mode, i.e., generating a perf.data file.
For users depending on pipe mode, neither host or event header
information were gathered. This patch addresses this limitation.

The difficulty in pipe mode is that information needs to be written
sequentially to the pipe. Meta data headers are usually generated
(and also expected) at the beginning of the file (or piped output).
To solve this problem, we introduce new synthetic record types,
one for each meta-data type. The approach is similar to what
is *ALREADY* used for BUILD_ID and TRACING_DATA.

We have modified util/header.c such that the same routines are used
to generate and read the meta-data information regardless of pipe-mode
vs. regular mode. To make this work, we added a new struct called
feat_fd which encapsulates all the information necessary to read or
write meta-data information to a file/pipe or from a file/pipe.

With this patch, it is possible to get:
  $ perf record -o - -e cycles -c 10 sleep 1 | perf report --stdio
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.000 MB - ]
  # hostname : myhost
  # os release : 4.11.0-dbx-up_perf
  # perf version : 4.11.rc6.g6277c80
  # arch : x86_64
  # nrcpus online : 72
  # nrcpus avail : 72
  # cpudesc : Intel(R) Xeon(R) CPU E5-2696 v3 @ 2.30GHz
  # cpuid : GenuineIntel,6,63,2
  # total memory : 263457192 kB
  # cmdline : /root/perf record -o - -e cycles -c 10 sleep 1
  # HEADER_CPU_TOPOLOGY info available, use -I to display
  # HEADER_NUMA_TOPOLOGY info available, use -I to display
  # pmu mappings: intel_bts = 6, uncore_imc_4 = 22, uncore_sbox_1 = 47, 
uncore_cbox_5 = 33, uncore_ha_0 = 16, uncore_cbox
  Percent |  Source code & Disassembly of kcore for cycles (9 samples)
  ...


David Carrillo-Cisneros (7):
  perf header: fail on write_padded error
  perf util: add const modifier to buf in "writen" function
  perf header: use struct feat_fd for write
  perf header: use struct feat_fd for print
  perf header: use struct feat_fd for process and read
  perf tool: make show-info in perf report a tool attribute
  perf tools: add feature header record to pipe-mode

 tools/perf/builtin-annotate.c |   1 +
 tools/perf/builtin-inject.c   |   1 +
 tools/perf/builtin-record.c   |   6 +
 tools/perf/builtin-report.c   |   6 +-
 tools/perf/builtin-script.c   |   6 +-
 tools/perf/util/build-id.c|  10 +-
 tools/perf/util/build-id.h|   4 +-
 tools/perf/util/event.c   |  13 +
 tools/perf/util/event.h   |  19 +
 tools/perf/util/header.c  | 905 +++---
 tools/perf/util/header.h  |  17 +-
 tools/perf/util/session.c |  12 +
 tools/perf/util/tool.h|   4 +-
 tools/perf/util/util.c|   6 +-
 tools/perf/util/util.h|   2 +-
 15 files changed, 594 insertions(+), 418 deletions(-)

-- 
2.13.0.303.g4ebf302169-goog

[PATCH 3/7] perf header: use struct feat_fd for write

[David Carrillo-Cisneros]

As preparation for using header records in pipe mode, replace
int fd with struct feat_fd fd in write functions for all header
record types.

Record types that are not used in pipe-mode (such as auxtrace) will
never be called with fd->buf set and fail if so.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/perf/util/build-id.c |  10 ++-
 tools/perf/util/build-id.h |   4 +-
 tools/perf/util/header.c   | 194 +
 tools/perf/util/header.h   |   7 +-
 4 files changed, 140 insertions(+), 75 deletions(-)

diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 168cc49654e7..292e90db3924 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -330,7 +330,7 @@ bool dso__build_id_is_kmod(const struct dso *dso, char *bf, 
size_t size)
else
 
 static int write_buildid(const char *name, size_t name_len, u8 *build_id,
-pid_t pid, u16 misc, int fd)
+pid_t pid, u16 misc, struct feat_fd *fd)
 {
int err;
struct build_id_event b;
@@ -345,14 +345,15 @@ static int write_buildid(const char *name, size_t 
name_len, u8 *build_id,
b.header.misc = misc;
b.header.size = sizeof(b) + len;
 
-   err = writen(fd, , sizeof(b));
+   err = do_write(fd, , sizeof(b));
if (err < 0)
return err;
 
return write_padded(fd, name, name_len + 1, len);
 }
 
-static int machine__write_buildid_table(struct machine *machine, int fd)
+static int machine__write_buildid_table(struct machine *machine,
+   struct feat_fd *fd)
 {
int err = 0;
char nm[PATH_MAX];
@@ -397,7 +398,8 @@ static int machine__write_buildid_table(struct machine 
*machine, int fd)
return err;
 }
 
-int perf_session__write_buildid_table(struct perf_session *session, int fd)
+int perf_session__write_buildid_table(struct perf_session *session,
+ struct feat_fd *fd)
 {
struct rb_node *nd;
int err = machine__write_buildid_table(>machines.host, fd);
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index a96081121179..84e5e8a52970 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -9,6 +9,7 @@
 
 extern struct perf_tool build_id__mark_dso_hit_ops;
 struct dso;
+struct feat_fd;
 
 int build_id__sprintf(const u8 *build_id, int len, char *bf);
 int sysfs__sprintf_build_id(const char *root_dir, char *sbuild_id);
@@ -26,7 +27,8 @@ int build_id__mark_dso_hit(struct perf_tool *tool, union 
perf_event *event,
 int dsos__hit_all(struct perf_session *session);
 
 bool perf_session__read_build_ids(struct perf_session *session, bool 
with_hits);
-int perf_session__write_buildid_table(struct perf_session *session, int fd);
+int perf_session__write_buildid_table(struct perf_session *session,
+ struct feat_fd *fd);
 int perf_session__cache_build_ids(struct perf_session *session);
 
 char *build_id_cache__origname(const char *sbuild_id);
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 2415d41282d8..5ca603b7a7a3 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -57,6 +57,14 @@ struct perf_file_attr {
struct perf_file_sectionids;
 };
 
+struct feat_fd {
+   struct perf_header *ph;
+   int fd;
+   void *buf;  /* Either buf != NULL or fd >= 0 */
+   ssize_t offset;
+   size_t size;
+};
+
 void perf_header__set_feat(struct perf_header *header, int feat)
 {
set_bit(feat, header->adds_features);
@@ -73,23 +81,36 @@ bool perf_header__has_feat(const struct perf_header 
*header, int feat)
 }
 
 /* Return: 0 if succeded, -ERR if failed. */
-static int do_write(int fd, const void *buf, size_t size)
+int do_write(struct feat_fd *fd, const void *buf, size_t size)
 {
-   while (size) {
-   int ret = write(fd, buf, size);
+   void *addr;
 
-   if (ret < 0)
-   return -errno;
+   if (!fd->buf) {
+   ssize_t ret = writen(fd->fd, buf, size);
 
-   size -= ret;
-   buf += ret;
+   if (ret != (ssize_t)size)
+   return ret < 0 ? (int)ret : -1;
+   return 0;
}
+retry:
+   if (size > (fd->size - fd->offset)) {
+   addr = realloc(fd->buf, fd->size << 1);
+   if (!addr)
+   return -ENOSPC;
+   fd->buf = addr;
+   fd->size <<= 1;
+   goto retry;
+   }
+
+   memcpy(fd->buf + fd->offset, buf, size);
+   fd->offset += size;
 
return 0;
 }
 
 /* Return: 0 if succeded, -ERR if failed. */
-int write_padded(int fd, const void *bf, size_t count, size_t count_aligned)
+int write_padded(struct feat_fd *fd, const void *bf,
+size_t count, size_t count_aligned)
 {

[PATCH 2/7] perf util: add const modifier to buf in "writen" function

[David Carrillo-Cisneros]

Make buf in helper function "writen" constant to simplify
the life of its callers.

This requires to hack a cast of buf prior to passing it to "ion"
which is simpler than the alternative of reworking the "ion"
function to provide a read and a write paths, the latter with
constant buf argument.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/perf/util/util.c | 6 --
 tools/perf/util/util.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 6450c75a6f5b..31ca7661e5fb 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -260,6 +260,7 @@ static ssize_t ion(bool is_read, int fd, void *buf, size_t 
n)
size_t left = n;
 
while (left) {
+   /* buf must be treated as const if !is_read. */
ssize_t ret = is_read ? read(fd, buf, left) :
write(fd, buf, left);
 
@@ -287,9 +288,10 @@ ssize_t readn(int fd, void *buf, size_t n)
 /*
  * Write exactly 'n' bytes or return an error.
  */
-ssize_t writen(int fd, void *buf, size_t n)
+ssize_t writen(int fd, const void *buf, size_t n)
 {
-   return ion(false, fd, buf, n);
+   /* ion does not modify buf. */
+   return ion(false, fd, (void *)buf, n);
 }
 
 size_t hex_width(u64 v)
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 3852b6d3270a..e0881bf67fc9 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -57,7 +57,7 @@ int copyfile_mode(const char *from, const char *to, mode_t 
mode);
 int copyfile_offset(int fromfd, loff_t from_ofs, int tofd, loff_t to_ofs, u64 
size);
 
 ssize_t readn(int fd, void *buf, size_t n);
-ssize_t writen(int fd, void *buf, size_t n);
+ssize_t writen(int fd, const void *buf, size_t n);
 
 struct perf_event_attr;
 
-- 
2.13.0.303.g4ebf302169-goog

[PATCH 3/7] perf header: use struct feat_fd for write

[David Carrillo-Cisneros]

As preparation for using header records in pipe mode, replace
int fd with struct feat_fd fd in write functions for all header
record types.

Record types that are not used in pipe-mode (such as auxtrace) will
never be called with fd->buf set and fail if so.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/perf/util/build-id.c |  10 ++-
 tools/perf/util/build-id.h |   4 +-
 tools/perf/util/header.c   | 194 +
 tools/perf/util/header.h   |   7 +-
 4 files changed, 140 insertions(+), 75 deletions(-)

diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 168cc49654e7..292e90db3924 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -330,7 +330,7 @@ bool dso__build_id_is_kmod(const struct dso *dso, char *bf, 
size_t size)
else
 
 static int write_buildid(const char *name, size_t name_len, u8 *build_id,
-pid_t pid, u16 misc, int fd)
+pid_t pid, u16 misc, struct feat_fd *fd)
 {
int err;
struct build_id_event b;
@@ -345,14 +345,15 @@ static int write_buildid(const char *name, size_t 
name_len, u8 *build_id,
b.header.misc = misc;
b.header.size = sizeof(b) + len;
 
-   err = writen(fd, , sizeof(b));
+   err = do_write(fd, , sizeof(b));
if (err < 0)
return err;
 
return write_padded(fd, name, name_len + 1, len);
 }
 
-static int machine__write_buildid_table(struct machine *machine, int fd)
+static int machine__write_buildid_table(struct machine *machine,
+   struct feat_fd *fd)
 {
int err = 0;
char nm[PATH_MAX];
@@ -397,7 +398,8 @@ static int machine__write_buildid_table(struct machine 
*machine, int fd)
return err;
 }
 
-int perf_session__write_buildid_table(struct perf_session *session, int fd)
+int perf_session__write_buildid_table(struct perf_session *session,
+ struct feat_fd *fd)
 {
struct rb_node *nd;
int err = machine__write_buildid_table(>machines.host, fd);
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index a96081121179..84e5e8a52970 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -9,6 +9,7 @@
 
 extern struct perf_tool build_id__mark_dso_hit_ops;
 struct dso;
+struct feat_fd;
 
 int build_id__sprintf(const u8 *build_id, int len, char *bf);
 int sysfs__sprintf_build_id(const char *root_dir, char *sbuild_id);
@@ -26,7 +27,8 @@ int build_id__mark_dso_hit(struct perf_tool *tool, union 
perf_event *event,
 int dsos__hit_all(struct perf_session *session);
 
 bool perf_session__read_build_ids(struct perf_session *session, bool 
with_hits);
-int perf_session__write_buildid_table(struct perf_session *session, int fd);
+int perf_session__write_buildid_table(struct perf_session *session,
+ struct feat_fd *fd);
 int perf_session__cache_build_ids(struct perf_session *session);
 
 char *build_id_cache__origname(const char *sbuild_id);
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 2415d41282d8..5ca603b7a7a3 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -57,6 +57,14 @@ struct perf_file_attr {
struct perf_file_sectionids;
 };
 
+struct feat_fd {
+   struct perf_header *ph;
+   int fd;
+   void *buf;  /* Either buf != NULL or fd >= 0 */
+   ssize_t offset;
+   size_t size;
+};
+
 void perf_header__set_feat(struct perf_header *header, int feat)
 {
set_bit(feat, header->adds_features);
@@ -73,23 +81,36 @@ bool perf_header__has_feat(const struct perf_header 
*header, int feat)
 }
 
 /* Return: 0 if succeded, -ERR if failed. */
-static int do_write(int fd, const void *buf, size_t size)
+int do_write(struct feat_fd *fd, const void *buf, size_t size)
 {
-   while (size) {
-   int ret = write(fd, buf, size);
+   void *addr;
 
-   if (ret < 0)
-   return -errno;
+   if (!fd->buf) {
+   ssize_t ret = writen(fd->fd, buf, size);
 
-   size -= ret;
-   buf += ret;
+   if (ret != (ssize_t)size)
+   return ret < 0 ? (int)ret : -1;
+   return 0;
}
+retry:
+   if (size > (fd->size - fd->offset)) {
+   addr = realloc(fd->buf, fd->size << 1);
+   if (!addr)
+   return -ENOSPC;
+   fd->buf = addr;
+   fd->size <<= 1;
+   goto retry;
+   }
+
+   memcpy(fd->buf + fd->offset, buf, size);
+   fd->offset += size;
 
return 0;
 }
 
 /* Return: 0 if succeded, -ERR if failed. */
-int write_padded(int fd, const void *bf, size_t count, size_t count_aligned)
+int write_padded(struct feat_fd *fd, const void *bf,
+size_t count, size_t count_aligned)
 {
static const char 

[PATCH 2/7] perf util: add const modifier to buf in "writen" function

[David Carrillo-Cisneros]

Make buf in helper function "writen" constant to simplify
the life of its callers.

This requires to hack a cast of buf prior to passing it to "ion"
which is simpler than the alternative of reworking the "ion"
function to provide a read and a write paths, the latter with
constant buf argument.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/perf/util/util.c | 6 --
 tools/perf/util/util.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 6450c75a6f5b..31ca7661e5fb 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -260,6 +260,7 @@ static ssize_t ion(bool is_read, int fd, void *buf, size_t 
n)
size_t left = n;
 
while (left) {
+   /* buf must be treated as const if !is_read. */
ssize_t ret = is_read ? read(fd, buf, left) :
write(fd, buf, left);
 
@@ -287,9 +288,10 @@ ssize_t readn(int fd, void *buf, size_t n)
 /*
  * Write exactly 'n' bytes or return an error.
  */
-ssize_t writen(int fd, void *buf, size_t n)
+ssize_t writen(int fd, const void *buf, size_t n)
 {
-   return ion(false, fd, buf, n);
+   /* ion does not modify buf. */
+   return ion(false, fd, (void *)buf, n);
 }
 
 size_t hex_width(u64 v)
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 3852b6d3270a..e0881bf67fc9 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -57,7 +57,7 @@ int copyfile_mode(const char *from, const char *to, mode_t 
mode);
 int copyfile_offset(int fromfd, loff_t from_ofs, int tofd, loff_t to_ofs, u64 
size);
 
 ssize_t readn(int fd, void *buf, size_t n);
-ssize_t writen(int fd, void *buf, size_t n);
+ssize_t writen(int fd, const void *buf, size_t n);
 
 struct perf_event_attr;
 
-- 
2.13.0.303.g4ebf302169-goog