[PATCH] crypto: akcipher: fix typos in include/crypto/akcipher.h

[LABBE Corentin]

Fix numerous spelling error in include/crypto/akcipher.h

Signed-off-by: LABBE Corentin 
---
 include/crypto/akcipher.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h
index 45cd5b3..354de15 100644
--- a/include/crypto/akcipher.h
+++ b/include/crypto/akcipher.h
@@ -21,9 +21,9 @@
  * @src:   Source data
  * @dst:   Destination data
  * @src_len:   Size of the input buffer
- * @dst_len:   Size of the output buffer. It needs to be at leaset
+ * @dst_len:   Size of the output buffer. It needs to be at least
  * as big as the expected result depending on the operation
- * After operation it will be updated with the acctual size of the
+ * After operation it will be updated with the actual size of the
  * result.
  * In case of error where the dst sgl size was insufficient,
  * it will be updated to the size required for the operation.
@@ -59,7 +59,7 @@ struct crypto_akcipher {
  * algorithm. In case of error, where the dst_len was insufficient,
  * the req->dst_len will be updated to the size required for the
  * operation
- * @encrypt:   Function performs an encrytp operation as defined by public key
+ * @encrypt:   Function performs an encrypt operation as defined by public key
  * algorithm. In case of error, where the dst_len was insufficient,
  * the req->dst_len will be updated to the size required for the
  * operation
@@ -73,7 +73,7 @@ struct crypto_akcipher {
  * @set_priv_key: Function invokes the algorithm specific set private key
  * function, which knows how to decode and interpret
  * the BER encoded private key
- * @max_size:  Function returns dest buffer size reqired for a given key.
+ * @max_size:  Function returns dest buffer size required for a given key.
  * @init:  Initialize the cryptographic transformation object.
  * This function is used to initialize the cryptographic
  * transformation object. This function is called only once at
@@ -232,7 +232,7 @@ static inline void akcipher_request_set_callback(struct 
akcipher_request *req,
 }
 
 /**
- * akcipher_request_set_crypt() -- Sets reqest parameters
+ * akcipher_request_set_crypt() -- Sets request parameters
  *
  * Sets parameters required by crypto operation
  *
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/8] ARM: dts: Exynos5800: fix CPU OPP

[Krzysztof Kozlowski]

On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> Fix CPU operating points for Exynos5800 (it use different
> voltages than Exynos5420 and supports additional frequencies).
> However don't use 2000MHz & 1900MHz OPPs (for A15 cores) and
> 1400MHz OPP (for A7 cores) for now as they are not available
> on all boards.
> 
> Based on Hardkernel's kernel for ODROID-XU3 board.
> 
> Changes by Ben Gamari:
> - Port to operating-points-v2
> 
> Cc: Kukjin Kim 
> Cc: Doug Anderson 
> Cc: Javier Martinez Canillas 
> Cc: Andreas Faerber 
> Cc: Sachin Kamat 
> Cc: Thomas Abraham 
> Signed-off-by: Ben Gamari 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/boot/dts/exynos5800.dtsi | 165 
> ++
>  1 file changed, 165 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5800.dtsi 
> b/arch/arm/boot/dts/exynos5800.dtsi
> index c0bb356..e417218 100644
> --- a/arch/arm/boot/dts/exynos5800.dtsi
> +++ b/arch/arm/boot/dts/exynos5800.dtsi
> @@ -17,8 +17,173 @@
>  
>  / {
>   compatible = "samsung,exynos5800", "samsung,exynos5";
> +
> + cpu0_opp_table: opp_table0 {

This includes exynos5420.dtsi, so override by label instead of
duplicating full path.

In the same time you don't have to duplicate all data - just override
what you want:
&cpu0_opp_table {
opp00@18 {
opp-microvolt = <125>;
};
};

That should be sufficient I think.

> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00@18 {
> + opp-hz = /bits/ 64 <18>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp01@17 {
> + opp-hz = /bits/ 64 <17>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp02@16 {
> + opp-hz = /bits/ 64 <16>;
> + opp-microvolt = <125>;
> + clock-latency-ns = <14>;
> + };
> + opp03@15 {
> + opp-hz = /bits/ 64 <15>;
> + opp-microvolt = <110>;
> + clock-latency-ns = <14>;
> + };
> + opp04@14 {
> + opp-hz = /bits/ 64 <14>;
> + opp-microvolt = <110>;
> + clock-latency-ns = <14>;
> + };
> + opp05@13 {
> + opp-hz = /bits/ 64 <13>;
> + opp-microvolt = <110>;
> + clock-latency-ns = <14>;
> + };
> + opp06@12 {
> + opp-hz = /bits/ 64 <12>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp07@11 {
> + opp-hz = /bits/ 64 <11>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp08@10 {
> + opp-hz = /bits/ 64 <10>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp09@9 {
> + opp-hz = /bits/ 64 <9>;
> + opp-microvolt = <100>;
> + clock-latency-ns = <14>;
> + };
> + opp10@8 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp11@7 {
> + opp-hz = /bits/ 64 <7>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp12@6 {
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp13@5 {
> + opp-hz = /bits/ 64 <5>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp14@4 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp15@3 {
> + opp-hz = /bits/ 64 <3>;
> + opp-microvolt = <90>;
> + clock-latency-ns = <14>;
> + };
> + opp16@2000

Re: [PATCH v5 3/4] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Jean-Francois Moine]

On Mon, 7 Dec 2015 19:44:30 +0100
Jens Kuske  wrote:

> >> +   "bus_lcd0", "bus_lcd1", 
> >> "bus_deint",
> 
> > "bus_tcon0", "bus_tcon1", "bus_deint",
> > 
> > (the tcon1 clock is used by both lcd0 and lcd1, while
> >  the tcon0 clock is used for TV output from lcd1)
> 
> Hi,
> 
> These are only the ahb bus gates, not the module clocks.
> Naming them lcd might be a bit confusing, but it follows the naming we
> used since sun4i. And the tcon modules are still called lcd0 and lcd1
> module in the manual too.

There is no reference to TCON0 in the LCDs registers (H3 V1.1 pages 428
and 435), only TCON1.

> Interestingly there is only a tcon0 module clock in the manual and no
> tcon1, but that is not part of this patch.

Well, I looked again in the 3.4 kernel and, for the LCD0/HDMI, there is
no clock setting for TCON1: it just receives the AHB1 clock.

This means that its gate ("bus_lcd1" or "ahb1_tcon1") must be enabled
when streaming on LCD0 or LCD1.

The role of tcon0 is not yet clear to me, but it seems that its clock
is the streaming clock for LCD1/TV, as the HDMI clock is for LCD0/HDMI.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 0/2] mm: Introduce kernelcore=reliable option

[Izumi, Taku]

Dear Tony,

  Thanks for testing!

Dear Andrew,


> > Xeon E7 v3 based systems supports Address Range Mirroring
> > and UEFI BIOS complied with UEFI spec 2.5 can notify which
> > ranges are reliable (mirrored) via EFI memory map.
> > Now Linux kernel utilize its information and allocates
> > boot time memory from reliable region.
> >
> > My requirement is:
> >   - allocate kernel memory from reliable region
> >   - allocate user memory from non-reliable region
> >
> > In order to meet my requirement, ZONE_MOVABLE is useful.
> > By arranging non-reliable range into ZONE_MOVABLE,
> > reliable memory is only used for kernel allocations.
> >
> > My idea is to extend existing "kernelcore" option and
> > introduces kernelcore=reliable option. By specifying
> > "reliable" instead of specifying the amount of memory,
> > non-reliable region will be arranged into ZONE_MOVABLE.
> 
> It is unfortunate that the kernel presently refers to this memory as
> "mirrored", but this patchset introduces the new term "reliable".  I
> think it would be better if we use "mirrored" throughout.
> Of course, mirroring isn't the only way to get reliable memory.

  YES. "mirroring" is not the only way.
  So, in my opinion, we should change "mirrored" into "reliable" in order
  to match terms of UEFI 2.5 spec.

> Perhaps if a part of the system memory has ECC correction then this
> also can be accessed using "reliable", in which case your proposed
> naming makes sense.  reliable == mirrored || ecc?

  "reliable" is better.

  But, I'm willing to change "reliable" into "mirrored".

  Otherwise, I keep "kernelcore=reliable" and add the following minimal fix as 
  a separate patch:

diff  a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -134,7 +134,7 @@ void __init efi_find_mirror(void)
}
}
if (mirror_size)
-   pr_info("Memory: %lldM/%lldM mirrored memory\n",
+   pr_info("Memory: %lldM/%lldM reliable memory\n",
mirror_size>>20, total_size>>20);
 }

 
 Which do you think is beter ?
   - change into kernelcore="mirrored"
   - keep kernelcore="reliable" and minmal printk fix 

> 
> Secondly, does this patchset mean that kernelcore=reliable and
> kernelcore=100M are exclusive?  Or can the user specify
> "kernelcore=reliable,kernelcore=100M" to use 100M of reliable memory
> for kernelcore?

  No, these are exclusive.
> 
> This is unclear from the documentation and I suggest that this be
> spelled out.

  Thanks. I'll update its document.

 Sincerely,
 Taku Izumi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: sunxi: Extend the simple gates and handle the Allwinner H3

[Jean-Francois Moine]

On Tue, 8 Dec 2015 08:53:54 +0100
Maxime Ripard  wrote:

> Look, we all agreed on a solution that raised all objections, but
> yours.
> 
> I'm going to take Jens patch.

OK. Good luck for the next SoCs!

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] crypto: add precalculated hash for zero message length

[LABBE Corentin]

Hello

Some crypto drivers cannot process empty data message and so rely on
precalculated hash.
This patch series add precalculated hash in headers and
make the drivers use them.

Using those precalculated hash make some additionnal constify patch necessary.

Changes since v1
- Moved arrays from headers to c file and made them EXPORT.

LABBE Corentin (4):
  crypto: hash: add zero length message hash for shax and md5
  crypto: niagara: Use precalculated hash from headers
  crypto: ccp: Use precalculated hash from headers
  crypto: ux500: Use precalculated hash from headers

 crypto/md5.c  |  6 ++
 crypto/sha1_generic.c |  7 +++
 crypto/sha256_generic.c   | 16 ++
 drivers/crypto/ccp/ccp-ops.c  | 39 +++
 drivers/crypto/n2_core.c  | 33 ++---
 drivers/crypto/ux500/hash/hash_core.c | 20 ++
 include/crypto/md5.h  |  2 ++
 include/crypto/sha.h  |  6 ++
 8 files changed, 53 insertions(+), 76 deletions(-)

-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/4] crypto: ccp: Use precalculated hash from headers

[LABBE Corentin]

Precalculated hash for empty message are now present in hash headers.
This patch just use them.

Signed-off-by: LABBE Corentin 
Tested-by: Tom Lendacky 
Acked-by: Tom Lendacky 
---
 drivers/crypto/ccp/ccp-ops.c | 39 ---
 1 file changed, 8 insertions(+), 31 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index c6e883b..6613aee 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -152,32 +152,6 @@ static const __be32 ccp_sha256_init[CCP_SHA_CTXSIZE / 
sizeof(__be32)] = {
cpu_to_be32(SHA256_H6), cpu_to_be32(SHA256_H7),
 };
 
-/* The CCP cannot perform zero-length sha operations so the caller
- * is required to buffer data for the final operation.  However, a
- * sha operation for a message with a total length of zero is valid
- * so known values are required to supply the result.
- */
-static const u8 ccp_sha1_zero[CCP_SHA_CTXSIZE] = {
-   0xda, 0x39, 0xa3, 0xee, 0x5e, 0x6b, 0x4b, 0x0d,
-   0x32, 0x55, 0xbf, 0xef, 0x95, 0x60, 0x18, 0x90,
-   0xaf, 0xd8, 0x07, 0x09, 0x00, 0x00, 0x00, 0x00,
-   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-};
-
-static const u8 ccp_sha224_zero[CCP_SHA_CTXSIZE] = {
-   0xd1, 0x4a, 0x02, 0x8c, 0x2a, 0x3a, 0x2b, 0xc9,
-   0x47, 0x61, 0x02, 0xbb, 0x28, 0x82, 0x34, 0xc4,
-   0x15, 0xa2, 0xb0, 0x1f, 0x82, 0x8e, 0xa6, 0x2a,
-   0xc5, 0xb3, 0xe4, 0x2f, 0x00, 0x00, 0x00, 0x00,
-};
-
-static const u8 ccp_sha256_zero[CCP_SHA_CTXSIZE] = {
-   0xe3, 0xb0, 0xc4, 0x42, 0x98, 0xfc, 0x1c, 0x14,
-   0x9a, 0xfb, 0xf4, 0xc8, 0x99, 0x6f, 0xb9, 0x24,
-   0x27, 0xae, 0x41, 0xe4, 0x64, 0x9b, 0x93, 0x4c,
-   0xa4, 0x95, 0x99, 0x1b, 0x78, 0x52, 0xb8, 0x55,
-};
-
 static u32 ccp_addr_lo(struct ccp_dma_info *info)
 {
return lower_32_bits(info->address + info->offset);
@@ -1391,18 +1365,21 @@ static int ccp_run_sha_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
if (sha->msg_bits)
return -EINVAL;
 
-   /* A sha operation for a message with a total length of zero,
-* return known result.
+   /* The CCP cannot perform zero-length sha operations so the
+* caller is required to buffer data for the final operation.
+* However, a sha operation for a message with a total length
+* of zero is valid so known values are required to supply
+* the result.
 */
switch (sha->type) {
case CCP_SHA_TYPE_1:
-   sha_zero = ccp_sha1_zero;
+   sha_zero = sha1_zero_message_hash;
break;
case CCP_SHA_TYPE_224:
-   sha_zero = ccp_sha224_zero;
+   sha_zero = sha224_zero_message_hash;
break;
case CCP_SHA_TYPE_256:
-   sha_zero = ccp_sha256_zero;
+   sha_zero = sha256_zero_message_hash;
break;
default:
return -EINVAL;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] crypto: ux500: Use precalculated hash from headers

[LABBE Corentin]

Precalculated hash for empty message are now present in hash headers.
This patch just use them.

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/ux500/hash/hash_core.c | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/ux500/hash/hash_core.c 
b/drivers/crypto/ux500/hash/hash_core.c
index f47d112..d6fdc58 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -41,22 +41,6 @@ static int hash_mode;
 module_param(hash_mode, int, 0);
 MODULE_PARM_DESC(hash_mode, "CPU or DMA mode. CPU = 0 (default), DMA = 1");
 
-/**
- * Pre-calculated empty message digests.
- */
-static const u8 zero_message_hash_sha1[SHA1_DIGEST_SIZE] = {
-   0xda, 0x39, 0xa3, 0xee, 0x5e, 0x6b, 0x4b, 0x0d,
-   0x32, 0x55, 0xbf, 0xef, 0x95, 0x60, 0x18, 0x90,
-   0xaf, 0xd8, 0x07, 0x09
-};
-
-static const u8 zero_message_hash_sha256[SHA256_DIGEST_SIZE] = {
-   0xe3, 0xb0, 0xc4, 0x42, 0x98, 0xfc, 0x1c, 0x14,
-   0x9a, 0xfb, 0xf4, 0xc8, 0x99, 0x6f, 0xb9, 0x24,
-   0x27, 0xae, 0x41, 0xe4, 0x64, 0x9b, 0x93, 0x4c,
-   0xa4, 0x95, 0x99, 0x1b, 0x78, 0x52, 0xb8, 0x55
-};
-
 /* HMAC-SHA1, no key */
 static const u8 zero_message_hmac_sha1[SHA1_DIGEST_SIZE] = {
0xfb, 0xdb, 0x1d, 0x1b, 0x18, 0xaa, 0x6c, 0x08,
@@ -242,13 +226,13 @@ static int get_empty_message_digest(
 
if (HASH_OPER_MODE_HASH == ctx->config.oper_mode) {
if (HASH_ALGO_SHA1 == ctx->config.algorithm) {
-   memcpy(zero_hash, &zero_message_hash_sha1[0],
+   memcpy(zero_hash, &sha1_zero_message_hash[0],
   SHA1_DIGEST_SIZE);
*zero_hash_size = SHA1_DIGEST_SIZE;
*zero_digest = true;
} else if (HASH_ALGO_SHA256 ==
ctx->config.algorithm) {
-   memcpy(zero_hash, &zero_message_hash_sha256[0],
+   memcpy(zero_hash, &sha256_zero_message_hash[0],
   SHA256_DIGEST_SIZE);
*zero_hash_size = SHA256_DIGEST_SIZE;
*zero_digest = true;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/4] clk: sunxi: Add H3 clocks support

[Maxime Ripard]

Hi Jens,

On Fri, Dec 04, 2015 at 10:24:40PM +0100, Jens Kuske wrote:
> The H3 clock control unit is similar to the those of other sun8i family
> members like the A23.
> 
> It adds a new bus gates clock similar to the simple gates, but with a
> different parent clock for each single gate.
> Some of the gates use the new AHB2 clock as parent, whose clock source
> is muxable between AHB1 and PLL6/2. The documentation isn't totally clear
> about which devices belong to AHB2 now, especially USB EHIC/OHIC, so it
> is mostly based on Allwinner kernel source code.
> 
> Signed-off-by: Jens Kuske 

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[PATCH v2 1/4] crypto: hash: add zero length message hash for shax and md5

[LABBE Corentin]

Some crypto drivers cannot process empty data message and return a
precalculated hash for md5/sha1/sha224/sha256.

This patch add thoses precalculated hash in include/crypto.

Signed-off-by: LABBE Corentin 
---
 crypto/md5.c|  6 ++
 crypto/sha1_generic.c   |  7 +++
 crypto/sha256_generic.c | 16 
 include/crypto/md5.h|  2 ++
 include/crypto/sha.h|  6 ++
 5 files changed, 37 insertions(+)

diff --git a/crypto/md5.c b/crypto/md5.c
index 33d17e9..2355a7c 100644
--- a/crypto/md5.c
+++ b/crypto/md5.c
@@ -24,6 +24,12 @@
 #include 
 #include 
 
+const u8 md5_zero_message_hash[MD5_DIGEST_SIZE] = {
+   0xd4, 0x1d, 0x8c, 0xd9, 0x8f, 0x00, 0xb2, 0x04,
+   0xe9, 0x80, 0x09, 0x98, 0xec, 0xf8, 0x42, 0x7e,
+};
+EXPORT_SYMBOL_GPL(md5_zero_message_hash);
+
 /* XXX: this stuff can be optimized */
 static inline void le32_to_cpu_array(u32 *buf, unsigned int words)
 {
diff --git a/crypto/sha1_generic.c b/crypto/sha1_generic.c
index 39e3acc..6877cbb 100644
--- a/crypto/sha1_generic.c
+++ b/crypto/sha1_generic.c
@@ -26,6 +26,13 @@
 #include 
 #include 
 
+const u8 sha1_zero_message_hash[SHA1_DIGEST_SIZE] = {
+   0xda, 0x39, 0xa3, 0xee, 0x5e, 0x6b, 0x4b, 0x0d,
+   0x32, 0x55, 0xbf, 0xef, 0x95, 0x60, 0x18, 0x90,
+   0xaf, 0xd8, 0x07, 0x09
+};
+EXPORT_SYMBOL_GPL(sha1_zero_message_hash);
+
 static void sha1_generic_block_fn(struct sha1_state *sst, u8 const *src,
  int blocks)
 {
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index 7843116..8f9c47e 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -27,6 +27,22 @@
 #include 
 #include 
 
+const u8 sha224_zero_message_hash[SHA224_DIGEST_SIZE] = {
+   0xd1, 0x4a, 0x02, 0x8c, 0x2a, 0x3a, 0x2b, 0xc9, 0x47,
+   0x61, 0x02, 0xbb, 0x28, 0x82, 0x34, 0xc4, 0x15, 0xa2,
+   0xb0, 0x1f, 0x82, 0x8e, 0xa6, 0x2a, 0xc5, 0xb3, 0xe4,
+   0x2f
+};
+EXPORT_SYMBOL_GPL(sha224_zero_message_hash);
+
+const u8 sha256_zero_message_hash[SHA256_DIGEST_SIZE] = {
+   0xe3, 0xb0, 0xc4, 0x42, 0x98, 0xfc, 0x1c, 0x14,
+   0x9a, 0xfb, 0xf4, 0xc8, 0x99, 0x6f, 0xb9, 0x24,
+   0x27, 0xae, 0x41, 0xe4, 0x64, 0x9b, 0x93, 0x4c,
+   0xa4, 0x95, 0x99, 0x1b, 0x78, 0x52, 0xb8, 0x55
+};
+EXPORT_SYMBOL_GPL(sha256_zero_message_hash);
+
 static inline u32 Ch(u32 x, u32 y, u32 z)
 {
return z ^ (x & (y ^ z));
diff --git a/include/crypto/md5.h b/include/crypto/md5.h
index 146af82..327deac 100644
--- a/include/crypto/md5.h
+++ b/include/crypto/md5.h
@@ -13,6 +13,8 @@
 #define MD5_H2 0x98badcfeUL
 #define MD5_H3 0x10325476UL
 
+extern const u8 md5_zero_message_hash[MD5_DIGEST_SIZE];
+
 struct md5_state {
u32 hash[MD5_HASH_WORDS];
u32 block[MD5_BLOCK_WORDS];
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index dd7905a..c94d3eb 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
@@ -64,6 +64,12 @@
 #define SHA512_H6  0x1f83d9abfb41bd6bULL
 #define SHA512_H7  0x5be0cd19137e2179ULL
 
+extern const u8 sha1_zero_message_hash[SHA1_DIGEST_SIZE];
+
+extern const u8 sha224_zero_message_hash[SHA224_DIGEST_SIZE];
+
+extern const u8 sha256_zero_message_hash[SHA256_DIGEST_SIZE];
+
 struct sha1_state {
u32 state[SHA1_DIGEST_SIZE / 4];
u64 count;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] crypto: niagara: Use precalculated hash from headers

[LABBE Corentin]

Precalculated hash for empty message are now present in hash headers.
This patch just use them.

Signed-off-by: LABBE Corentin 
---
 drivers/crypto/n2_core.c | 33 ++---
 1 file changed, 6 insertions(+), 27 deletions(-)

diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 5450880..febbd5e 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -241,7 +241,7 @@ static inline bool n2_should_run_async(struct spu_queue 
*qp, int this_len)
 
 struct n2_ahash_alg {
struct list_headentry;
-   const char  *hash_zero;
+   const u8*hash_zero;
const u32   *hash_init;
u8  hw_op_hashsz;
u8  digest_size;
@@ -1267,7 +1267,7 @@ static LIST_HEAD(cipher_algs);
 
 struct n2_hash_tmpl {
const char  *name;
-   const char  *hash_zero;
+   const u8*hash_zero;
const u32   *hash_init;
u8  hw_op_hashsz;
u8  digest_size;
@@ -1276,40 +1276,19 @@ struct n2_hash_tmpl {
u8  hmac_type;
 };
 
-static const char md5_zero[MD5_DIGEST_SIZE] = {
-   0xd4, 0x1d, 0x8c, 0xd9, 0x8f, 0x00, 0xb2, 0x04,
-   0xe9, 0x80, 0x09, 0x98, 0xec, 0xf8, 0x42, 0x7e,
-};
 static const u32 md5_init[MD5_HASH_WORDS] = {
cpu_to_le32(MD5_H0),
cpu_to_le32(MD5_H1),
cpu_to_le32(MD5_H2),
cpu_to_le32(MD5_H3),
 };
-static const char sha1_zero[SHA1_DIGEST_SIZE] = {
-   0xda, 0x39, 0xa3, 0xee, 0x5e, 0x6b, 0x4b, 0x0d, 0x32,
-   0x55, 0xbf, 0xef, 0x95, 0x60, 0x18, 0x90, 0xaf, 0xd8,
-   0x07, 0x09
-};
 static const u32 sha1_init[SHA1_DIGEST_SIZE / 4] = {
SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4,
 };
-static const char sha256_zero[SHA256_DIGEST_SIZE] = {
-   0xe3, 0xb0, 0xc4, 0x42, 0x98, 0xfc, 0x1c, 0x14, 0x9a,
-   0xfb, 0xf4, 0xc8, 0x99, 0x6f, 0xb9, 0x24, 0x27, 0xae,
-   0x41, 0xe4, 0x64, 0x9b, 0x93, 0x4c, 0xa4, 0x95, 0x99,
-   0x1b, 0x78, 0x52, 0xb8, 0x55
-};
 static const u32 sha256_init[SHA256_DIGEST_SIZE / 4] = {
SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7,
 };
-static const char sha224_zero[SHA224_DIGEST_SIZE] = {
-   0xd1, 0x4a, 0x02, 0x8c, 0x2a, 0x3a, 0x2b, 0xc9, 0x47,
-   0x61, 0x02, 0xbb, 0x28, 0x82, 0x34, 0xc4, 0x15, 0xa2,
-   0xb0, 0x1f, 0x82, 0x8e, 0xa6, 0x2a, 0xc5, 0xb3, 0xe4,
-   0x2f
-};
 static const u32 sha224_init[SHA256_DIGEST_SIZE / 4] = {
SHA224_H0, SHA224_H1, SHA224_H2, SHA224_H3,
SHA224_H4, SHA224_H5, SHA224_H6, SHA224_H7,
@@ -1317,7 +1296,7 @@ static const u32 sha224_init[SHA256_DIGEST_SIZE / 4] = {
 
 static const struct n2_hash_tmpl hash_tmpls[] = {
{ .name = "md5",
- .hash_zero= md5_zero,
+ .hash_zero= md5_zero_message_hash,
  .hash_init= md5_init,
  .auth_type= AUTH_TYPE_MD5,
  .hmac_type= AUTH_TYPE_HMAC_MD5,
@@ -1325,7 +1304,7 @@ static const struct n2_hash_tmpl hash_tmpls[] = {
  .digest_size  = MD5_DIGEST_SIZE,
  .block_size   = MD5_HMAC_BLOCK_SIZE },
{ .name = "sha1",
- .hash_zero= sha1_zero,
+ .hash_zero= sha1_zero_message_hash,
  .hash_init= sha1_init,
  .auth_type= AUTH_TYPE_SHA1,
  .hmac_type= AUTH_TYPE_HMAC_SHA1,
@@ -1333,7 +1312,7 @@ static const struct n2_hash_tmpl hash_tmpls[] = {
  .digest_size  = SHA1_DIGEST_SIZE,
  .block_size   = SHA1_BLOCK_SIZE },
{ .name = "sha256",
- .hash_zero= sha256_zero,
+ .hash_zero= sha256_zero_message_hash,
  .hash_init= sha256_init,
  .auth_type= AUTH_TYPE_SHA256,
  .hmac_type= AUTH_TYPE_HMAC_SHA256,
@@ -1341,7 +1320,7 @@ static const struct n2_hash_tmpl hash_tmpls[] = {
  .digest_size  = SHA256_DIGEST_SIZE,
  .block_size   = SHA256_BLOCK_SIZE },
{ .name = "sha224",
- .hash_zero= sha224_zero,
+ .hash_zero= sha224_zero_message_hash,
  .hash_init= sha224_init,
  .auth_type= AUTH_TYPE_SHA256,
  .hmac_type= AUTH_TYPE_RESERVED,
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 7/8] ARM: dts: Exynos5422: fix OPP tables

[Krzysztof Kozlowski]

On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> From: Ben Gamari 
> 
> The Exynos 5422 is identical to the 5800 except for the fact that it
> boots from the A7 cores. Consequently, the core numbering is different:
> cores 0-3 are A7s whereas 4-7 are A15s.
> 
> We can reuse the device tree of the 5800 for the 5422 but we must take
> care to override the OPP tables and CPU clocks.  These are otherwise
> inherited from the exynos5800 devicetree, which has the CPU clusters
> reversed compared to the 5422. This results in the A15 cores only
> reaching 1.4GHz, the maximum rate of the KFC clock.
> 
> Cc: Javier Martinez Canillas 
> Signed-off-by: Ben Gamari 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 

This looks like a very-non-atomic way of handling a change. You added
opp tables to exynos5420 before so at that time they will be applied to
Odroid XU3 family which uses different CPU order. After that you are
fixing the tables to proper CPU order. Direct bisectability probably
won't be an issue because all of DTS would go to separate branch... but
the logic behind confuses.

I think this should be squashed into 3/8.

Best regards,
Krzysztof

> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi 
> b/arch/arm/boot/dts/exynos5422-cpus.dtsi
> index b7f60c8..9a5131d 100644
> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
> @@ -20,8 +20,10 @@
>   device_type = "cpu";
>   compatible = "arm,cortex-a7";
>   reg = <0x100>;
> + clocks = <&clock CLK_KFC_CLK>;
>   clock-frequency = <10>;
>   cci-control-port = <&cci_control0>;
> + operating-points-v2 = <&cpu1_opp_table>;
>  };
>  
>  &cpu1 {
> @@ -30,6 +32,7 @@
>   reg = <0x101>;
>   clock-frequency = <10>;
>   cci-control-port = <&cci_control0>;
> + operating-points-v2 = <&cpu1_opp_table>;
>  };
>  
>  &cpu2 {
> @@ -38,6 +41,7 @@
>   reg = <0x102>;
>   clock-frequency = <10>;
>   cci-control-port = <&cci_control0>;
> + operating-points-v2 = <&cpu1_opp_table>;
>  };
>  
>  &cpu3 {
> @@ -46,14 +50,17 @@
>   reg = <0x103>;
>   clock-frequency = <10>;
>   cci-control-port = <&cci_control0>;
> + operating-points-v2 = <&cpu1_opp_table>;
>  };
>  
>  &cpu4 {
>   device_type = "cpu";
>   compatible = "arm,cortex-a15";
>   reg = <0x0>;
> + clocks = <&clock CLK_ARM_CLK>;
>   clock-frequency = <18>;
>   cci-control-port = <&cci_control1>;
> + operating-points-v2 = <&cpu0_opp_table>;
>  };
>  
>  &cpu5 {
> @@ -62,6 +69,7 @@
>   reg = <0x1>;
>   clock-frequency = <18>;
>   cci-control-port = <&cci_control1>;
> + operating-points-v2 = <&cpu0_opp_table>;
>  };
>  
>  &cpu6 {
> @@ -70,6 +78,7 @@
>   reg = <0x2>;
>   clock-frequency = <18>;
>   cci-control-port = <&cci_control1>;
> + operating-points-v2 = <&cpu0_opp_table>;
>  };
>  
>  &cpu7 {
> @@ -78,4 +87,5 @@
>   reg = <0x3>;
>   clock-frequency = <18>;
>   cci-control-port = <&cci_control1>;
> + operating-points-v2 = <&cpu0_opp_table>;
>  };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: An issue about sp5100 watchdog

[Huang Rui]

On Mon, Dec 07, 2015 at 11:03:31PM -0800, Guenter Roeck wrote:
> On 12/07/2015 09:42 PM, Huang Rui wrote:
> >Hi all,
> >
> >I found an issue in some of AMD platforms about sp5100, that the MMIO
> >address (0x51413120) is already used by System RAM
> >(0010-7c2befff)...
> >
> >[   29.928096] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
> >[   29.928302] sp5100_tco: PCI Vendor ID: 0x1022, Device ID: 0x790b, 
> >Revision ID: 0x4a
> >[   29.928319] sp5100_tco: Got 0x51413120 from indirect I/O
> >[   29.928323] sp5100_tco: MMIO address 0x51413120 already in use
> >[   29.928332] sp5100_tco: SBResource_MMIO is disabled(0xe000a0)
> >[   29.928333] sp5100_tco: failed to find MMIO address, giving up.
> >
> If I understand the code correctly, the problem is really "SBResource_MMIO is 
> disabled".
> Presumably that is done in the BIOS. No idea if anything can be done about 
> that.
> 

Thank you.

Compared with correct message:

0010-3e4befff : System RAM
  0100-017b1ab3 : Kernel code
  017b1ab4-01d4ce7f : Kernel data
  01ec4000-02008fff : Kernel bss
3e4bf000-3e8befff : reserved
3e8bf000-3ebbefff : ACPI Non-volatile Storage
3ebqbf000-3ebfefff : ACPI Tables
3ebff000-3ebf : System RAM
3ec0-7eff : reserved
  51413120-51413127 : SB800 TCO <- here
7f00-f7ff : PCI Bus :00

SB800 TCO area is reserved. Then it doesn't find MMIO address from
SBResource_MMIO register...

Thanks,
Rui

> Guenter
> 
> >0010-7c2befff : System RAM
> >   0100-017b1ab3 : Kernel code
> >   017b1ab4-01d4ce7f : Kernel data
> >   01ec4000-02008fff : Kernel bss
> >7c2bf000-7c8befff : reserved
> >7c8bf000-7cbbefff : ACPI Non-volatile Storage
> >   7cbb6000-7cbb9fff : MSFT0101:00
> >   7cbba000-7cbbdfff : MSFT0101:00
> >7cbbf000-7cbfefff : ACPI Tables
> >7cbff000-7cbf : System RAM
> >7cc0-7eff : reserved
> >
> >Any idea?
> >
> >Thanks,
> >Rui
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> >the body of a message to majord...@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH 01/23] mtd: kill the ecclayout->oobavail field

[Boris Brezillon]

Hi Priit,

On Tue, 08 Dec 2015 08:43:05 +0200
Priit Laes  wrote:

> On Mon, 2015-12-07 at 23:25 +0100, Boris Brezillon wrote:
> > ecclayout->oobavail is just redundant with the mtd->oobavail field.
> > Moreover, it prevents static const definition of ecc layouts since
> > the
> > NAND framework is calculating this value based on the ecclayout-
> > >oobfree
> > field.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/devices/docg3.c   |  5 ++-
> >  drivers/mtd/mtdswap.c | 16 -
> >  drivers/mtd/nand/brcmnand/brcmnand.c  |  3 --
> >  drivers/mtd/nand/docg4.c  |  1 -
> >  drivers/mtd/nand/hisi504_nand.c   |  1 -
> >  drivers/mtd/nand/nand_base.c  | 12 +++
> >  drivers/mtd/onenand/onenand_base.c| 16 -
> >  drivers/mtd/tests/oobtest.c   | 49 +--
> > 
> >  drivers/staging/mt29f_spinand/mt29f_spinand.c |  1 -
> >  fs/jffs2/wbuf.c   |  6 ++--
> >  include/linux/mtd/mtd.h   |  1 -
> >  11 files changed, 48 insertions(+), 63 deletions(-)
> > 
> [..]
> >  
> > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/brcmnand/brcmnand.c
> > index 35d78f7..a906ec2 100644
> > --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> > @@ -845,9 +845,6 @@ static struct nand_ecclayout 
> > *brcmnand_create_layout(int ecc_level,
> >     break;
> >     }
> >  out:
> > -   /* Sum available OOB */
> > -   for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES_LARGE; i++)
> > -   layout->oobavail += layout->oobfree[i].length;
> >     return layout;
> >  }
> 
> You can get rid of the 'out' label and replace the single goto in this
> function with 'return layout'.

Yep, I'll fix that.

> 
> [...]
> >  
> > diff --git a/drivers/mtd/nand/nand_base.c
> > b/drivers/mtd/nand/nand_base.c
> > index 0748a13..1107f5c1 100644
> > --- a/drivers/mtd/nand/nand_base.c
> > +++ b/drivers/mtd/nand/nand_base.c
> > @@ -2037,7 +2037,7 @@ static int nand_do_read_oob(struct mtd_info
> > *mtd, loff_t from,
> >     stats = mtd->ecc_stats;
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   len = chip->ecc.layout->oobavail;
> > +   len = mtd->oobavail;
> >     else
> >     len = mtd->oobsize;
> >  
> > @@ -2728,7 +2728,7 @@ static int nand_do_write_oob(struct mtd_info
> > *mtd, loff_t to,
> >      __func__, (unsigned int)to, (int)ops-
> > >ooblen);
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   len = chip->ecc.layout->oobavail;
> > +   len = mtd->oobavail;
> >     else
> >     len = mtd->oobsize;
> >  
> [...]
> > diff --git a/drivers/mtd/onenand/onenand_base.c
> > b/drivers/mtd/onenand/onenand_base.c
> > index 43b3392..d70bbfd 100644
> > --- a/drivers/mtd/onenand/onenand_base.c
> > +++ b/drivers/mtd/onenand/onenand_base.c
> > @@ -1125,7 +1125,7 @@ static int onenand_mlc_read_ops_nolock(struct
> > mtd_info *mtd, loff_t from,
> >     (int)len);
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -1230,7 +1230,7 @@ static int onenand_read_ops_nolock(struct
> > mtd_info *mtd, loff_t from,
> >     (int)len);
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -1365,7 +1365,7 @@ static int onenand_read_oob_nolock(struct
> > mtd_info *mtd, loff_t from,
> >     ops->oobretlen = 0;
> >  
> >     if (mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -1887,7 +1887,7 @@ static int onenand_write_ops_nolock(struct
> > mtd_info *mtd, loff_t to,
> >     return 0;
> >  
> >     if (ops->mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> >  
> > @@ -2063,7 +2063,7 @@ static int onenand_write_oob_nolock(struct
> > mtd_info *mtd, loff_t to,
> >     ops->oobretlen = 0;
> >  
> >     if (mode == MTD_OPS_AUTO_OOB)
> > -   oobsize = this->ecclayout->oobavail;
> > +   oobsize = mtd->oobavail;
> >     else
> >     oobsize = mtd->oobsize;
> 
> This identical construction seems to occur multiple times in multiple
> files. Would it make sense to create a macro for it?

Right, I'll make another patch move this logic into an inline function.

Thanks for the review.

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from 

Re: [PATCH v3] staging/android: add TODO to de-stage android sync framework

[Daniel Vetter]

On Mon, Dec 07, 2015 at 04:28:45PM -0200, Gustavo Padovan wrote:
> Hi,
> 
> any comments/update on this? Thanks

My ack from the previous version still stands.
-Daniel

> 
>   Gustavo
> 
> 2015-11-26 Gustavo Padovan :
> 
> > From: Gustavo Padovan 
> > 
> >  - remove CONFIG_SW_SYNC_USER, it is used only for testing/debugging and
> >should not be upstreamed.
> >  - port CONFIG_SW_SYNC_USER tests interfaces to use debugfs somehow
> >  - port libsync tests to kselftest
> >  - clean up and ABI check for security issues
> >  - move the sync framework to drivers/base/dma-buf
> > 
> > Cc: Arve Hjønnevåg 
> > Cc: Riley Andrews 
> > Cc: Daniel Vetter 
> > Cc: Rob Clark 
> > Cc: Greg Hackmann 
> > Cc: John Harrison 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/staging/android/TODO | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..64d8c87 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> > @@ -25,5 +25,13 @@ ion/
> > exposes existing cma regions and doesn't reserve unecessarily memory 
> > when
> > booting a system which doesn't use ion.
> >  
> > +sync framework:
> > + - remove CONFIG_SW_SYNC_USER, it is used only for testing/debugging and
> > + should not be upstreamed.
> > + - port CONFIG_SW_SYNC_USER tests interfaces to use debugfs somehow
> > + - port libsync tests to kselftest
> > + - clean up and ABI check for security issues
> > + - move it to drivers/base/dma-buf
> > +
> >  Please send patches to Greg Kroah-Hartman  and Cc:
> >  Arve Hjønnevåg  and Riley Andrews 
> > -- 
> > 2.1.0
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fixing full name in patchwork

[Sudip Mukherjee]

On Tue, Dec 08, 2015 at 09:54:41AM +0200, Kalle Valo wrote:
> Sudip Mukherjee  writes:
> 
> > On Mon, Dec 07, 2015 at 08:03:54PM +0200, Kalle Valo wrote:
> >> Hi Sudip,
> >> 
> >> Sudip Mukherjee  writes:
> >> 

> >
> > I have also noticed the patch. Anyway, I have created a profile in
> > patchwork and given full name. Hopefully that should solve the problem.
> 
> At least now your name in the patchwork link above looks correct:

Yes, but I am still surprised why this happened for only this patch.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/4] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Maxime Ripard]

On Fri, Dec 04, 2015 at 10:24:42PM +0100, Jens Kuske wrote:
> The Allwinner H3 is a home entertainment system oriented SoC with
> four Cortex-A7 cores and a Mali-400MP2 GPU.
> 
> Signed-off-by: Jens Kuske 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: Fixing full name in patchwork

[Kalle Valo]

Sudip Mukherjee  writes:

> On Tue, Dec 08, 2015 at 09:54:41AM +0200, Kalle Valo wrote:
>> Sudip Mukherjee  writes:
>> 
>> > On Mon, Dec 07, 2015 at 08:03:54PM +0200, Kalle Valo wrote:
>> >> Hi Sudip,
>> >> 
>> >> Sudip Mukherjee  writes:
>> >> 
> 
>> >
>> > I have also noticed the patch. Anyway, I have created a profile in
>> > patchwork and given full name. Hopefully that should solve the problem.
>> 
>> At least now your name in the patchwork link above looks correct:
>
> Yes, but I am still surprised why this happened for only this patch.

I don't know what other patches you are referring to, but I download the
patches I apply directly from patchwork. If other maintainers take the
patch from a mail folder this issue would not happen.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/4] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Maxime Ripard]

On Tue, Dec 08, 2015 at 09:06:58AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Dec 2015 19:44:30 +0100
> Jens Kuske  wrote:
> 
> > >> + "bus_lcd0", "bus_lcd1", 
> > >> "bus_deint",
> > 
> > >   "bus_tcon0", "bus_tcon1", "bus_deint",
> > > 
> > > (the tcon1 clock is used by both lcd0 and lcd1, while
> > >  the tcon0 clock is used for TV output from lcd1)
> > 
> > Hi,
> > 
> > These are only the ahb bus gates, not the module clocks.
> > Naming them lcd might be a bit confusing, but it follows the naming we
> > used since sun4i. And the tcon modules are still called lcd0 and lcd1
> > module in the manual too.
> 
> There is no reference to TCON0 in the LCDs registers (H3 V1.1 pages 428
> and 435), only TCON1.
> 
> > Interestingly there is only a tcon0 module clock in the manual and no
> > tcon1, but that is not part of this patch.
> 
> Well, I looked again in the 3.4 kernel and, for the LCD0/HDMI, there is
> no clock setting for TCON1: it just receives the AHB1 clock.
> 
> This means that its gate ("bus_lcd1" or "ahb1_tcon1") must be enabled
> when streaming on LCD0 or LCD1.
> 
> The role of tcon0 is not yet clear to me, but it seems that its clock
> is the streaming clock for LCD1/TV, as the HDMI clock is for LCD0/HDMI.

If the H3 display block is done the same way than the A10 (and later)
one on this aspect, then the TCON has two channels with two different
streaming (or functional, you pick the name) clocks. The channel 0 is
usually used for RGB, the channel 1 for HDMI, composite and VGA.

Maybe they just added different bus gates for those two different
channels, and moved HDMI to the channel 0.

Anyway, that can always be changed later on if we have more clue on
what's going on.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 18/25] cris: nand: remove useless mtd->priv = chip assignments

[Jesper Nilsson]

On Tue, Dec 01, 2015 at 12:03:15PM +0100, Boris Brezillon wrote:
> mtd_to_nand() now uses the container_of() approach to transform an
> mtd_info pointer into a nand_chip one. Drop useless mtd->priv
> assignments from NAND controller drivers.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 4/4] ARM: dts: sun8i: Add Orange Pi Plus support

[Maxime Ripard]

On Fri, Dec 04, 2015 at 10:24:43PM +0100, Jens Kuske wrote:
> The Orange Pi Plus is a SBC based on the Allwinner H3 SoC
> with 8GB eMMC, multiple USB ports through a USB hub chip, SATA through
> a USB-SATA bridge, one uSD slot, a 10/100/1000M ethernet port,
> WiFi, HDMI, headphone jack, IR receiver, a microphone, a CSI connector
> and a 40-pin GPIO header.
> 
> Signed-off-by: Jens Kuske 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] fat: constify fatent_operations structures

[OGAWA Hirofumi]

Julia Lawall  writes:

> The fatent_operations structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.

Looks good. Thanks.

Acked-by: OGAWA Hirofumi 

> Signed-off-by: Julia Lawall 
>
> ---
>  fs/fat/fat.h|2 +-
>  fs/fat/fatent.c |   24 
>  2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/fs/fat/fat.h b/fs/fat/fat.h
> index 4307cd4..e6b764a 100644
> --- a/fs/fat/fat.h
> +++ b/fs/fat/fat.h
> @@ -87,7 +87,7 @@ struct msdos_sb_info {
>   unsigned int vol_id;/*volume ID*/
>  
>   int fatent_shift;
> - struct fatent_operations *fatent_ops;
> + const struct fatent_operations *fatent_ops;
>   struct inode *fat_inode;
>   struct inode *fsinfo_inode;
>  
> diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c
> index 8226557..1d9a8c4 100644
> --- a/fs/fat/fatent.c
> +++ b/fs/fat/fatent.c
> @@ -99,7 +99,7 @@ err:
>  static int fat_ent_bread(struct super_block *sb, struct fat_entry *fatent,
>int offset, sector_t blocknr)
>  {
> - struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
> + const struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
>  
>   WARN_ON(blocknr < MSDOS_SB(sb)->fat_start);
>   fatent->fat_inode = MSDOS_SB(sb)->fat_inode;
> @@ -246,7 +246,7 @@ static int fat32_ent_next(struct fat_entry *fatent)
>   return 0;
>  }
>  
> -static struct fatent_operations fat12_ops = {
> +static const struct fatent_operations fat12_ops = {
>   .ent_blocknr= fat12_ent_blocknr,
>   .ent_set_ptr= fat12_ent_set_ptr,
>   .ent_bread  = fat12_ent_bread,
> @@ -255,7 +255,7 @@ static struct fatent_operations fat12_ops = {
>   .ent_next   = fat12_ent_next,
>  };
>  
> -static struct fatent_operations fat16_ops = {
> +static const struct fatent_operations fat16_ops = {
>   .ent_blocknr= fat_ent_blocknr,
>   .ent_set_ptr= fat16_ent_set_ptr,
>   .ent_bread  = fat_ent_bread,
> @@ -264,7 +264,7 @@ static struct fatent_operations fat16_ops = {
>   .ent_next   = fat16_ent_next,
>  };
>  
> -static struct fatent_operations fat32_ops = {
> +static const struct fatent_operations fat32_ops = {
>   .ent_blocknr= fat_ent_blocknr,
>   .ent_set_ptr= fat32_ent_set_ptr,
>   .ent_bread  = fat_ent_bread,
> @@ -320,7 +320,7 @@ static inline int fat_ent_update_ptr(struct super_block 
> *sb,
>int offset, sector_t blocknr)
>  {
>   struct msdos_sb_info *sbi = MSDOS_SB(sb);
> - struct fatent_operations *ops = sbi->fatent_ops;
> + const struct fatent_operations *ops = sbi->fatent_ops;
>   struct buffer_head **bhs = fatent->bhs;
>  
>   /* Is this fatent's blocks including this entry? */
> @@ -349,7 +349,7 @@ int fat_ent_read(struct inode *inode, struct fat_entry 
> *fatent, int entry)
>  {
>   struct super_block *sb = inode->i_sb;
>   struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
> - struct fatent_operations *ops = sbi->fatent_ops;
> + const struct fatent_operations *ops = sbi->fatent_ops;
>   int err, offset;
>   sector_t blocknr;
>  
> @@ -407,7 +407,7 @@ int fat_ent_write(struct inode *inode, struct fat_entry 
> *fatent,
> int new, int wait)
>  {
>   struct super_block *sb = inode->i_sb;
> - struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
> + const struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
>   int err;
>  
>   ops->ent_put(fatent, new);
> @@ -432,7 +432,7 @@ static inline int fat_ent_next(struct msdos_sb_info *sbi,
>  static inline int fat_ent_read_block(struct super_block *sb,
>struct fat_entry *fatent)
>  {
> - struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
> + const struct fatent_operations *ops = MSDOS_SB(sb)->fatent_ops;
>   sector_t blocknr;
>   int offset;
>  
> @@ -463,7 +463,7 @@ int fat_alloc_clusters(struct inode *inode, int *cluster, 
> int nr_cluster)
>  {
>   struct super_block *sb = inode->i_sb;
>   struct msdos_sb_info *sbi = MSDOS_SB(sb);
> - struct fatent_operations *ops = sbi->fatent_ops;
> + const struct fatent_operations *ops = sbi->fatent_ops;
>   struct fat_entry fatent, prev_ent;
>   struct buffer_head *bhs[MAX_BUF_PER_PAGE];
>   int i, count, err, nr_bhs, idx_clus;
> @@ -551,7 +551,7 @@ int fat_free_clusters(struct inode *inode, int cluster)
>  {
>   struct super_block *sb = inode->i_sb;
>   struct msdos_sb_info *sbi = MSDOS_SB(sb);
> - struct fatent_operations *ops = sbi->fatent_ops;
> + const struct fatent_operations *ops = sbi->fatent_ops;
>   struct fat_entry fatent;
>   struct buffer_head *bhs[MAX_BUF_PER_PAGE];
>   int i, err, nr_bhs;
> @@ -636,7 +636,7 @@ EXPORT_SYMBOL_GPL(fat_free_clusters);
>  static void fat_ent_reada(struct super_block *sb, struct fat_entry *fatent,
> u

Re: [PATCH v2 15/25] cris: nand: use the mtd instance embedded in struct nand_chip

[Jesper Nilsson]

On Tue, Dec 01, 2015 at 12:03:12PM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig  |7 +
 drivers/usb/gadget/Makefile |1 +
 drivers/usb/gadget/charger.c|  669 +++
 include/linux/usb/usb_charger.h |  164 ++
 4 files changed, 841 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..8d69dca 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,13 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config USB_CHARGER
+   bool "USB charger support"
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 598a67d..1e421c1 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -10,3 +10,4 @@ libcomposite-y:= usbstring.o config.o 
epautoconf.o
 libcomposite-y += composite.o functions.o configfs.o u_f.o
 
 obj-$(CONFIG_USB_GADGET)   += udc/ function/ legacy/
+obj-$(CONFIG_USB_CHARGER)  += charger.o
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..82a9973
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,669 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CUR_PROTECT(50)
+#define DEFAULT_SDP_CUR_LIMIT  (500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT  (1500 - DEFAULT_CUR_PROTECT)
+#define UCHGER_STATE_LENGTH(50)
+
+static DEFINE_IDA(usb_charger_ida);
+static struct bus_type usb_charger_subsys = {
+   .name   = "usb-charger",
+   .dev_name   = "usb-charger",
+};
+
+static struct usb_charger *dev_to_uchger(struct device *udev)
+{
+   return container_of(udev, struct usb_charger, dev);
+}
+
+static ssize_t sdp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
+}
+
+static ssize_t sdp_limit_store(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int sdp_limit;
+   int ret;
+
+   ret = kstrtouint(buf, 10, &sdp_limit);
+   if (ret < 0)
+   return ret;
+
+   ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+static DEVICE_ATTR_RW(sdp_limit);
+
+static ssize_t dcp_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+
+   return sprintf(buf, "%d\n", uchger->cur_limit.dcp_cur_limit);
+}
+
+static ssize_t dcp_limit_store(struct device *dev,
+

[PATCH v7 3/4] gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/charger.c |   43 --
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
index 82a9973..76e1a6f 100644
--- a/drivers/usb/gadget/charger.c
+++ b/drivers/usb/gadget/charger.c
@@ -272,7 +272,11 @@ EXPORT_SYMBOL_GPL(usb_charger_unregister_notify);
 enum usb_charger_type
 usb_charger_detect_type(struct usb_charger *uchger)
 {
-   if (uchger->psy) {
+   if (uchger->gadget && uchger->gadget->ops
+   && uchger->gadget->ops->get_charger_type) {
+   uchger->type =
+   uchger->gadget->ops->get_charger_type(uchger->gadget);
+   } else if (uchger->psy) {
union power_supply_propval val;
 
power_supply_get_property(uchger->psy,
@@ -479,6 +483,29 @@ usb_charger_plug_by_extcon(struct notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (!uchger)
+   return -EINVAL;
+
+   /* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED)
+   uchger_state = USB_CHARGER_PRESENT;
+   else if (state == USB_STATE_NOTATTACHED)
+   uchger_state = USB_CHARGER_REMOVE;
+   else
+   uchger_state = USB_CHARGER_DEFAULT;
+
+   usb_charger_notify_others(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
@@ -635,6 +662,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = ugadget->state;
 
/* register a new usb charger */
@@ -655,7 +683,18 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   return 0;
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   if (uchger->extcon_dev)
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB, &uchger->extcon_nb.nb);
+
+   ida_simple_remove(&usb_charger_ida, uchger->id);
+
+   return usb_charger_unregister(uchger);
 }
 
 static int __init usb_charger_sysfs_init(void)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 2/4] gadget: Support for the usb charger framework

[Baolin Wang]

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.

Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/udc/udc-core.c |   11 +++
 include/linux/usb/gadget.h|   11 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index f660afb..2727f01 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * struct usb_udc - describes one usb device controller
@@ -226,6 +227,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(&udc->dev.kobj, NULL, "state");
 }
@@ -405,8 +409,14 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
mutex_unlock(&udc_lock);
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
return 0;
 
+err5:
+   device_del(&udc->dev);
 err4:
list_del(&udc->list);
mutex_unlock(&udc_lock);
@@ -481,6 +491,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
device_unregister(&udc->dev);
+   usb_charger_exit(gadget);
device_unregister(&gadget->dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..52c19b1 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct usb_ep;
 
@@ -560,6 +561,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+   enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
 };
 
 /**
@@ -632,6 +634,8 @@ struct usb_gadget {
unsignedout_epnum;
unsignedin_epnum;
struct usb_otg_caps *otg_caps;
+   /* negotiate the power with the usb charger */
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
@@ -836,10 +840,17 @@ static inline int usb_gadget_vbus_connect(struct 
usb_gadget *gadget)
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
+   if (gadget->charger)
+   usb_charger_set_cur_limit_by_type(gadget->charger,
+   usb_charger_detect_type(gadget->charger), mA);
+
if (!gadget->ops->vbus_draw)
return -EOPNOTSUPP;
return gadget->ops->vbus_draw(gadget, mA);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
---
 drivers/power/wm831x_power.c |   69 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 72 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 7082301..043f1f4 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %dmA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +647,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(&pdev->dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ &power->usb_notify);
+   if (ret != 0) {
+   dev_err(&pdev->dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ &wm831x_power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to integrate with */
+   const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please r

Re: [PATCH 1/1] perf/x86/intel: Add perf core PMU support for Intel Knights Landing

[Peter Zijlstra]

On Mon, Dec 07, 2015 at 02:28:18PM -0800, Harish Chegondi wrote:
> Knights Landing core is based on Silvermont core with several differences.
> Like Silvermont, Knights Landing has 8 pairs of LBR MSRs. However, the
> LBR MSRs addresses match those of the Xeon cores' first 8 pairs of LBR MSRs


> +/* Knights Landing */
> +void intel_pmu_lbr_init_knl(void)
> +{
> + x86_pmu.lbr_nr = 8;
> + x86_pmu.lbr_tos= MSR_LBR_TOS;
> + x86_pmu.lbr_from   = MSR_LBR_NHM_FROM;
> + x86_pmu.lbr_to = MSR_LBR_NHM_TO;
> +
> + x86_pmu.lbr_sel_mask = LBR_SEL_MASK;
> + x86_pmu.lbr_sel_map  = snb_lbr_sel_map;

Also, unlike Silvermont, this thing seems to have hardware LBR filters.
So would it not be more accurate to say the KNL has a big core LBR
instead? (Note that this LBR setup isn't specific to Xeon's, all of the
Core chips have this, including the client parts).

> + pr_cont("8-deep LBR, ");
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH 21/23] staging: mt29f_spinand: switch to mtd_ooblayout_ops

[Boris Brezillon]

Hi Julian,

On Tue, 8 Dec 2015 10:59:53 +1100
Julian Calaby  wrote:

> Hi Boris,
> 
> On Tue, Dec 8, 2015 at 9:26 AM, Boris Brezillon
>  wrote:
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/staging/mt29f_spinand/mt29f_spinand.c | 44 
> > ---
> >  1 file changed, 26 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
> > b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> > index cb9d5ab..967d50a 100644
> > --- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
> > +++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
> > @@ -42,23 +42,29 @@ static inline struct spinand_state *mtd_to_state(struct 
> > mtd_info *mtd)
> >  static int enable_hw_ecc;
> >  static int enable_read_hw_ecc;
> >
> > -static struct nand_ecclayout spinand_oob_64 = {
> > -   .eccbytes = 24,
> > -   .eccpos = {
> > -   1, 2, 3, 4, 5, 6,
> > -   17, 18, 19, 20, 21, 22,
> > -   33, 34, 35, 36, 37, 38,
> > -   49, 50, 51, 52, 53, 54, },
> > -   .oobfree = {
> > -   {.offset = 8,
> > -   .length = 8},
> > -   {.offset = 24,
> > -   .length = 8},
> > -   {.offset = 40,
> > -   .length = 8},
> > -   {.offset = 56,
> > -   .length = 8},
> > -   }
> > +static int spinand_oob_64_eccpos(struct mtd_info *mtd, int eccbyte)
> > +{
> > +   if (eccbyte > 23)
> > +   return -ERANGE;
> > +
> > +   return ((eccbyte / 6) * 16) + 1;
> 
> Are you sure this is correct? My reading of this is that we'd get 1
> for eccbytes 0 through 5.
> 
> Would
> 
> ((eccbyte / 6) * 16) + (eccbyte % 6) + 1
> 
> be more correct?

Absolutely. I'll fix that.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v5:
 - Remove the notifier chain things from the gadget and introduce one callback
 function to report to the usb charger when the gadget state is changed.
 - Flesh out the port type detection which combines the USB negotiation and
 PMICs detection.
 - Supply the notification mechanism to userspace when charger state is changed.
 - Integrate with the vbus staff in the gadget API.
 - Spilt up the functionality for userspace with one file per USB charger type.

Baolin Wang (4):
  gadget: Introduce the usb charger framework
  gadget: Support for the usb charger framework
  gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c  |   69 
 drivers/usb/gadget/Kconfig|7 +
 drivers/usb/gadget/Makefile   |1 +
 drivers/usb/gadget/charger.c  |  708 +
 drivers/usb/gadget/udc/udc-core.c |   11 +
 include/linux/mfd/wm831x/pdata.h  |3 +
 include/linux/usb/gadget.h|   11 +
 include/linux/usb/usb_charger.h   |  164 +
 8 files changed, 974 insertions(+)
 create mode 100644 drivers/usb/gadget/charger.c
 create mode 100644 include/linux/usb/usb_charger.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: multi_v7_defconfig: Enable some drivers for LS1021A

[Alison Wang]

This patch enables some drivers for LS1021A, such as
GIANFAR, WATCHDOG, AUDIO, QSPI, I2C, ESDHC, EDMA, FTM.
QorIQ Clock Framework and Ramdisk support is also enabled.

Signed-off-by: Alison Wang 
---
 arch/arm/configs/multi_v7_defconfig | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index f6a2557..95e725c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -128,6 +128,7 @@ CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_QORIQ_CPUFREQ=y
 CONFIG_CPU_IDLE=y
 CONFIG_ARM_CPUIDLE=y
 CONFIG_NEON=y
@@ -182,8 +183,11 @@ CONFIG_MTD_NAND_ATMEL=y
 CONFIG_MTD_NAND_BRCMNAND=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_FSL_QUADSPI=y
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=65536
 CONFIG_AD525X_DPOT=y
 CONFIG_AD525X_DPOT_I2C=y
 CONFIG_ATMEL_TCLIB=y
@@ -210,6 +214,7 @@ CONFIG_HIX5HD2_GMAC=y
 CONFIG_SUN4I_EMAC=y
 CONFIG_MACB=y
 CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_GIANFAR=y
 CONFIG_IGB=y
 CONFIG_MV643XX_ETH=y
 CONFIG_MVNETA=y
@@ -226,6 +231,7 @@ CONFIG_MARVELL_PHY=y
 CONFIG_SMSC_PHY=y
 CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
+CONFIG_REALTEK_PHY=y
 CONFIG_MICREL_PHY=y
 CONFIG_FIXED_PHY=y
 CONFIG_USB_PEGASUS=y
@@ -312,6 +318,7 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=y
 CONFIG_I2C_DIGICOLOR=m
 CONFIG_I2C_GPIO=m
 CONFIG_I2C_EXYNOS5=y
+CONFIG_I2C_IMX=y
 CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_RIIC=y
 CONFIG_I2C_RK3X=y
@@ -330,6 +337,7 @@ CONFIG_SPI=y
 CONFIG_SPI_ATMEL=m
 CONFIG_SPI_CADENCE=y
 CONFIG_SPI_DAVINCI=y
+CONFIG_SPI_FSL_DSPI=y
 CONFIG_SPI_OMAP24XX=y
 CONFIG_SPI_ORION=y
 CONFIG_SPI_PL022=y
@@ -405,6 +413,7 @@ CONFIG_ARM_SP805_WATCHDOG=y
 CONFIG_ORION_WATCHDOG=y
 CONFIG_ST_LPC_WATCHDOG=y
 CONFIG_SUNXI_WATCHDOG=y
+CONFIG_IMX2_WDT=y
 CONFIG_TEGRA_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=y
 CONFIG_DIGICOLOR_WATCHDOG=y
@@ -525,6 +534,7 @@ CONFIG_SND_USB_AUDIO=y
 CONFIG_SND_SOC=m
 CONFIG_SND_ATMEL_SOC=m
 CONFIG_SND_ATMEL_SOC_WM8904=m
+CONFIG_SND_SOC_FSL_SAI=m
 CONFIG_SND_SOC_SH4_FSI=m
 CONFIG_SND_SOC_RCAR=m
 CONFIG_SND_SOC_RSRC_CARD=m
@@ -537,6 +547,7 @@ CONFIG_SND_SOC_TEGRA_TRIMSLICE=m
 CONFIG_SND_SOC_TEGRA_ALC5632=m
 CONFIG_SND_SOC_TEGRA_MAX98090=m
 CONFIG_SND_SOC_AK4642=m
+CONFIG_SND_SOC_SGTL5000=m
 CONFIG_SND_SOC_WM8978=m
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
@@ -577,6 +588,7 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_OF_ARASAN=y
 CONFIG_MMC_SDHCI_OF_AT91=y
+CONFIG_MMC_SDHCI_OF_ESDHC=y
 CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_MMC_SDHCI_DOVE=y
 CONFIG_MMC_SDHCI_TEGRA=y
@@ -653,6 +665,7 @@ CONFIG_DMADEVICES=y
 CONFIG_DW_DMAC=y
 CONFIG_AT_HDMAC=y
 CONFIG_AT_XDMAC=y
+CONFIG_FSL_EDMA=y
 CONFIG_MV_XOR=y
 CONFIG_TEGRA20_APB_DMA=y
 CONFIG_SH_DMAE=y
@@ -712,6 +725,7 @@ CONFIG_AK8975=y
 CONFIG_PWM=y
 CONFIG_PWM_ATMEL=m
 CONFIG_PWM_ATMEL_TCB=m
+CONFIG_PWM_FSL_FTM=y
 CONFIG_PWM_RENESAS_TPU=y
 CONFIG_PWM_ROCKCHIP=m
 CONFIG_PWM_SAMSUNG=m
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] of: fix declaration of of_io_request_and_map

[Sudip Mukherjee]

We are having build failure with linux-next for sparc allmodconfig with
the error messages:

drivers/built-in.o: In function `meson6_timer_init':
meson6_timer.c:(.init.text+0x5fe8): undefined reference to 
`of_io_request_and_map'
drivers/built-in.o: In function `mtk_timer_init':
mtk_timer.c:(.init.text+0x6af0): undefined reference to `of_io_request_and_map'
drivers/built-in.o: In function `asm9260_timer_init':
asm9260_timer.c:(.init.text+0x6c48): undefined reference to 
`of_io_request_and_map'

CONFIG_OF is defined for sparc so it is expected that we have a
definition of of_io_request_and_map() but of/address.c is only compiled
if it is !SPARC. In other words, CONFIG_OF_ADDRESS is not defined for
sparc so we get the build failure.

Fixes: e572f844ca66 ("clocksource/drivers/meson6: Add the COMPILE_TEST option")
Fixes: bec8c4617611 ("clocksource/drivers/mediatek: Add the COMPILE_TEST 
option")
Fixes: 4a373b45f94a ("clocksource/drivers/asm9260: Add the COMPILE_TEST option")
Cc: Daniel Lezcano 
Signed-off-by: Sudip Mukherjee 
---

v1: had a complicated set of #ifdefs
v2: i messed up and resulted in build failure of some other arch where
CONFIG_OF is not defined.
v3: tested with allmodconfig of x86_64, defconfig of alpha and mips.
v4: changed subject and commit message. And the of_io_request_and_map()
is moved under existing #ifdef instead of defining one more section.


 include/linux/of_address.h | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 507daad..4d6c50a 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -36,6 +36,8 @@ extern struct device_node *of_find_matching_node_by_address(
const struct of_device_id *matches,
u64 base_address);
 extern void __iomem *of_iomap(struct device_node *device, int index);
+void __iomem *of_io_request_and_map(struct device_node *device,
+   int index, const char *name);
 
 /* Extract an address from a device, returns the region size and
  * the address space flags too. The PCI version uses a BAR number
@@ -58,6 +60,14 @@ extern int of_dma_get_range(struct device_node *np, u64 
*dma_addr,
 extern bool of_dma_is_coherent(struct device_node *np);
 #else /* CONFIG_OF_ADDRESS */
 
+#include 
+
+static inline void __iomem *of_io_request_and_map(struct device_node *device,
+ int index, const char *name)
+{
+   return IOMEM_ERR_PTR(-EINVAL);
+}
+
 static inline u64 of_translate_address(struct device_node *np,
   const __be32 *addr)
 {
@@ -112,8 +122,6 @@ static inline bool of_dma_is_coherent(struct device_node 
*np)
 extern int of_address_to_resource(struct device_node *dev, int index,
  struct resource *r);
 void __iomem *of_iomap(struct device_node *node, int index);
-void __iomem *of_io_request_and_map(struct device_node *device,
-   int index, const char *name);
 #else
 
 #include 
@@ -128,12 +136,6 @@ static inline void __iomem *of_iomap(struct device_node 
*device, int index)
 {
return NULL;
 }
-
-static inline void __iomem *of_io_request_and_map(struct device_node *device,
-   int index, const char *name)
-{
-   return IOMEM_ERR_PTR(-EINVAL);
-}
 #endif
 
 #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] powercap/rapl: reduce ipi calls

[Peter Zijlstra]

On Mon, Dec 07, 2015 at 03:23:22PM -0800, Srinivas Pandruvada wrote:
> On Mon, 2015-12-07 at 15:01 -0800, Jacob Pan wrote:
> > +struct rapl_msr_action {
> > +   u32 msr;
> > +   unsigned long long value;
> > +   int shift;
> > +   u64 mask;
> > +};
> > +
> > +static void rapl_write_data_cpu(void *info)
> > +{
> > +   u64 msr_val;
> > +   struct rapl_msr_action *ra = (struct rapl_msr_action *)info;
> > +
> > +   rdmsrl_safe(ra->msr, &msr_val);
> > +   msr_val &= ~ra->mask;
> > +   msr_val |= ra->value << ra->shift;
> > +   wrmsrl_safe(ra->msr, msr_val);
> What about adding additional common interface
> wrmsrl_safe_update(), so that everyone can use this?
> 

In which case you want a return value. Also, instead of the value,shift
pair I would add another u64.

Something like:

struct msr_action {
u32 msr;
int ret;
u64 mask, bits;
};

static void msr_update_function(void *info)
{
struct msr_action *ma = info;
int ret = 0;
u64 val;

ret = rdmsrl_safe(ma->msr, &val);
if (ret)
goto out;

val &= ma->mask;
val |= ma->bits;

ret = wrmsrl_safe(ma->msr, val);

out:
ma->ret = ret;
}

int rmwmsrl_safe_on_cpu(u32 msr, int cpu, u64 mask, u64 bits)
{
struct msr_action ma = {
.msr = msr,
.mask = mask,
.bits = bits,
};
int ret;

ret = smp_call_function_single(cpu, msr_update_func, &ma, 1);
if (!ret)
ret = ma.ret;

return ret;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:perf/core] perf/x86: Use INST_RETIRED.PREC_DIST for cycles: ppp

[Peter Zijlstra]

On Tue, Dec 08, 2015 at 06:36:04AM +0100, Ingo Molnar wrote:

> So I checked my NHM box with your latest queue and it now works correctly. Do 
> you 
> have any idea what the difference is/was?

Sadly, no clue :/

I went over those patches and cannot find anything that should affect
NHM (or <=SNB in fact).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/3] reduce latency of direct async compaction

[Aaron Lu]

On Tue, Dec 08, 2015 at 03:51:16PM +0900, Joonsoo Kim wrote:
> On Tue, Dec 08, 2015 at 01:14:39PM +0800, Aaron Lu wrote:
> > On Tue, Dec 08, 2015 at 09:41:18AM +0900, Joonsoo Kim wrote:
> > > On Mon, Dec 07, 2015 at 04:59:56PM +0800, Aaron Lu wrote:
> > > > On Mon, Dec 07, 2015 at 04:35:24PM +0900, Joonsoo Kim wrote:
> > > > > It looks like overhead still remain. I guess that migration scanner
> > > > > would call pageblock_pfn_to_page() for more extended range so
> > > > > overhead still remain.
> > > > > 
> > > > > I have an idea to solve his problem. Aaron, could you test following 
> > > > > patch
> > > > > on top of base? It tries to skip calling pageblock_pfn_to_page()
> > > > 
> > > > It doesn't apply on top of 25364a9e54fb8296837061bf684b76d20eec01fb
> > > > cleanly, so I made some changes to make it apply and the result is:
> > > > https://github.com/aaronlu/linux/commit/cb8d05829190b806ad3948ff9b9e08c8ba1daf63
> > > 
> > > Yes, that's okay. I made it on my working branch but it will not result in
> > > any problem except applying.
> > > 
> > > > 
> > > > There is a problem occured right after the test starts:
> > > > [   58.080962] BUG: unable to handle kernel paging request at 
> > > > ea008218
> > > > [   58.089124] IP: [] compaction_alloc+0xf9/0x270
> > > > [   58.096109] PGD 107ffd6067 PUD 207f7d5067 PMD 0
> > > > [   58.101569] Oops:  [#1] SMP 
> > > 
> > > I did some mistake. Please test following patch. It is also made
> > > on my working branch so you need to resolve conflict but it would be
> > > trivial.
> > > 
> > > I inserted some logs to check whether zone is contiguous or not.
> > > Please check that normal zone is set to contiguous after testing.
> > 
> > Yes it is contiguous, but unfortunately, the problem remains:
> > [   56.536930] check_zone_contiguous: Normal
> > [   56.543467] check_zone_contiguous: Normal: contiguous
> > [   56.549640] BUG: unable to handle kernel paging request at 
> > ea008218
> > [   56.557717] IP: [] compaction_alloc+0xf9/0x270
> > [   56.564719] PGD 107ffd6067 PUD 207f7d5067 PMD 0
> > 
> 
> Maybe, I find the reason. cc->free_pfn can be initialized to invalid pfn
> that isn't checked so optimized pageblock_pfn_to_page() causes BUG().
> 
> I add work-around for this problem at isolate_freepages(). Please test
> following one.

Still no luck and the error is about the same:

[   64.727792] check_zone_contiguous: Normal
[   64.733950] check_zone_contiguous: Normal: contiguous
[   64.741610] BUG: unable to handle kernel paging request at ea008218
[   64.749708] IP: [] compaction_alloc+0xf9/0x270
[   64.756806] PGD 107ffd6067 PUD 207f7d5067 PMD 0 
[   64.762302] Oops:  [#1] SMP 
[   64.766294] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 
dns_resolver netconsole sg sd_mod x86_pkg_temp_thermal coretemp kvm_intel kvm 
mgag200 irqbypass crct10dif_pclmul ttm crc32_pclmul crc32c_intel drm_kms_helper 
ahci syscopyarea sysfillrect sysimgblt snd_pcm libahci fb_sys_fops snd_timer 
snd sb_edac aesni_intel soundcore lrw drm gf128mul pcspkr edac_core 
ipmi_devintf glue_helper ablk_helper cryptd libata ipmi_si shpchp wmi 
ipmi_msghandler acpi_power_meter acpi_pad
[   64.816579] CPU: 19 PID: 1526 Comm: usemem Not tainted 
4.4.0-rc3-00025-gf60ea5f #1
[   64.825419] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
SE5C610.86B.01.01.0008.021120151325 02/11/2015
[   64.837483] task: 88168a0aca80 ti: 88168a564000 
task.ti:88168a564000
[   64.846264] RIP: 0010:[]  [] 
compaction_alloc+0xf9/0x270
[   64.856147] RSP: :88168a567940  EFLAGS: 00010286
[   64.862520] RAX: 88207ffdcd80 RBX: 88168a567ac0 RCX: 88207ffdcd80
[   64.870944] RDX: 0208 RSI: 88168a567ac0 RDI: 88168a567ac0
[   64.879377] RBP: 88168a567990 R08: ea008200 R09: 
[   64.887813] R10:  R11: 0001ae88 R12: ea008200
[   64.896254] R13: ea0059f20780 R14: 0208 R15: 0208
[   64.904704] FS:  7f2d4e6e8700() GS:88203444() 
knlGS:
[   64.914232] CS:  0010 DS:  ES:  CR0: 80050033
[   64.921151] CR2: ea008218 CR3: 002015771000 CR4: 001406e0
[   64.929635] Stack:
[   64.932413]  88168a568000 0167ca00 81193196 
88207ffdcd80
[   64.941292]  0208 ea0059f207c0 88168a567ac0 
ea0059f20780
[   64.950179]  ea0059f207e0 88207ffdcd80 88168a567a20 
811d097e
[   64.959071] Call Trace:
[   64.962364]  [] ? update_pageblock_skip+0x56/0xa0
[   64.969939]  [] migrate_pages+0x28e/0x7b0
[   64.976728]  [] ? update_pageblock_skip+0xa0/0xa0
[   64.984312]  [] ? __pageblock_pfn_to_page+0xe0/0xe0
[   64.992093]  [] compact_zone+0x38a/0x8e0
[   64.998811]  [] compact_zone_order+0x6d/0x90
[   65.005926]  [] ? get_page_from_freelist+0xd4/0xa20
[   65.013861]  [] try_to_compact_pages+0xec/0x210
[   65.021212]  [] ? 
sdebug

Re: [tip:perf/core] perf/x86: Use INST_RETIRED.PREC_DIST for cycles: ppp

[Peter Zijlstra]

On Tue, Dec 08, 2015 at 09:50:26AM +0100, Peter Zijlstra wrote:
> On Tue, Dec 08, 2015 at 06:36:04AM +0100, Ingo Molnar wrote:
> 
> > So I checked my NHM box with your latest queue and it now works correctly. 
> > Do you 
> > have any idea what the difference is/was?
> 
> Sadly, no clue :/
> 
> I went over those patches and cannot find anything that should affect
> NHM (or <=SNB in fact).

Oh wait, I spoke too soon, the two new patches affect everything with
PEBS. And esp. the latter one:

  lkml.kernel.org/r/1449177740-5422-2-git-send-email-a...@firstfloor.org

But note that this is a pre-existing issue and should not be changed
by the skl-:pp and :ppp patches.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

[Thomas Petazzoni]

Hello Thomas,

On Sun, 6 Dec 2015 10:28:15 +0100 (CET), Thomas Gleixner wrote:

> Second thoughts. That network driver example does not make sense.
> 
> You have a suspend/resume mechanism and a cpu hotplug machinery in
> that driver, right? So that should be responsible for
> disabling/enabling the per cpu interrupts. I don't think it's the
> proper way to do that in the irq chip driver at some random point
> during resume as you'd reenable interrupts on cpus which are not
> online yet.

The irqchip driver would re-enable the per-CPU interrupts in a CPU
notifier, so only when the secondary CPUs come online again after
resume.

When a device driver uses a normal (non per-CPU) interrupt, then it
doesn't have to take care of disabling the interrupt on suspend and
re-enabling the interrupt on resume at the interrupt controller level.
This is all transparently handled by the irqchip driver.

Why should the handling of per-CPU interrupts be different and require
explicit handling from each device driver rather than being
transparently handled by the irqchip driver ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region

[Stanimir Varbanov]

On 12/03/2015 03:35 PM, Stanimir Varbanov wrote:
> Add 'write memory' barrier after enable region in PCIE_ATU_CR2
> register. The barrier is needed to ensure that the region enable
> request has been reached it's destination at time when we
> read/write to PCI configuration space.
> 
> Without this barrier PCI device enumeration during kernel boot
> is not reliable, and reading configuration space for particular
> PCI device on the bus returns zero aka no device.

Anand, Jingoo, what is your opinion?

> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/pci/host/pcie-designware.c |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-designware.c 
> b/drivers/pci/host/pcie-designware.c
> index 02a7452bdf23..ed4dc2e2553b 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
> *pp, int index,
>   dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
>   dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
>   dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
> + /*
> +  * ensure that the ATU enable has been happaned before accessing
> +  * pci configuration/io spaces through dw_pcie_cfg_[read|write].
> +  */
> + wmb();
>  }
>  
>  static struct irq_chip dw_msi_irq_chip = {
> 


-- 
regards,
Stan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ques: [kernel/time/*] Is there any disadvantage in using usleep_range for more than 20ms delay ?

[Clemens Ladisch]

Aniroop Mathur wrote:
> As in the kernel documentation, it is mentioned to use msleep for
> 10ms+ delay, I am confused whether there would be any disadvantage in
> using usleep_range for higher delays values because normally drivers
> have variety of delays used (2, 10, 20, 40, 100, 500 ms).
>
> So, could you please help to confirm that if we use usleep_range for
> inserting delays greater than 20 ms, would it be harmful or beneficial
> or does not make any difference at all ?

As the documentation told you, usleep_range() is likely to require
a separate interrupt, while msleep() is likely to round to some other,
already-scheduled interrupt.  The former is possibly harmful regarding
CPU and power usage; you have to balance it against your need for
accuracy.

(And usleep_range() has a 32-bit nanosecond limit on 32-bit
architectures.)


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Sebastian Andrzej Siewior]

* Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:

>The backtrace might be OK (maybe slightly overkill), but all the
>stack addresses are certainly irrelevant and distracting.  We only
>need enough to recognize the problem.  I don't think the modules list
>is relevant either.

I would shorten it to the bare minimum. Also the patch description
itself could be truncated to the required bits…

>> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
>> index 8c36880..0415192 100644
>> --- a/drivers/pci/host/pci-dra7xx.c
>> +++ b/drivers/pci/host/pci-dra7xx.c
>> @@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct 
>> dra7xx_pcie *dra7xx,
>>  return -EINVAL;
>>  }
>>  
>> +/*
>> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
>> + * On -RT and if kernel is booting with "threadirqs" cmd line parameter
>> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
>> + * in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
>> + * which, in turn, will be resolved to handle_simple_irq() call.
>> + * The handle_simple_irq() expected to be called with IRQ disabled, as
>> + * result kernle will display warning:
>> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
>> + */

…not to mention this piece. d7ce4377494a ("powerpc/fsl_msi: mark the msi
cascade handler IRQF_NO_THREAD") fixes the same bug in arch/ppc so they
bypassed you fixing it.

>>  ret = devm_request_irq(&pdev->dev, pp->irq,
>> -   dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
>> +   dra7xx_pcie_msi_irq_handler,
>> +   IRQF_SHARED | IRQF_NO_THREAD,
>> "dra7-pcie-msi", pp);
>
>There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
>and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
>why not?

You are right. The request for the handler exynos_pcie_msi_irq_handler(),
imx6_pcie_msi_handler() and spear13xx_pcie_irq_handler() needs same
treatment.
Additionally we have:

arch/mips/pci/msi-octeon.c: if (request_irq(OCTEON_IRQ_PCI_MSI0, 
octeon_msi_interrupt0,
arch/sparc/kernel/pci_msi.c:err = request_irq(irq, sparc64_msiq_interrupt, 
0,
drivers/pci/host/pci-tegra.c:   err = request_irq(msi->irq, tegra_pcie_msi_irq, 
0,
drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(&pdev->dev, msi->irq1, 
rcar_pcie_msi_irq,
drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(&pdev->dev, msi->irq2, 
rcar_pcie_msi_irq,
drivers/pci/host/pcie-xilinx.c: err = devm_request_irq(dev, port->irq, 
xilinx_pcie_intr_handler,

which require the same kind of fix…

>I see your discussion about DRA7 hardware design, but my impression is
>that this problem affects anybody who calls dw_handle_msi_irq() from a
>handler registered with IRQF_SHARED.

… brecause all of them invoke generic_handle_irq() from the requsted
handler. generic_handle_irq grabs raw_locks and this needs to run in
raw-irq context.
IRQF_SHARED could probably go away. The IRQ is mostlikely exclusive
assigned in each SoC for MSI interrupt demux.

>Bjorn

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] perf/x86/intel/uncore: Add Knights Landing uncore PMU support

[Peter Zijlstra]

On Mon, Dec 07, 2015 at 02:32:32PM -0800, Harish Chegondi wrote:
> @@ -981,6 +990,8 @@ static int __init uncore_pci_init(void)
>   break;
>   case 61: /* Broadwell */
>   ret = bdw_uncore_pci_init();
> + case 87: /* Knights Landing */
> + ret = knl_uncore_pci_init();
>   break;
>   default:
>   return 0;
> @@ -1289,6 +1300,8 @@ static int __init uncore_cpu_init(void)
>   break;
>   case 86: /* BDX-DE */
>   bdx_uncore_cpu_init();
> + case 87: /* Knights Landing */
> + knl_uncore_cpu_init();
>   break;
>   default:

Surely you need some extra break statements in there?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

[Gregory CLEMENT]

Hi Felipe,
 
 On lun., déc. 07 2015, Felipe Balbi  wrote:

> Hi,
>
> Gregory CLEMENT  writes:
>> Hi Felipe,
>>
>> I am going back on this subject (again :) )
>>  
>>  On mar., oct. 20 2015, Gregory CLEMENT  
>> wrote:
>>
>>> Hi Felipe,
>>>  
>>>  On lun., oct. 05 2015, Felipe Balbi  wrote:
>>>
>>>
> So after many tests on different devices, 200ms is enough for most of
> them, but for one, 2000ms (2s) was needed!
>
> I see several option:
> - adding a sysfs entry to setup the time
> - adding a debugs entry entry
> - adding configuration option in menuconfig
> - using 2000ms and hopping it was enough for everyone
>
> My preference would go to the first option, what is your opinion?

 I'm not sure if either of them is good. man 2s is just too large. If the
>>
>> Well 2s is lon I agree, but currently instead of 2s we have an infinite
>> wait, which is worse!
>>
 device isn't following the specification, I'm afraid that device needs
 to be fixed.
>>
>> I agree but these devices are for most of them USB stick that we find in
>> retail. We have no influence on them, so we have to do with them, even
>> if they do not follow the sepc.
>>
>> So what about using configfs or sysfs to let the user confgiure this
>> value if needed?
>
> iff we have to; I'm still not 100% convinced.
>
>> I go back on this because, your suggestion didn't work. At least, I
>> didn't manage to make it improve the situation.
>>
>> Thanks,
>>

 I think the real issue here is the lack of a disconnect IRQ from AM335x
 devices. But here's something I've been meaning to test but never had
 time. If you look into AM335x address space, there's a bit in the
 wrapper which tells it to use the standard MUSB registers for IRQ,
 instead of the TI-specific thing. Can you see if we get a disconnect IRQ
 with that ?

 TRM is at [1], see page 2566. Basically, if you set bit 3 in register
 offset 0x1014, then it should use Mentor IRQ registers. If that works,
 quite a few problems will actually vanish :-p
>>>
>>> So I tried it with the following patch:
>>>
>>> -
>>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>>> index c791ba5..c714500 100644
>>> --- a/drivers/usb/musb/musb_dsps.c
>>> +++ b/drivers/usb/musb/musb_dsps.c
>>> @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb)
>>>  
>>> /* Reset the musb */
>>> dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
>>> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
>
> overwritting reset.
>
>>> musb->isr = dsps_interrupt;
>>>  
>>> @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb)
>>> if (session_restart || !glue->sw_babble_enabled) {
>>> dev_info(musb->controller, "Restarting MUSB to recover from 
>>> Babble\n");
>>> dsps_writel(musb->ctrl_base, wrp->control, (1 << 
>>> wrp->reset));
>>> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
>
> here too. No wonder it won't work, right :-)
>
>>> I am not very familiar with that driver but my understanding was that
>>> the Mentor IRQ registeres are managed by the musb_interrupt() function
>>> which is called from the dsps_interrupt() interrupt handler.
>>>
>>> Am I right?
>
> yeah, however the way IRQs are reported is a different thing. AM335x
> introduced its own IRQ reporting scheme which, basically, reads MUSB
> generic IRQ status registers and reports on an AM335x specific
> register. No idea why TI did that for AM335x devices.
>
>>> if it is the case then it didn't fix the issue I had.
>>>
>>> I activated the following debug line:
>>>
>>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"
>>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012"
>>>
>>> But I didn't get any interrupt while disconnecting the cable without any
>>> device connected on it (whereas I got an interrupt when I connected it).
>>>
>>> Note that I applied this patch instead of the "usb: musb: dsps: handle
>>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ?
>
> yeah, that's what I had in mind. But your patch seems wrong :-)
>
> I tried writing a more correct version here and found 2 issues:
>
> a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's
> registers
>
> b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note
> that according to TRM, RESET_ISOLATION _must_ be set prior to a soft
> reset and cleared afterwards. But right after setting RESET_ISOLATION,
> if I try a read of CTRL, it'll hang forever.

The datasheet seems not very coherent about it,

on one side we have:
"This bit should be set high prior to setting bit 0 and cleared after bit 0
is cleared."

and on the other side:
"Both the soft_reset and soft_reset_isolation bits should be asserted
simultaneously."

The hang you saw could be explained by the following:
"Setting only

Re: [PATCH v2] perf/x86: fix filter_events() bug with event mappings

[Peter Zijlstra]

On Mon, Dec 07, 2015 at 08:33:25PM +0100, Stephane Eranian wrote:
> Fixes: 8300daa26 ("perf/x86: Filter out undefined events from sysfs events 
> attribute")

Please put the below in your .gitconfig, the alias is just a convenient
helper to generate the right string, but the abbrev is the important
part, we've already had hash collisions with the short thingies.


[core]
abbrev = 12
[alias]
one = show -s --pretty='format:%h (\"%s\")'


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch V2] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

[Borislav Petkov]

On Mon, Dec 07, 2015 at 08:41:43PM -0500, Raj, Ashok wrote:
> On Tue, Dec 08, 2015 at 12:25:24AM +0100, Borislav Petkov wrote:
> > 
> > Did you miss my statement in my previous mail where I said that the MCE
> > is being raised only on the cores of node 0?
> > 
> 
> That's right.. but i think if MCE is only given to node0, then the system 
> would panic eveytime with or without the patch. which is why i got confused.
> 
> I somehow misunderstood that with this patch the system didn't panic.

No, the system did panic in both times. The "strange" observation is
that the MCE gets reported only on the cores on node 0. Or at least only
the printks from mce_panic() on the cores on node0 reach the serial
console.

If we really broadcast only on node0, then that would be a problem if
the corrupted data leaves the node and manages to corrupt storage when
written out on some of the other nodes. I'm not sure if the kernel
panicking the whole system is on time and there's not a small window
between the detection and the panicking, in which the corruption might
happen.

If so, this'd defeat the purpose of MCE broadcasting but I'm just
hypothesizing here.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/4] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Jean-Francois Moine]

On Tue, 8 Dec 2015 09:32:24 +0100
Maxime Ripard  wrote:

> If the H3 display block is done the same way than the A10 (and later)
> one on this aspect, then the TCON has two channels with two different
> streaming (or functional, you pick the name) clocks. The channel 0 is
> usually used for RGB, the channel 1 for HDMI, composite and VGA.
> 
> Maybe they just added different bus gates for those two different
> channels, and moved HDMI to the channel 0.
> 
> Anyway, that can always be changed later on if we have more clue on
> what's going on.

I don't know about the other Allwinner chips, and your DRM driver for
these ones cannot be reused for the H3 because its display engine
(DE.2) is completely different.

The DE2 runs at 432MHz and treats both LCDs. The TCON1 runs at a fixed
rate, 200MHz, and the streaming rates are defined by the HDMI (LCD0) and
TCON0 (LCD1) clocks.

BTW, I hope to submit a H3 DRM driver before new year.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net 1/2] net: cadence: macb: Disable USRIO register on some platforms

[Neil Armstrong]

Hi Josh,

2015-12-07 20:32 GMT+01:00 Josh Cartwright :
> On Mon, Dec 07, 2015 at 11:58:33AM +0100, Neil Armstrong wrote:
>> On some platforms, the macb integration does not use the USRIO
>> register to configure the (R)MII port and clocks.
>> When the register is not implemented and the MACB error signal
>> is connected to the bus error, reading or writing to the USRIO
>> register can trigger some Imprecise External Aborts on ARM platforms.
>> ---
>
> Does this make sense to even be a separate bool device tree property?
>
> This sort of configuration is typically done by:
>1. Creating a new 'caps' bit; relevant codepaths check that bit
>2. Creating a new "compatible" string for your platform's macb
>   instance
>3. Creating a new 'struct macb_config' instance for your platform,
>   setting any relevant caps bits when it is selected.
>
>   Josh

I see the point, but according to the User Guide :
>User I/O Register
> The MACB design provides up to 16 inputs and 16 outputs,
> for which the state of the I/O may
> be read or set under the control of the processor interface.
> If the user I/O is disabled as a configuration option, this address space is 
> defined
> as reserved, and hence will be a read-only register of value 0x0.

On the design I worked on, the macb_user_* signals were commented,
thus disabling this register.

The implementation is not mandatory, and the "generic" macb compatible
"cdns,macb" should disable
usage of USRIO register by default and be only used for platform
specific macb instances...

Is it OK if I add a new 'caps' bit and use it for the "generic" macb instance ?

For the device tree property, it should be safe to have the generic
instances of macb and gem to
rely on these properties instead of hardcoded instances.
(it's the biggest aim of device tree, no ? no more hardcoded 'caps' bit ?)
The "no-usrio" and other should eventually map 'caps' bits along the
generic instances.

Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Lucas Stach]

Hi Bjorn,

Am Montag, den 07.12.2015, 21:33 -0600 schrieb Bjorn Helgaas:
> [+cc Jingoo (exynos), Richard, Lucas (imx6), Pratyush (spear13xx)]
> 
> On Fri, Dec 04, 2015 at 11:22:50PM +0200, Grygorii Strashko wrote:
> > On 12/04/2015 08:46 PM, Bjorn Helgaas wrote:
> > > Hi Grygorii,
[...]
> > >>   
> > >> +/*
> > >> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
> > >> + * On -RT and if kernel is booting with "threadirqs" cmd line 
> > >> parameter
> > >> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded 
> > >> but,
> > >> + * in the same time, it's IRQ dispatcher and calls 
> > >> generic_handle_irq(),
> > >> + * which, in turn, will be resolved to handle_simple_irq() call.
> > >> + * The handle_simple_irq() expected to be called with IRQ 
> > >> disabled, as
> > >> + * result kernle will display warning:
> > >> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
> > >> + */
> > >>  ret = devm_request_irq(&pdev->dev, pp->irq,
> > >> -   dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
> > >> +   dra7xx_pcie_msi_irq_handler,
> > >> +   IRQF_SHARED | IRQF_NO_THREAD,
> > >> "dra7-pcie-msi", pp);
> > > 
> > > There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
> > > and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
> > > why not?
> > > 
> > > I see your discussion about DRA7 hardware design, but my impression is
> > > that this problem affects anybody who calls dw_handle_msi_irq() from a
> > > handler registered with IRQF_SHARED.
> > 
> > Issue fixed by this patch is not related to IRQF_SHARED. 
> > It will happen on -RT or if kernel will boot with "threadirqs" cmd line 
> > parameter
> > - in both cases these PCI IRQ handlers will be forced to be threaded and,
> > as result, generic_handle_irq() will produce above backtrace.
> > 
> > Personally, I don't have strong opinion about "should similar change be 
> > applied
> > to other PCI drivers or not?" And I think, that owners of those driver 
> > should
> > make such decision.
> 
> If the same issue affects several drivers, I'd like to see them all
> handle it the same way.  Otherwise, somebody coming along later will
> wonder why they're different, and there won't be a good answer.
> 
> I cc'd the other maintainers to see what they think.
> 
Yes, this should absolutely be changed in all drivers, based on the DW
core. There were some patches for this already, but apparently they have
not been applied, because some review feedback wasn't taken care of.

I have a patch titled "PCI: designware: Mark the msi cascade handler
IRQF_NO_THREAD" in my inbox that did this, and I still think it's the
right thing to do.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: multi_v7_defconfig: Enable some drivers for LS1021A

[Arnd Bergmann]

On Tuesday 08 December 2015 16:38:03 Alison Wang wrote:
> This patch enables some drivers for LS1021A, such as
> GIANFAR, WATCHDOG, AUDIO, QSPI, I2C, ESDHC, EDMA, FTM.
> QorIQ Clock Framework and Ramdisk support is also enabled.
> 
> Signed-off-by: Alison Wang 
> ---

I think most of these can be made loadable modules, please do that
and only leave as much built-in as you need for booting.

Otherwise looks ok.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/12] selftests/x86: Extend Makefile to allow 64-bit only tests

[Borislav Petkov]

On Mon, Dec 07, 2015 at 01:51:26PM -0800, Andy Lutomirski wrote:
> There aren't any yet, but there might be a few some day.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  tools/testing/selftests/x86/Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/x86/Makefile 
> b/tools/testing/selftests/x86/Makefile
> index 389701f59940..a460fe7c5365 100644
> --- a/tools/testing/selftests/x86/Makefile
> +++ b/tools/testing/selftests/x86/Makefile
> @@ -8,8 +8,9 @@ TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs 
> ldt_gdt syscall_nt ptr
>  TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault sigreturn 
> test_syscall_vdso unwind_vdso
>  
>  TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
> +TARGETS_C_64BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_64BIT_ONLY)
>  BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
> -BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
> +BINARIES_64 := $(TARGETS_C_64BIT_ALL:%=%_64)
>  
>  CFLAGS := -O2 -g -std=gnu99 -pthread -Wall
>  
> @@ -37,7 +38,7 @@ clean:
>  $(TARGETS_C_32BIT_ALL:%=%_32): %_32: %.c
>   $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
>  
> -$(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c
> +$(TARGETS_C_64BIT_ALL:%=%_64): %_64: %.c
>   $(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
>  
>  # x86_64 users should be encouraged to install 32-bit libraries
> -- 

It doesn't build some of the tests here if I run make in the x86 dir.
This is unrelated but maybe for the future we should add some feature
testing like perf tool does to warn people if stuff is missing on the
system...

$ cd tools/testing/selftests/x86
$ make
gcc -m32 -o single_step_syscall_32 -O2 -g -std=gnu99 -pthread -Wall  
single_step_syscall.c -lrt -ldl -lm
gcc -m32 -o sysret_ss_attrs_32 -O2 -g -std=gnu99 -pthread -Wall  
sysret_ss_attrs.c -lrt -ldl -lm
gcc -m32 -o ldt_gdt_32 -O2 -g -std=gnu99 -pthread -Wall  ldt_gdt.c -lrt -ldl -lm
gcc -m32 -o syscall_nt_32 -O2 -g -std=gnu99 -pthread -Wall  syscall_nt.c -lrt 
-ldl -lm
gcc -m32 -o ptrace_syscall_32 -O2 -g -std=gnu99 -pthread -Wall  
ptrace_syscall.c raw_syscall_helper_32.S -lrt -ldl -lm
gcc -m32 -o entry_from_vm86_32 -O2 -g -std=gnu99 -pthread -Wall  
entry_from_vm86.c -lrt -ldl -lm
gcc -m32 -o syscall_arg_fault_32 -O2 -g -std=gnu99 -pthread -Wall  
syscall_arg_fault.c -lrt -ldl -lm
gcc -m32 -o sigreturn_32 -O2 -g -std=gnu99 -pthread -Wall  sigreturn.c -lrt 
-ldl -lm
gcc -m32 -o test_syscall_vdso_32 -O2 -g -std=gnu99 -pthread -Wall  
test_syscall_vdso.c thunks_32.S -lrt -ldl -lm
In file included from ptrace_syscall.c:6:0:
/usr/include/sys/syscall.h:24:24: fatal error: asm/unistd.h: No such file or 
directory
compilation terminated.
In file included from entry_from_vm86.c:14:0:
/usr/include/sys/syscall.h:24:24: fatal error: asm/unistd.h: No such file or 
directory
compilation terminated.
...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/5] clk: shmobile: Add new CPG/MSSR driver core

[Geert Uytterhoeven]

On Sat, Dec 5, 2015 at 4:08 AM, Laurent Pinchart
 wrote:
>> +static inline int cpg_mssr_add_clk_domain(struct device *dev,
>> +   const unsigned int *core_pm_clks,
>> +   unsigned int num_core_pm_clks) {}
>
> The function is missing a return statement.

Thank you, will include for v7 and/or final pull request.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net 1/2] net: cadence: macb: Disable USRIO register on some platforms

[Nicolas Ferre]

Le 08/12/2015 10:21, Neil Armstrong a écrit :
> Hi Josh,
> 
> 2015-12-07 20:32 GMT+01:00 Josh Cartwright :
>> On Mon, Dec 07, 2015 at 11:58:33AM +0100, Neil Armstrong wrote:
>>> On some platforms, the macb integration does not use the USRIO
>>> register to configure the (R)MII port and clocks.
>>> When the register is not implemented and the MACB error signal
>>> is connected to the bus error, reading or writing to the USRIO
>>> register can trigger some Imprecise External Aborts on ARM platforms.
>>> ---
>>
>> Does this make sense to even be a separate bool device tree property?
>>
>> This sort of configuration is typically done by:
>>1. Creating a new 'caps' bit; relevant codepaths check that bit
>>2. Creating a new "compatible" string for your platform's macb
>>   instance
>>3. Creating a new 'struct macb_config' instance for your platform,
>>   setting any relevant caps bits when it is selected.
>>
>>   Josh
> 
> I see the point, but according to the User Guide :
>> User I/O Register
>> The MACB design provides up to 16 inputs and 16 outputs,
>> for which the state of the I/O may
>> be read or set under the control of the processor interface.
>> If the user I/O is disabled as a configuration option, this address space is 
>> defined
>> as reserved, and hence will be a read-only register of value 0x0.
> 
> On the design I worked on, the macb_user_* signals were commented,
> thus disabling this register.
> 
> The implementation is not mandatory, and the "generic" macb compatible
> "cdns,macb" should disable
> usage of USRIO register by default and be only used for platform
> specific macb instances...
> 
> Is it OK if I add a new 'caps' bit and use it for the "generic" macb instance 
> ?

I would say no as some platform may already use this compatibility
string. So If you need a different capability set, please create a new
compatible string and use this one.

> For the device tree property, it should be safe to have the generic
> instances of macb and gem to
> rely on these properties instead of hardcoded instances.
> (it's the biggest aim of device tree, no ? no more hardcoded 'caps' bit ?)
> The "no-usrio" and other should eventually map 'caps' bits along the
> generic instances.

It has been decided a log time ago to use these capabilities and to have
mixed approach to the actual configuration of the IP:
- from the compatibility string
- from the configuration registers.

I may be sometimes challenging to figure out where the final property
comes from but it has proven to be pretty well adapted to any kind of
situation.

So let's continue with this and not insert additional properties to this
binding.

Best regards,
-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/9] clk: hi3519: add dt-binding document and header file

[xuejiancheng]

On 2015/12/7 17:36, Arnd Bergmann wrote:
> On Monday 07 December 2015 16:01:03 xuejiancheng wrote:
>> On 2015/12/4 18:56, Arnd Bergmann wrote:
>>> On Friday 04 December 2015 11:21:28 xuejiancheng wrote:
 Hi Arnd,

 On 2015/12/3 17:44, Arnd Bergmann wrote:
> On Thursday 03 December 2015 10:39:24 Jiancheng Xue wrote:
>> +#ifndef __DTS_HI3519_CLOCK_H
>> +#define __DTS_HI3519_CLOCK_H
>
> Please try to avoid adding headers like this if you can at all.
>
> I might ask you to merge the header file in one merge window
> otherwise and submit the platform code one kernel later, as they
> tendn to cause us needless dependencies otherwise.
>

 Sorry. In v1, Rob suggested putting binding doc and header files in
 a separate patch. The clock driver indeed depends on the header.

 I will put the header and the clock driver in a patch, and keep the
 binding doc in another patch.
>>>
>>> Having split patches is better, I was really commenting on the fact
>>> that ideally you would not have a header file at all. If we merge
>>> the header through arm-soc, then you won't be able to merge the
>>> clk driver easily, and if you merge the header through the clk
>>> maintainer, I'm can't take your dts files.
>>
>> Thank you for your comments. Because the clocks in the crg module have
>> different types and random layouts. If this header file is removed,
>> the clock driver and the dts files will get very complicated.
>>
>> Could you help me acknowledge it if I put the header file and clock driver
>> in a patch?
>>
>> Could you give me some suggestions If I want to keep this header file?
> 
> If this is another clock controller that has a random register layout,
> then adding the header file is the least problematic solution indeed.

Is it OK if I put the header file and the clock driver in a patch?

If it's not OK, could you tell me how should I separate the patches?

Thank you.

> 
> Where do those numbers come from? They are not consecutive, so it sounds
> like they are directly from the data sheet and won't be needed in the 
> driver.
> If that's true, just use the numbers directly, as you do for everything
> else.

 The numbers are defined by myself, not directly from the data sheet. Some 
 numbers
 are reserved for device nodes which will be added later. So they are not 
 consecutive now.
>>>
>>> I don't understand. How do you decide which numbers to reserve? If the
>>> numbers are completely arbitrary and you have no idea what other clocks
>>> there are, you can simply have consecutive numbers here and do the driver
>>> accordingly.
>>
>> The clocks are divided into several groups according to their types. The 
>> clocks in
>> a group are expected to have consecutive numbers. So some numbers are 
>> reserved for
>> every group in this file, just like in some existing headers. Other clocks 
>> will be
>> added when other peripherals drivers are submitted. They will use the 
>> reserve numbers
>> and be inserted into existing groups.
>>
>> Of course it is not required to reserve numbers for later added clocks.
> 
> Are you able to enumerate all the clocks then? If all clocks that are
> supported by this clock controllers have names in the data sheet, I
> would prefer to just list them all now rather than only enter the ones
> we already need, to avoid having future merge conflicts.
> 
> Then we just need to add code to support those clocks when we need them,
> but that can be done in parallel to adding the DT nodes and the driver,
> rather than strongly serializing the patch flow on the header file patches.
> 
>   Arnd
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/compaction: restore COMPACT_CLUSTER_MAX to 32

[Mel Gorman]

On Mon, Dec 07, 2015 at 05:00:41PM -0800, Andrew Morton wrote:
> On Thu,  3 Dec 2015 13:11:40 +0900 Joonsoo Kim  wrote:
> 
> > Until now, COMPACT_CLUSTER_MAX is defined as SWAP_CLUSTER_MAX.
> > Commit ("mm: increase SWAP_CLUSTER_MAX to batch TLB flushes")
> > changes SWAP_CLUSTER_MAX from 32 to 256 to improve tlb flush performance
> > so COMPACT_CLUSTER_MAX is also changed to 256.
> 
> "mm: increase SWAP_CLUSTER_MAX to batch TLB flushes" has been in limbo
> for quite a while.  Because it has been unclear whether the patch's
> benefits exceed its costs+risks.
> 
> We should make a decision here - either do the appropriate testing or
> drop the patch.
> 

At this point, drop it. The benefits that apply to some corner cases are
marginal but the concerns about potentially isolating and reclaiming too
much persist.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 0/5] MT8173 IOMMU SUPPORT

[Yong Wu]

  This patch set adds support for m4u(Multimedia Memory Management Unit),
Currently it only support the m4u with 2 levels of pagetable on mt8173.

  It's based on Robin Murphy's reposting Short-descriptor[1].
 
  Please check the hardware block diagram of Mediatek IOMMU.
 
  m4u (Multimedia Memory Management Unit)
   |
   SMI Common(Smart Multimedia Interface Common)
   |
   ++---
   ||
   ||
   SMI larb0SMI larb1   ... SoCs have several SMI local arbiter(larb).
   (display) (vdec)
   ||
   ||
 +-+-+ +++
 | | | |||
 | | |...  |||  ... There are different ports in each larb.
 | | | |||
OVL0 RDMA0 WDMA0  MC   PP   VLD

  As above, The Multimedia HW will go through SMI and M4U while it
access EMI. SMI is a brige between m4u and the Multimedia HW. It contain
smi local arbiter and smi common. It will control whether the Multimedia
HW should go though the m4u for translation or bypass it and talk
directly with EMI. And also SMI help control the power domain and clocks for
each local arbiter.
  Normally we specify a local arbiter(larb) for each multimedia HW
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.

[1] http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015088.html

v6:
-rebase onto v4.4-rc1.
-Use Robin's reposting Short-decriptor.
-Add component for m4u and smi since m4u should depend on smi-larb.
 The master device is the m4u device, and the client one is the smi-larb 
device. 
-Change mtk iommu-cells from 2 to 1 since the mapping between larb and port is
 fixed. Compare this with v2, we redefine MTK_M4U_ID following this register
 REG_MMU_INT_ID.
-About SMI: Add some help funcion and rename some function and struction for
 more readable. 
 These three above are according to Daniel Kurtz's suggestion.

v5: http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014586.html
-rebase onto v4.3-rc1.
-About MTK iommu: don't return the same domain while domain_alloc, change the
 domain's flow according to the M4U HW.
-About Short-descriptor: Improve many error-handles, NO_PERMS quirk, and 
 add TLBI_MAP quirk following Will's Suggestion; Add io-pgtable don't use 
 dma_to_phys; Add a loop in arm_short_unmap since iommu_unmap don't care the 
 physical address align.
-About SMI driver: Add a help funcion for some similar code. Add PROPRE_DEFER
 for power-domain as MTK SCPSYS is module_init currently.

v4: http://lists.linuxfoundation.org/pipermail/iommu/2015-August/013903.html
-use only one iommu domain here based on the Robin's DMA-v5:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013900.html
-remove flush_pgtable.
-change writel to writel_relaxed.
-about Short-descriptor: move dma_map_single into io-pgtable-arm-short.
 Improve the flow of free pgtable and add NO_XN+NO_PERMS quirk following
 Will's suggestion.
-Change two sytle issues in dtsi according to Daniel's suggestion.

v3: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013632.html
-rebased onto v4.2-rc1
-improve iommu flow based on the Robin's DMA v3:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013597.html
-change mtk iommu-cells from 1 to 2.
-about Short-descriptor: add split function; add self-test; add some other bits 
like nG,
 XN according to the spec; add SUPERSECTION and MTK quirk; move 
io_pgtable_ops_to_pgtable
 out from LPAE to the header file.
-about SMI: move from driver/soc/mediatek to driver/memory; change the clocks 
from
 clk[2] to clk_apb and clk_smi; add pm.
-add iommu suspend/resume to backup/restore register.

v2: http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013028.html
-add arm short descriptor support.
-seperate smi common from smi and change the clock-names according
 to smi HW.
-delete the hardcode of the port-names in mt8173.
 replace this with larb-portes-nr in dtsi.
-fix some coding style issues.

v1: http://lists.infradead.org/pipermail/linux-mediatek/2015-March/58.html
-initial version.

Yong Wu (5):
  dt-bindings: iommu: Add binding for mediatek IOMMU
  dt-bindings: mediatek: Add smi dts binding
  memory: mediatek: Add SMI driver
  iommu/mediatek: Add mt8173 IOMMU driver
  dts: mt8173: Add iommu/smi nodes for mt8173

 .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 ++
 .../memory-controllers/mediatek,smi-common.txt |  24 +
 .../memory-controllers/mediatek,smi-larb.txt   |  25 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |  81 +++
 drivers/iommu/Kconfig  |  15 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/mtk_iommu.c  | 752 +++

[PATCH v6 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU

[Yong Wu]

This patch add mediatek iommu dts binding document.

Signed-off-by: Yong Wu 
---
 .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 +
 include/dt-bindings/memory/mt8173-larb-port.h  | 111 +
 2 files changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
 create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h

diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
new file mode 100644
index 000..c2fb06e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -0,0 +1,68 @@
+* Mediatek IOMMU Architecture Implementation
+
+  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
+uses the ARM Short-Descriptor translation table format for address translation.
+
+  About the M4U Hardware Block Diagram, please check below:
+
+  EMI (External Memory Interface)
+   |
+  m4u (Multimedia Memory Management Unit)
+   |
+   SMI Common(Smart Multimedia Interface Common)
+   |
+   ++---
+   ||
+   ||
+   SMI larb0SMI larb1   ... SoCs have several SMI local arbiter(larb).
+   (display) (vdec)
+   ||
+   ||
+ +-+-+ +++
+ | | | |||
+ | | |...  |||  ... There are different ports in each larb.
+ | | | |||
+OVL0 RDMA0 WDMA0  MC   PP   VLD
+
+  As above, The Multimedia HW will go through SMI and M4U while it
+access EMI. SMI is a brige between m4u and the Multimedia HW. It contain
+smi local arbiter and smi common. It will control whether the Multimedia
+HW should go though the m4u for translation or bypass it and talk
+directly with EMI. And also SMI help control the power domain and clocks for
+each local arbiter.
+  Normally we specify a local arbiter(larb) for each multimedia HW
+like display, video decode, and camera. And there are different ports
+in each larb. Take a example, There are many ports like MC, PP, VLD in the
+video decode local arbiter, all these ports are according to the video HW.
+
+Required properties:
+- compatible : must be "mediatek,mt8173-m4u".
+- reg : m4u register base and size.
+- interrupts : the interrupt of m4u.
+- clocks : must contain one entry for each clock-names.
+- clock-names : must be "bclk", It is the block clock of m4u.
+- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
+   Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
+   according to the local arbiter index, like larb0, larb1, larb2...
+- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
+   Specifies the mtk_m4u_id as defined in
+   dt-binding/memory/mt8173-larb-port.h.
+
+Example:
+   iommu: iommu@10205000 {
+   compatible = "mediatek,mt8173-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   interrupts = ;
+   clocks = <&infracfg CLK_INFRA_M4U>;
+   clock-names = "bclk";
+   mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
+   #iommu-cells = <1>;
+   };
+
+Example for a client device:
+   display {
+   compatible = "mediatek,mt8173-disp";
+   iommus = <&iommu M4U_PORT_DISP_OVL0>,
+<&iommu M4U_PORT_DISP_RDMA0>;
+   ...
+   };
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h 
b/include/dt-bindings/memory/mt8173-larb-port.h
new file mode 100644
index 000..50ccb93
--- /dev/null
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef __DTS_IOMMU_PORT_MT8173_H
+#define __DTS_IOMMU_PORT_MT8173_H
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+/* Local arbiter ID */
+#define MTK_M4U_TO_LARB(id)(((id) >> 5) & 0x7)
+/* PortID within the local arbiter */
+#define MTK_M4U_TO_PORT(id)((id) & 0x1f)
+
+#define M4U_LARB0_ID   0
+#define M4U_LARB1_ID   1
+#define M4U_LARB2_ID   2
+#define M4U_LARB3_ID   3
+#define M4U_LARB4_ID   4
+#define M4U_LARB5_ID   5
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_L

[PATCH v6 2/5] dt-bindings: mediatek: Add smi dts binding

[Yong Wu]

This patch add smi binding document.

Signed-off-by: Yong Wu 
---
 .../memory-controllers/mediatek,smi-common.txt | 24 +
 .../memory-controllers/mediatek,smi-larb.txt   | 25 ++
 2 files changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
new file mode 100644
index 000..06a83ce
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -0,0 +1,24 @@
+SMI (Smart Multimedia Interface) Common
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-common"
+- reg : the register and size of the SMI block.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+   the register.
+  - "smi" : It's the clock for transfer data and command.
+  They may be the same if both source clocks are the same.
+
+Example:
+   smi_common: smi@14022000 {
+   compatible = "mediatek,mt8173-smi-common";
+   reg = <0 0x14022000 0 0x1000>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_COMMON>,
+<&mmsys CLK_MM_SMI_COMMON>;
+   clock-names = "apb", "smi";
+   };
diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
new file mode 100644
index 000..55ff3b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -0,0 +1,25 @@
+SMI (Smart Multimedia Interface) Local Arbiter
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-larb"
+- reg : the register and size of this local arbiter.
+- mediatek,smi : a phandle to the smi_common node.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names: must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+   the register.
+  - "smi" : It's the clock for transfer data and command.
+
+Example:
+   larb1: larb@1601 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+   clocks = <&vdecsys CLK_VDEC_CKEN>,
+<&vdecsys CLK_VDEC_LARB_CKEN>;
+   clock-names = "apb", "smi";
+   };
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 3/5] memory: mediatek: Add SMI driver

[Yong Wu]

This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the power domain
and clocks of each local arbiter.

Signed-off-by: Yong Wu 
---
  Currently SMI offer mtk_smi_larb_get/put to enable the power-domain
,clocks and initialize the iommu configuration register for each a local
arbiter, The reason is:
  a) If a device would like to disable iommu, it also need call
mtk_smi_larb_get/put to enable its power and clocks.
  b) The iommu core don't support attach/detach a device within a iommu-group.
So we cann't use iommu_attach_device(iommu_detach_device) instead
of mtk_smi_larb_get/put. 

 drivers/memory/Kconfig |   8 ++
 drivers/memory/Makefile|   1 +
 drivers/memory/mtk-smi.c   | 297 +
 include/soc/mediatek/smi.h |  53 
 4 files changed, 359 insertions(+)
 create mode 100644 drivers/memory/mtk-smi.c
 create mode 100644 include/soc/mediatek/smi.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 6f31546..51d5cd2 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -114,6 +114,14 @@ config JZ4780_NEMC
  the Ingenic JZ4780. This controller is used to handle external
  memory devices such as NAND and SRAM.
 
+config MTK_SMI
+   bool
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   help
+ This driver is for the Memory Controller module in MediaTek SoCs,
+ mainly help enable/disable iommu and control the power domain and
+ clocks for each local arbiter.
+
 source "drivers/memory/tegra/Kconfig"
 
 endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 1c46af5..890bdf4 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -15,5 +15,6 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
 obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)  += jz4780-nemc.o
+obj-$(CONFIG_MTK_SMI)  += mtk-smi.o
 
 obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
new file mode 100644
index 000..3562081
--- /dev/null
+++ b/drivers/memory/mtk-smi.c
@@ -0,0 +1,297 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SMI_LARB_MMU_EN0xf00
+#define F_SMI_MMU_EN(port) BIT(port)
+
+struct mtk_smi_common {
+   struct device   *dev;
+   struct clk  *clk_apb, *clk_smi;
+};
+
+struct mtk_smi_larb { /* larb: local arbiter */
+   struct device   *dev;
+   void __iomem*base;
+   struct clk  *clk_apb, *clk_smi;
+   struct device   *smi_common_dev;
+   u32 mmu;
+};
+
+static int
+mtk_smi_enable(struct device *dev, struct clk *apb, struct clk *smi)
+{
+   int ret;
+
+   ret = pm_runtime_get_sync(dev);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_prepare_enable(apb);
+   if (ret)
+   goto err_put_pm;
+
+   ret = clk_prepare_enable(smi);
+   if (ret)
+   goto err_disable_apb;
+
+   return 0;
+
+err_disable_apb:
+   clk_disable_unprepare(apb);
+err_put_pm:
+   pm_runtime_put_sync(dev);
+   return ret;
+}
+
+static void
+mtk_smi_disable(struct device *dev, struct clk *apb, struct clk *smi)
+{
+   clk_disable_unprepare(smi);
+   clk_disable_unprepare(apb);
+   pm_runtime_put_sync(dev);
+}
+
+static int mtk_smi_common_enable(struct mtk_smi_common *common)
+{
+   return mtk_smi_enable(common->dev, common->clk_apb, common->clk_smi);
+}
+
+static void mtk_smi_common_disable(struct mtk_smi_common *common)
+{
+   mtk_smi_disable(common->dev, common->clk_apb, common->clk_smi);
+}
+
+static int mtk_smi_larb_enable(struct mtk_smi_larb *larb)
+{
+   return mtk_smi_enable(larb->dev, larb->clk_apb, larb->clk_smi);
+}
+
+static void mtk_smi_larb_disable(struct mtk_smi_larb *larb)
+{
+   mtk_smi_disable(larb->dev, larb->clk_apb, larb->clk_smi);
+}
+
+int mtk_smi_larb_get(struct device *larbdev)
+{
+   struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
+   struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
+   int ret;
+
+   ret = mtk_smi_common_enable(common);
+   if (ret)
+   return ret;
+
+   ret = mtk_smi_larb_enable(larb);
+   if (ret)
+   goto err_put_smi;
+
+   /* Co

[PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

[Yong Wu]

This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).

Signed-off-by: Yong Wu 
---
 drivers/iommu/Kconfig |  15 +
 drivers/iommu/Makefile|   1 +
 drivers/iommu/mtk_iommu.c | 752 ++
 3 files changed, 768 insertions(+)
 create mode 100644 drivers/iommu/mtk_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index b9094e9..aab942f 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -393,4 +393,19 @@ config S390_IOMMU
help
  Support for the IOMMU API for s390 PCI devices.
 
+config MTK_IOMMU
+   bool "MTK IOMMU Support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select IOMMU_API
+   select IOMMU_DMA
+   select IOMMU_IO_PGTABLE_ARMV7S
+   select MEMORY
+   select MTK_SMI
+   help
+ Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia
+ Memory Management Unit. This option enables remapping of DMA memory
+ accesses for the multimedia subsystem.
+
+ If unsure, say N here.
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 68faca02..02887bc 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
 obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
 obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
 obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
+obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
 obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o
 obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o
 obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
new file mode 100644
index 000..6a21e70
--- /dev/null
+++ b/drivers/iommu/mtk_iommu.c
@@ -0,0 +1,752 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "io-pgtable.h"
+
+#define REG_MMU_PT_BASE_ADDR   0x000
+
+#define REG_MMU_INVALIDATE 0x020
+#define F_ALL_INVLD0x2
+#define F_MMU_INV_RANGE0x1
+
+#define REG_MMU_INVLD_START_A  0x024
+#define REG_MMU_INVLD_END_A0x028
+
+#define REG_MMU_INV_SEL0x038
+#define F_INVLD_EN0BIT(0)
+#define F_INVLD_EN1BIT(1)
+
+#define REG_MMU_STANDARD_AXI_MODE  0x048
+#define REG_MMU_DCM_DIS0x050
+
+#define REG_MMU_CTRL_REG   0x110
+#define F_MMU_PREFETCH_RT_REPLACE_MOD  BIT(4)
+#define F_MMU_TF_PROTECT_SEL(prot) (((prot) & 0x3) << 5)
+#define F_COHERENCE_EN BIT(8)
+
+#define REG_MMU_IVRP_PADDR 0x114
+#define F_MMU_IVRP_PA_SET(pa)  ((pa) >> 1)
+
+#define REG_MMU_INT_CONTROL0   0x120
+#define F_L2_MULIT_HIT_EN  BIT(0)
+#define F_TABLE_WALK_FAULT_INT_EN  BIT(1)
+#define F_PREETCH_FIFO_OVERFLOW_INT_EN BIT(2)
+#define F_MISS_FIFO_OVERFLOW_INT_ENBIT(3)
+#define F_PREFETCH_FIFO_ERR_INT_EN BIT(5)
+#define F_MISS_FIFO_ERR_INT_EN BIT(6)
+#define F_INT_CLR_BIT  BIT(12)
+
+#define REG_MMU_INT_MAIN_CONTROL   0x124
+#define F_INT_TRANSLATION_FAULTBIT(0)
+#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
+#define F_INT_INVALID_PA_FAULT BIT(2)
+#define F_INT_ENTRY_REPLACEMENT_FAULT  BIT(3)
+#define F_INT_TLB_MISS_FAULT   BIT(4)
+#define F_INT_MISS_TRANSATION_FIFO_FAULT   BIT(5)
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT   BIT(6)
+
+#define REG_MMU_CPE_DONE   0x12C
+
+#define REG_MMU_FAULT_ST1  0x134
+
+#define REG_MMU_FAULT_VA   0x13c
+#define F_MMU_FAULT_VA_MSK 0xf000
+#define F_MMU_FAULT_VA_WRITE_BIT   BIT(1)
+#define F_MMU_FAULT_VA_LAYER_BIT   BIT(0)
+
+#define REG_MMU_INVLD_PA   0x140
+#define REG_MMU_INT_ID 0x150
+#define F_MMU0_INT_ID_LARB_ID(a)   (((a) >> 7) & 0x7)
+#define F_MMU0_INT_ID_PORT_ID(a)   (((a) >> 2

[PATCH v6 5/5] dts: mt8173: Add iommu/smi nodes for mt8173

[Yong Wu]

This patch add the iommu/larbs nodes for mt8173

Signed-off-by: Yong Wu 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81 
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4dd5f93..8b50951 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "mt8173-pinfunc.h"
@@ -267,6 +268,17 @@
reg = <0 0x10200620 0 0x20>;
};
 
+   iommu: iommu@10205000 {
+   compatible = "mediatek,mt8173-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   interrupts = ;
+   clocks = <&infracfg CLK_INFRA_M4U>;
+   clock-names = "bclk";
+   mediatek,larbs = <&larb0 &larb1 &larb2
+ &larb3 &larb4 &larb5>;
+   #iommu-cells = <1>;
+   };
+
apmixedsys: clock-controller@10209000 {
compatible = "mediatek,mt8173-apmixedsys";
reg = <0 0x10209000 0 0x1000>;
@@ -516,29 +528,98 @@
#clock-cells = <1>;
};
 
+   larb0: larb@14021000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x14021000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_LARB0>,
+<&mmsys CLK_MM_SMI_LARB0>;
+   clock-names = "apb", "smi";
+   };
+
+   smi_common: smi@14022000 {
+   compatible = "mediatek,mt8173-smi-common";
+   reg = <0 0x14022000 0 0x1000>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_COMMON>,
+<&mmsys CLK_MM_SMI_COMMON>;
+   clock-names = "apb", "smi";
+   };
+
+   larb4: larb@14027000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x14027000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+   clocks = <&mmsys CLK_MM_SMI_LARB4>,
+<&mmsys CLK_MM_SMI_LARB4>;
+   clock-names = "apb", "smi";
+   };
+
imgsys: clock-controller@1500 {
compatible = "mediatek,mt8173-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb2: larb@15001000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x15001000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_ISP>;
+   clocks = <&imgsys CLK_IMG_LARB2_SMI>,
+<&imgsys CLK_IMG_LARB2_SMI>;
+   clock-names = "apb", "smi";
+   };
+
vdecsys: clock-controller@1600 {
compatible = "mediatek,mt8173-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb1: larb@1601 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+   clocks = <&vdecsys CLK_VDEC_CKEN>,
+<&vdecsys CLK_VDEC_LARB_CKEN>;
+   clock-names = "apb", "smi";
+   };
+
vencsys: clock-controller@1800 {
compatible = "mediatek,mt8173-vencsys", "syscon";
reg = <0 0x1800 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb3: larb@18001000 {
+   compatible = "mediatek,mt8173-smi-larb";
+   reg = <0 0x18001000 0 0x1000>;
+   mediatek,smi = <&smi_common>;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC>;
+   clocks = <&vencsys CLK_VENC_CKE1>,
+<&vencsys CLK_VENC_CKE0>;
+   clock-names = "apb", "smi";
+   };
+
vencltsys: clock-con

[RFC PATCH 0/3] debugfs: implement 'debugfs_create_dir_with_tmpfiles()'

[Roman Pen]

Hello.

Here is an attempt to solve annoying race, which exists between two operations
on debugfs entries: write (setting a request) and read (reading a response).

E.g. let's assume that we have some storage device, which can have thousands
of snapshots (yeah, plenty of them, thus it is ridicoulous to create a debugfs
entry for each), and each snapshot is controlled by the handle, which is a UUID
or any non-numeric character sequence (for numeric sequence this problem can be
solved by 'seek' operation).  This device provides a debugfs entry 
'snap_status',
which can be opened for reading and writing, where write - is an operation for
specifiying a request, and read - is an operation for getting a response back.

I.e. it is obvious, that to request a status of a snapshot you have to write a
UUID first of a snapshot and then read back a status response back, so the
sequence can be the following:

  # echo $UUID > /sys/kernel/debug/storage/snap_status
  # cat /sys/kernel/debug/storage/snap_status

Between those two operations a race exists, and if someone else comes and
requests status for another snapshot, the first requester will get incorrect
data.

An atomic request-set and response-read solution can be the following:

  # cat /sys/kernel/debug/storage/snap_status/$UUID

Here debugfs creates non-existent temporary entry on demand with the $UUID
name and eventually calls file operations, which were passed to the
'debugfs_create_dir_with_tmpfiles()' function.  Caller of that function can
control the correctness of the file name in 'i_fop->open' callback and can
return an error if temporary file name does not match some format.

Temporary file, which is created, will not appear in any lookups, further
linking is forbidden, corresponding dentry and inode will be freed when last
file descriptor is closed (see O_TMPFILE, with the only difference is that
debugfs temporary dentry has a name).

Of course this file creation on demand can be applied to many other cases,
where it is impossible to create as many debugfs entries as objects exist,
but atomicity of read-write can be required.

This atomicity can be achieved also by locking from userspace, but that approach
increases complexity and makes it hardly possible to invoke only few commands
from command line, like 'echo' or 'cat'.

So basically creating a temporary file on demand with a specified name is a
way to provide one additional parameter for an 'read' operation.

Probably, there is more elegant solution for that write-read race problem,
but I've not found any.

PS. I did not want to use configfs, because I have nothing to configure (what
I have described is not a configuration issue), and I do not like to keep
dentries in a system if userspace forgets to remove them.

Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org

Roman Pen (3):
  debugfs: make create directory logic more generic
  debugfs: implement 'debugfs_create_dir_with_tmpfiles()'
  debugfs: update some bits of documentation

 Documentation/filesystems/debugfs.txt |  25 ++
 fs/debugfs/inode.c| 157 ++
 include/linux/debugfs.h   |  12 +++
 3 files changed, 179 insertions(+), 15 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 1/3] debugfs: make create directory logic more generic

[Roman Pen]

Now __create_dir() accepts inode operations and private data.
I will use this generic call in next path to create directory
with temporary files.

Signed-off-by: Roman Pen 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org
---
 fs/debugfs/inode.c | 48 
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index b7fcc0d..f1c4f80 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -388,25 +388,9 @@ struct dentry *debugfs_create_file_size(const char *name, 
umode_t mode,
 }
 EXPORT_SYMBOL_GPL(debugfs_create_file_size);
 
-/**
- * debugfs_create_dir - create a directory in the debugfs filesystem
- * @name: a pointer to a string containing the name of the directory to
- *create.
- * @parent: a pointer to the parent dentry for this file.  This should be a
- *  directory dentry if set.  If this parameter is NULL, then the
- *  directory will be created in the root of the debugfs filesystem.
- *
- * This function creates a directory in debugfs with the given name.
- *
- * This function will return a pointer to a dentry if it succeeds.  This
- * pointer must be passed to the debugfs_remove() function when the file is
- * to be removed (no automatic cleanup happens if your module is unloaded,
- * you are responsible here.)  If an error occurs, %NULL will be returned.
- *
- * If debugfs is not enabled in the kernel, the value -%ENODEV will be
- * returned.
- */
-struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
+static struct dentry *__create_dir(const char *name,
+  struct dentry *parent, void *data,
+  const struct inode_operations *i_op)
 {
struct dentry *dentry = start_creating(name, parent);
struct inode *inode;
@@ -419,7 +403,8 @@ struct dentry *debugfs_create_dir(const char *name, struct 
dentry *parent)
return failed_creating(dentry);
 
inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
-   inode->i_op = &simple_dir_inode_operations;
+   inode->i_op = i_op;
+   inode->i_private = data;
inode->i_fop = &simple_dir_operations;
 
/* directory inodes start off with i_nlink == 2 (for "." entry) */
@@ -429,6 +414,29 @@ struct dentry *debugfs_create_dir(const char *name, struct 
dentry *parent)
fsnotify_mkdir(d_inode(dentry->d_parent), dentry);
return end_creating(dentry);
 }
+
+/**
+ * debugfs_create_dir - create a directory in the debugfs filesystem
+ * @name: a pointer to a string containing the name of the directory to
+ *create.
+ * @parent: a pointer to the parent dentry for this file.  This should be a
+ *  directory dentry if set.  If this parameter is NULL, then the
+ *  directory will be created in the root of the debugfs filesystem.
+ *
+ * This function creates a directory in debugfs with the given name.
+ *
+ * This function will return a pointer to a dentry if it succeeds.  This
+ * pointer must be passed to the debugfs_remove() function when the file is
+ * to be removed (no automatic cleanup happens if your module is unloaded,
+ * you are responsible here.)  If an error occurs, %NULL will be returned.
+ *
+ * If debugfs is not enabled in the kernel, the value -%ENODEV will be
+ * returned.
+ */
+struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
+{
+   return __create_dir(name, parent, NULL, &simple_dir_inode_operations);
+}
 EXPORT_SYMBOL_GPL(debugfs_create_dir);
 
 /**
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 2/3] debugfs: implement 'debugfs_create_dir_with_tmpfiles()'

[Roman Pen]

This new function creates a directory in debugfs with the given name with
possibility to create temporary files on demand.  Any attempt to open
a non-existent file in that directory will create a temporary file,
wich will be deleted when the last file descriptor is closed.  This
temporary file is very similar to opening a directory with O_TMPFILE,
with the difference that a resulting dentry has a name, but still is
unhashed, so is invisible to outer world and can never be reached via
any pathname.

Why it is needed?  That will solve the race between writing (setting some
request information) and then reading back a response from some debugfs
entry.

E.g. let's assume that we have some storage device, which can have thousands
of snapshots, and each snapshot is controlled by the handle, which is a UUID
or any non-numeric character sequence.  This device provides a debugfs entry
to get a status of a requested snapshot: 'snap_status'.  It is obvious, that
to request a status of a snapshot you have to write a UUID first of a snapshot
and then read back the response with the status data, so the sequence is the
following:

  # echo $UUID > /sys/kernel/debug/storage/snap_status
  # cat /sys/kernel/debug/storage/snap_status

Between those two operations a race exists, and if someone else comes and
requests status for another snapshot, the first requester will get incorrect
data.

The atomic request-set and response-read solution can be the following:

  # cat /sys/kernel/debug/storage/snap_status/$UUID

Here debugfs creates non-existent temporary entry with the $UUID name on
demand and eventually calls file operations, which were passed to the
'debugfs_create_dir_with_tmpfiles()' function.  User of that function can
control the correctness of the file name in 'i_fop->open' callback and can
return an error if temporary file name does not match some criteria.

Created temporary file will not appear in any lookups, further linking is
forbidden, corresponding dentry and inode will be freed when last file
descriptor is closed.

Signed-off-by: Roman Pen 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org
---
 fs/debugfs/inode.c  | 119 
 include/linux/debugfs.h |  12 +
 2 files changed, 131 insertions(+)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index f1c4f80..4a67d14 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -170,6 +170,9 @@ static void debugfs_evict_inode(struct inode *inode)
clear_inode(inode);
if (S_ISLNK(inode->i_mode))
kfree(inode->i_link);
+   else if (S_ISDIR(inode->i_mode))
+   /* Only for directories with tmpfiles i_private is set */
+   kfree(inode->i_private);
 }
 
 static const struct super_operations debugfs_super_operations = {
@@ -242,8 +245,19 @@ static struct file_system_type debug_fs_type = {
 };
 MODULE_ALIAS_FS("debugfs");
 
+static inline const struct inode_operations *swap_inode_ops(
+   const struct inode_operations **dst,
+   const struct inode_operations  *new)
+{
+   const struct inode_operations *ret = *dst;
+
+   *dst = new;
+   return ret;
+}
+
 static struct dentry *start_creating(const char *name, struct dentry *parent)
 {
+   const struct inode_operations *i_op;
struct dentry *dentry;
int error;
 
@@ -266,7 +280,13 @@ static struct dentry *start_creating(const char *name, 
struct dentry *parent)
parent = debugfs_mount->mnt_root;
 
mutex_lock(&d_inode(parent)->i_mutex);
+   /* We want to avoid creating temporary inodes while lookup,
+* thus use simple inode ops
+*/
+   i_op = swap_inode_ops(&d_inode(parent)->i_op,
+ &simple_dir_inode_operations);
dentry = lookup_one_len(name, parent, strlen(name));
+   swap_inode_ops(&d_inode(parent)->i_op, i_op);
if (!IS_ERR(dentry) && d_really_is_positive(dentry)) {
dput(dentry);
dentry = ERR_PTR(-EEXIST);
@@ -439,6 +459,98 @@ struct dentry *debugfs_create_dir(const char *name, struct 
dentry *parent)
 }
 EXPORT_SYMBOL_GPL(debugfs_create_dir);
 
+struct tmp_priv {
+   const struct file_operations *fops;
+   void   *data;
+   umode_t mode;
+};
+
+/**
+ * debugfs_tmp_lookup() - lookup for directory with temporary files
+ *
+ * This lookup always creates inode for any name and ties it with dentry,
+ * but dentry cannot be reached via any pathname, so when last referenced
+ * on the file is closed - everything will be deleted (see O_TMPFILE).
+ */
+struct dentry *debugfs_tmp_lookup(struct inode *dir, struct dentry *dentry,
+ unsigned int flags)
+{
+   struct inode *inode;
+   struct tmp_priv *p;
+
+   inode = debugfs_get_inode(dir->i_sb);
+   if (unlikely(!inode))
+   return ERR_PTR(-ENOMEM);
+
+   p = dir->i_private;
+   BUG_ON(p == NULL);
+
+   inode->i_mode = 

[RFC PATCH 3/3] debugfs: update some bits of documentation

[Roman Pen]

Include description of 'debugfs_create_dir_with_tmpfiles()' call.

Signed-off-by: Roman Pen 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel@vger.kernel.org
---
 Documentation/filesystems/debugfs.txt | 25 +
 1 file changed, 25 insertions(+)

diff --git a/Documentation/filesystems/debugfs.txt 
b/Documentation/filesystems/debugfs.txt
index 4f45f71..150fabf 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -36,6 +36,31 @@ wrong.  If ERR_PTR(-ENODEV) is returned, that is an 
indication that the
 kernel has been built without debugfs support and none of the functions
 described below will work.
 
+Another way to create a directory where temporary files will be created
+on demand is:
+
+struct dentry *debugfs_create_dir_with_tmpfiles(const char *name,
+   umode_t mode, struct dentry *parent, void *data,
+   const struct file_operations *fops);
+
+This function creates a directory in debugfs with the given name with
+possibility to create temporary files on demand.  Any attempt to open
+a non-existent file in that directory will create a temporary file,
+wich will be deleted when the last file descriptor is closed.  This
+temporary file is very similar to opening a directory with O_TMPFILE,
+with the difference that a resulting dentry has a name, but still is
+unhashed, so is invisible to outer world and can never be reached via
+any pathname.
+
+How those temporary files on demand can be used?  This is a way to provide
+one additional parameter in a file name and specify an object name.  E.g.:
+
+# cat /sys/kernel/debug/my_objects/$UUID
+
+Where $UUID is a UUID of an object which should be requested.  This $UUID
+file will never appear in lookup and will be deleted when 'cat' closes last
+file descriptor.
+
 The most general way to create a file within a debugfs directory is with:
 
 struct dentry *debugfs_create_file(const char *name, umode_t mode,
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/12] selftests/x86: Add check_initial_reg_state

[Borislav Petkov]

On Mon, Dec 07, 2015 at 01:51:27PM -0800, Andy Lutomirski wrote:
> This checks that ELF binaries are started with an appropriately
> blank register state.
> 
> (There's currently a nasty special case in the entry asm to arrange
>  for this.  I'm planning on removing the special case, and this will
>  help make sure I don't break it.)
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  tools/testing/selftests/x86/Makefile   |   8 +-
>  .../selftests/x86/check_initial_reg_state.c| 108 
> +
>  2 files changed, 115 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/x86/check_initial_reg_state.c
> 
> diff --git a/tools/testing/selftests/x86/Makefile 
> b/tools/testing/selftests/x86/Makefile
> index a460fe7c5365..b82409421fa6 100644
> --- a/tools/testing/selftests/x86/Makefile
> +++ b/tools/testing/selftests/x86/Makefile
> @@ -4,7 +4,7 @@ include ../lib.mk
>  
>  .PHONY: all all_32 all_64 warn_32bit_failure clean
>  
> -TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs ldt_gdt syscall_nt 
> ptrace_syscall
> +TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs ldt_gdt syscall_nt 
> ptrace_syscall check_initial_reg_state
>  TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault sigreturn 
> test_syscall_vdso unwind_vdso
>  
>  TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
> @@ -63,3 +63,9 @@ endif
>  sysret_ss_attrs_64: thunks.S
>  ptrace_syscall_32: raw_syscall_helper_32.S
>  test_syscall_vdso_32: thunks_32.S
> +
> +# check_initial_reg_state is special: it needs a custom entry, and it
> +# needs to be static so that its interpreter doesn't destroy its initial
> +# state.
> +check_initial_reg_state_32: CFLAGS += -Wl,-ereal_start -static
> +check_initial_reg_state_64: CFLAGS += -Wl,-ereal_start -static
> diff --git a/tools/testing/selftests/x86/check_initial_reg_state.c 
> b/tools/testing/selftests/x86/check_initial_reg_state.c
> new file mode 100644
> index ..0cb565f7786d
> --- /dev/null
> +++ b/tools/testing/selftests/x86/check_initial_reg_state.c
> @@ -0,0 +1,108 @@
> +/*
> + * check_initial_reg_state.c - check that execve sets the correct state
> + * Copyright (c) 2014-2015 Andrew Lutomirski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + */
> +
> +#define _GNU_SOURCE
> +
> +#include 
> +
> +unsigned long ax, bx, cx, dx, si, di, bp, sp, flags;
> +unsigned long r8, r9, r10, r11, r12, r13, r14, r15;
> +
> +asm (".pushsection .text\n\t"

WARNING: please, no spaces at the start of a line
#82: FILE: tools/testing/selftests/x86/check_initial_reg_state.c:23:
+ ".type real_start, @function\n\t"$

Something trampled over the preceding tabs in that whole asm().

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] clk: tegra-super: Fix sparse warnings for functions not declared as static

[Jon Hunter]

On 07/12/15 17:51, Rhyland Klein wrote:
> On 12/7/2015 10:51 AM, Rhyland Klein wrote:
>> On 12/4/2015 12:04 PM, Jon Hunter wrote:
>>> Sparse reports the following warnings for structures and functions that
>>> should be declared static:
>>>
>>> drivers/clk/tegra/clk-tegra-super-gen4.c:70:35: warning: symbol
>>>  'tegra_super_gen_info_gen4' was not declared. Should it be static?
>>> drivers/clk/tegra/clk-tegra-super-gen4.c:96:35: warning: symbol
>>>  'tegra_super_gen_info_gen5' was not declared. Should it be static?
>>> drivers/clk/tegra/clk-tegra-super-gen4.c:174:13: warning: symbol
>>>  'tegra_super_clk_init' was not declared. Should it be static?
>>>
>>> Fix this by making the above static.
>>>
>>> Fixes: 88467d220119 ("clk: tegra: Add Super Gen5 Logic")
>>>
>>> Signed-off-by: Jon Hunter 
>>> ---
>>>  drivers/clk/tegra/clk-tegra-super-gen4.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>> ...
>>
>> Acked-by: Rhyland Klein 
>>
> 
> Actually, Don't you need to change the function declarations in
> drivers/clk/tegra/clk.h for tegra_super_clk_gen[4|5]_init otherwise you
> will get mismatches with one being declared static and the other not?

So this patch does not touch the functions
tegra_super_clk_gen[4|5]_init() and these should definitely not be
static. This patch just makes the structures
tegra_super_gen_info_gen[4|5] and the function tegra_super_clk_init()
static. None of these are referenced outside clk-tegra-super-gen4.c.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH resend 2/6] clk: sunxi: Add VE (Video Engine) module clock driver for sun[457]i

[Maxime Ripard]

Hi,

On Sat, Dec 05, 2015 at 09:16:43PM +0800, Chen-Yu Tsai wrote:
> The video engine has its own special module clock, consisting of a clock
> gate, configurable dividers, and a reset control.
> 
> On later (sun[68]i) families, the reset control is moved out of this
> piece of hardware and grouped with reset controls of other peripherals.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |   4 +
>  drivers/clk/sunxi/Makefile|   1 +
>  drivers/clk/sunxi/clk-a10-ve.c| 171 
> ++
>  3 files changed, 176 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk-a10-ve.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index ef0b452806b1..14496056319f 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -74,6 +74,7 @@ Required properties:
>   "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
>   "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>   "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
> + "allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>  
>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
> @@ -93,6 +94,9 @@ Required properties for all clocks:
>  And "allwinner,*-usb-clk" clocks also require:
>  - reset-cells : shall be set to 1
>  
> +The "allwinner,sun4i-a10-ve-clk" clock also requires:
> +- reset-cells : shall be set to 0
> +
>  The "allwinner,sun9i-a80-mmc-config-clk" clock also requires:
>  - #reset-cells : shall be set to 1
>  - resets : shall be the reset control phandle for the mmc block.
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 103efab05ca8..78db91ad5af6 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -7,6 +7,7 @@ obj-y += clk-a10-codec.o
>  obj-y += clk-a10-hosc.o
>  obj-y += clk-a10-mod1.o
>  obj-y += clk-a10-pll2.o
> +obj-y += clk-a10-ve.o
>  obj-y += clk-a20-gmac.o
>  obj-y += clk-mod0.o
>  obj-y += clk-simple-gates.o
> diff --git a/drivers/clk/sunxi/clk-a10-ve.c b/drivers/clk/sunxi/clk-a10-ve.c
> new file mode 100644
> index ..de0fdb656150
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-a10-ve.c
> @@ -0,0 +1,171 @@
> +/*
> + * Copyright 2015 Chen-Yu Tsai
> + *
> + * Chen-Yu Tsai 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static DEFINE_SPINLOCK(ve_lock);
> +
> +#define SUN4I_VE_ENABLE  31
> +#define SUN4I_VE_DIVIDER_SHIFT   16
> +#define SUN4I_VE_DIVIDER_WIDTH   3
> +#define SUN4I_VE_RESET   0
> +
> +/**
> + * sunxi_ve_reset... - reset bit in ve clk registers handling
> + */
> +
> +struct ve_reset_data {
> + void __iomem*reg;
> + spinlock_t  *lock;
> + struct reset_controller_dev rcdev;
> +};
> +
> +static int sunxi_ve_reset_assert(struct reset_controller_dev *rcdev,
> +  unsigned long id)
> +{
> + struct ve_reset_data *data = container_of(rcdev,
> +   struct ve_reset_data,
> +   rcdev);
> + unsigned long flags;
> + u32 reg;
> +
> + spin_lock_irqsave(data->lock, flags);
> +
> + reg = readl(data->reg);
> + writel(reg & ~BIT(SUN4I_VE_RESET), data->reg);
> +
> + spin_unlock_irqrestore(data->lock, flags);
> +
> + return 0;
> +}
> +
> +static int sunxi_ve_reset_deassert(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + struct ve_reset_data *data = container_of(rcdev,
> +   struct ve_reset_data,
> +   rcdev);
> + unsigned long flags;
> + u32 reg;
> +
> + spin_lock_irqsave(data->lock, flags);
> +
> + reg = readl(data->reg);
> + writel(reg | BIT(SUN4I_VE_RESET), data->reg);
> +
> + spin_unlock_irqrestore(data->lock, flags);
> +
> + return 0;
> +}

Is it me, or do we have this code duplicated everywhere now?

Maybe we should turn this into a small library.

> +static int sunxi_ve_of_xlate(struct reset_controller_dev *rcdev,
> +  const struct 

Re: [PATCH v7 2/6] mfd: syscon: add a DT property to set value width

[Arnd Bergmann]

On Monday 07 December 2015 14:42:18 Damien Riegel wrote:

> Good to see this patch applied. What's going on now with the other
> patches of this serie ? How should I handle them ?

I don't see any build-time dependencies between the patches, so
please submit them to the respective maintainers.

Patch 3 and 5 should go through the watchdog tree, and Shawn can take
the other ones and submit them through arm-soc.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/7] ARM: orion5x/mv78xx0 multiplatform

[Arnd Bergmann]

On Monday 07 December 2015 18:22:39 Gregory CLEMENT wrote:
>  On mer., déc. 02 2015, Arnd Bergmann  wrote:
> 
> > I've updated the series slightly to leave out the last two patches for
> > mach-dove. I think the MULTI_IRQ_HANDLER and SPARSE_IRQ use is useful
> > to have for all three platforms for consistency, and the watchdog change
> > is required to get orion5x to work right.
> >
> > Please have another look.
> >
> > I've also uploaded this series to
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git 
> > multiplatform-orion-4.3
> >
> > again, that version is based on v4.3, while the patches in these mails
> > are based on v4.4-rc3.
> >
> > I've left Andrew's Ack in place, hope that's ok.
> >
> 
> I applied the series on mvebu/soc and I will try to see if I can test it
> on an mv78xx0 board.
> 
> I applied the series on v4.4-rc1, so I had to merge "manually" the
> second patch. If everything goes well, should I use the v4.4-rc3 as
> reference for the pull request?

-rc1, -rc2 and -rc3 are all fine, but I'd like to avoid pulling
in later -rc releases.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH resend 6/6] ARM: dts: sun7i: Add VE (Video Engine) module clock node

[Maxime Ripard]

On Sat, Dec 05, 2015 at 09:16:47PM +0800, Chen-Yu Tsai wrote:
> The video engine has its own module clock, which also includes a
> reset control for it.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH resend 4/6] ARM: dts: sun4i: Add VE (Video Engine) module clock node

[Maxime Ripard]

On Sat, Dec 05, 2015 at 09:16:45PM +0800, Chen-Yu Tsai wrote:
> The video engine has its own module clock, which also includes a
> reset control for it.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] blkdev: Fix blkdev_open to release the bdev on error

[Suzuki K. Poulose]

On 08/12/15 07:25, Al Viro wrote:

On Mon, Dec 07, 2015 at 06:05:03PM +, Suzuki K. Poulose wrote:

blkdev_open() doesn't release the bdev, it attached to a given
inode, if blkdev_get() fails (e.g, due to absence of a device).
This can cause kernel crashes when the original filesystem
tries to flush the data during evict_inode.

This can be triggered easily with virtio-9p fs using the following
simple steps.


???



How can filesystem type affect the behaviour of block devices?



...



We should not do bd_forget() upon failing open() - what for?  As long as
->i_rdev remains the same, the pointer to struct bdev is valid.  It
doesn't pin bdev down; having it (or any other alias) opened does.  When
we decide to evict bdev, *all* aliasing inodes are dissociated from it;
none of them is open at that point, so we are OK.  When an aliasing inode
gets evicted, we have it dissociated from its ->i_bdev (if any).  Since we
only access the ->i_mapping of aliasing inode while its open, those places
are fine and anything that wants ->i_data of alias will simply find it empty.


Thanks for the detailed explanation. Surely my patch was not cooked up
on the full understanding of the bdev fs. Things are much more clear now.


Could you confirm that the patch below fixes your problem?



Yes, it does solve the issue.

Thanks
Suzuki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

[Arnd Bergmann]

On Monday 07 December 2015 10:26:34 Daniel Cashman wrote:
> > Ideally we'd remove the #ifdef around the mmap_rnd_compat_bits declaration
> > and change this code to use
> > 
> >   if (IS_ENABLED(CONFIG_COMPAT) && test_thread_flag(TIF_32BIT))
> > 
> That would result in "undefined reference to mmap_rnd_compat_bits" in
> the not-defined case, no?

No. The compiler eliminates all code paths that it knows are unused.
The IS_ENABLED() macro is designed to let the compiler figure this out.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] blkdev: Fix blkdev_open to release the bdev on error

[Suzuki K. Poulose]

On 08/12/15 07:58, Al Viro wrote:

On Mon, Dec 07, 2015 at 10:49:05AM -0800, Linus Torvalds wrote:

On Mon, Dec 7, 2015 at 10:05 AM, Suzuki K. Poulose
 wrote:


...


Anyway, the fix for 9p bogosity follows; it definitely fixes a bug there,
and I'm fairly sure that it fixes the bug that had been reported.
A confirmation would be nice, of course...

Signed-off-by: Al Viro 
---
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 699941e..5110785 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -451,9 +451,9 @@ void v9fs_evict_inode(struct inode *inode)
  {
struct v9fs_inode *v9inode = V9FS_I(inode);

-   truncate_inode_pages_final(inode->i_mapping);
+   truncate_inode_pages_final(&inode->i_data);
clear_inode(inode);
-   filemap_fdatawrite(inode->i_mapping);
+   filemap_fdatawrite(&inode->i_data);

v9fs_cache_inode_put_cookie(inode);
/* clunk the fid stashed in writeback_fid */



This patch fixes the problem :

Tested-by: Suzuki K. Poulose 

Thanks
Suzuki


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CGroup Namespaces (v6)

[Alban Crequy]

Hi,

Thanks for the patches!

On 8 December 2015 at 00:06,   wrote:
> Hi,
>
> following is a revised set of the CGroup Namespace patchset which Aditya
> Kali has previously sent.  The code can also be found in the cgroupns.v6
> branch of
>
> https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/
>
> To summarize the semantics:
>
> 1. CLONE_NEWCGROUP re-uses 0x0200, which was previously CLONE_STOPPED
>
> 2. unsharing a cgroup namespace makes all your current cgroups your new
> cgroup root.
>
> 3. /proc/pid/cgroup always shows cgroup paths relative to the reader's
> cgroup namespce root.  A task outside of  your cgroup looks like
>
> 8:memory:/../../..
>
> 4. when a task mounts a cgroupfs, the cgroup which shows up as root depends
> on the mounting task's  cgroup namespace.
>
> 5. setns to a cgroup namespace switches your cgroup namespace but not
> your cgroups.
>
> With this, using github.com/hallyn/lxc #2015-11-09/cgns (and
> github.com/hallyn/lxcfs #2015-11-10/cgns) we can start a container in a full
> proper cgroup namespace, avoiding either cgmanager or lxcfs cgroup bind 
> mounts.

I tested cgroupns.v6 with systemd-nspawn + patches from
https://github.com/systemd/systemd/pull/2112 using
unshare(CLONE_NEWCGROUP) booted with
systemd.unified_cgroup_hierarchy=1 in Fedora22. Tested with and
without userns. It worked for me :)

Do you need people to run more tests, with other scenarios?

Do you have patches already for /usr/bin/unshare and /usr/bin/nsenter?

> This is completely backward compatible and will be completely invisible
> to any existing cgroup users (except for those running inside a cgroup
> namespace and looking at /proc/pid/cgroup of tasks outside their
> namespace.)
>
> Changes from V5:
> 1. To get a root dentry for cgroup namespace mount, walk the path from the
>kernfs root dentry.
>
> Changes from V4:
> 1. Move the FS_USERNS_MOUNT flag to last patch
> 2. Rebase onto cgroup/for-4.5
> 3. Don't non-init user namespaces to bind new subsystems when mounting.
> 4. Address feedback from Tejun (thanks).  Specificaly, not addressed:
>. kernfs_obtain_root - walking dentry from kernfs root.
>  (I think that's the only piece)
> 5. Dropped unused get_task_cgroup fn/patch.
> 6. Reworked kernfs_path_from_node_locked() to try to simplify the logic.
>It now finds a common ancestor, walks from the source to it, then back
>up to the target.
>
> Changes from V3:
> 1. Rebased onto latest cgroup changes.  In particular switch to
>css_set_lock and ns_common.
> 2. Support all hierarchies.
>
> Changes from V2:
> 1. Added documentation in Documentation/cgroups/namespace.txt
> 2. Fixed a bug that caused crash
> 3. Incorporated some other suggestions from last patchset:
>- removed use of threadgroup_lock() while creating new cgroupns
>- use task_lock() instead of rcu_read_lock() while accessing
>  task->nsproxy
>- optimized setns() to own cgroupns
>- simplified code around sane-behavior mount option parsing
> 4. Restored ACKs from Serge Hallyn from v1 on few patches that have
>not changed since then.
>
> Changes from V1:
> 1. No pinning of processes within cgroupns. Tasks can be freely moved
>across cgroups even outside of their cgroupns-root. Usual DAC/MAC policies
>apply as before.
> 2. Path in /proc//cgroup is now always shown and is relative to
>cgroupns-root. So path can contain '/..' strings depending on cgroupns-root
>of the reader and cgroup of .
> 3. setns() does not require the process to first move under target
>cgroupns-root.
>
> Changes form RFC (V0):
> 1. setns support for cgroupns
> 2. 'mount -t cgroup cgroup ' from inside a cgroupns now
>mounts the cgroup hierarcy with cgroupns-root as the filesystem root.
> 3. writes to cgroup files outside of cgroupns-root are not allowed
> 4. visibility of /proc//cgroup is further restricted by not showing
>anything if the  is in a sibling cgroupns and its cgroup falls outside
>your cgroupns-root.
>
>
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 19/23] mtd: nand: switch all drivers to mtd_ooblayout_ops

[Ralf Baechle]

On Mon, Dec 07, 2015 at 11:26:14PM +0100, Boris Brezillon wrote:

Looking good,

Acked-by: Ralf Baechle 

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MIPS: VDSO: Fix build error

[Qais Yousef]

Commit ebb5e78cc634 (MIPS: Initial implementation of a VDSO) introduced a build
error.

For MIPS VDSO to be compiled it requires binutils version 2.25 or above but the
check in the Makefile had inverted logic causing it to be compiled in if 
binutils
is below 2.25.

This fixes the following compilation error:

CC  arch/mips/vdso/gettimeofday.o
/tmp/ccsExcUd.s: Assembler messages:
/tmp/ccsExcUd.s:62: Error: can't resolve `_start' {*UND* section} - `L0' {.text 
section}
/tmp/ccsExcUd.s:467: Error: can't resolve `_start' {*UND* section} - `L0' 
{.text section}
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
make[1]: *** [arch/mips/vdso] Error 2
make: *** [arch/mips] Error 2

Signed-off-by: Qais Yousef 
---
 arch/mips/vdso/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index ef5f348f386a..018f8c7b94f2 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -26,8 +26,8 @@ aflags-vdso := $(ccflags-vdso) \
 # the comments on that file.
 #
 ifndef CONFIG_CPU_MIPSR6
-  ifeq ($(call ld-ifversion, -gt, 2240, y),)
-$(warning MIPS VDSO requires binutils > 2.24)
+  ifeq ($(call ld-ifversion, -lt, 2250, y),)
+$(warning MIPS VDSO requires binutils >= 2.25)
 obj-vdso-y := $(filter-out gettimeofday.o, $(obj-vdso-y))
 ccflags-vdso += -DDISABLE_MIPS_VDSO
   endif
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] dm verity: add support for error correction

[Sami Tolvanen]

On Mon, Dec 07, 2015 at 02:07:43PM -0500, Mike Snitzer wrote:
> I'm not seeing any verification of the metadata in fec_read_parity() --
> so it would seem that corrupt RS blocks would result in -EBADMSG being
> returned from decode_rs8() (by virtue of incorrect parity being passed
> to decode_rs8).
> 
> Sami (or others) am I right?

Yes, decode_rs8 failing with -EBADMSG is one option. There are also two
other cases:

 1) If the parity data is only partially corrupted, it may still be
possible to correct errors, provided that the actual data isn't
too severely corrupted.

 2) If there's too much corruption for Reed-Solomon to detect, it's
also possible that decode_rs8 just returns bogus data, which we
will catch when verifying the hash again. This is why combining
error correction with integrity checking is essential.

In other words, the worst case is that we cannot correct errors for the
blocks covered by the corrupted parity data.

Sami
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/8] ARM: dts: Exynos542x/5800: add cluster regulator supply properties

[Markus Reichl]

Hi,

tested the patch successfully on Odroid-XU4.

Thanks
--
Markus

Am 07.12.2015 um 19:18 schrieb Bartlomiej Zolnierkiewicz:
> Add cluster regulator supply properties as a preparation to
> adding generic cpufreq-dt driver support for Exynos542x and
> Exynos5800 based boards.
> 
> Cc: Kukjin Kim 
> Cc: Doug Anderson 
> Cc: Javier Martinez Canillas 
> Cc: Andreas Faerber 
> Cc: Sachin Kamat 
> Cc: Thomas Abraham 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts   | 8 
>  arch/arm/boot/dts/exynos5420-peach-pit.dts  | 8 
>  arch/arm/boot/dts/exynos5420-smdk5420.dts   | 8 
>  arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 8 
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts  | 8 
>  arch/arm/boot/dts/exynos5422-odroidxu4.dts  | 8 
>  arch/arm/boot/dts/exynos5800-peach-pi.dts   | 8 
>  7 files changed, 56 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 4ecef69..4229641 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -52,6 +52,14 @@
>   };
>  };
>  
> +&cpu0 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck6_reg>;
> +};
> +
>  &usbdrd_dwc3_1 {
>   dr_mode = "host";
>  };
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 35cfb07..30f146b 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -676,6 +676,14 @@
>   };
>  };
>  
> +&cpu0 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck6_reg>;
> +};
> +
>  &i2c_2 {
>   status = "okay";
>   samsung,i2c-sda-delay = <100>;
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index ac35aef..fdfe4e6 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -423,3 +423,11 @@
>  &usbdrd_phy1 {
>   vbus-supply = <&usb301_vbus_reg>;
>  };
> +
> +&cpu0 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck6_reg>;
> +};
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> index 2ae1cf4..0bfd981 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> @@ -54,6 +54,14 @@
>   };
>  };
>  
> +&cpu0 {
> + cpu-supply = <&buck6_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
>  &pwm {
>   /*
>* PWM 0 -- fan
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index 432406d..b19561c 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -53,6 +53,14 @@
>   };
>  };
>  
> +&cpu0 {
> + cpu-supply = <&buck6_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
>  &i2c_0 {
>   status = "okay";
>  
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf886..bdc7106 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -32,6 +32,14 @@
>   };
>  };
>  
> +&cpu0 {
> + cpu-supply = <&buck6_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
>  &pwm {
>   /*
>* PWM 0 -- fan
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 7b018e4..03ff1ceb 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -638,6 +638,14 @@
>   };
>  };
>  
> +&cpu0 {
> + cpu-supply = <&buck2_reg>;
> +};
> +
> +&cpu4 {
> + cpu-supply = <&buck6_reg>;
> +};
> +
>  &i2c_2 {
>   status = "okay";
>   samsung,i2c-sda-delay = <100>;
> 


-- 
Markus Reichl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MIPS: Fix DMA contiguous allocation

[Qais Yousef]

Recent changes to how GFP_ATOMIC is defined seems to have broken the condition
to use mips_alloc_from_contiguous() in mips_dma_alloc_coherent().

I couldn't bottom out the exact change but I think it's this one

d0164adc89f6 (mm, page_alloc: distinguish between being unable to sleep,
unwilling to sleep and avoiding waking kswapd)

>From what I see GFP_ATOMIC has multiple bits set and the check for !(gfp
& GFP_ATOMIC) isn't enough. To verify if the flag is atomic we need to make
sure that (gfp & GFP_ATOMIC) == GFP_ATOMIC to verify that all bits rquired to
satisfy GFP_ATOMIC condition are set.

Signed-off-by: Qais Yousef 
---
 arch/mips/mm/dma-default.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index d8117be729a2..d6b8a1445a3a 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -145,7 +145,7 @@ static void *mips_dma_alloc_coherent(struct device *dev, 
size_t size,
 
gfp = massage_gfp_flags(dev, gfp);
 
-   if (IS_ENABLED(CONFIG_DMA_CMA) && !(gfp & GFP_ATOMIC))
+   if (IS_ENABLED(CONFIG_DMA_CMA) && ((gfp & GFP_ATOMIC) != GFP_ATOMIC))
page = dma_alloc_from_contiguous(dev,
count, get_order(size));
if (!page)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/4] iio: adc: add IMX7D ADC driver support

[Haibo Chen]

Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
driver support, and the driver only support ADC software trigger.

Signed-off-by: Haibo Chen 
---
 drivers/iio/adc/Kconfig |   9 +
 drivers/iio/adc/Makefile|   1 +
 drivers/iio/adc/imx7d_adc.c | 589 
 3 files changed, 599 insertions(+)
 create mode 100644 drivers/iio/adc/imx7d_adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7868c74..3493a46 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -194,6 +194,15 @@ config HI8435
  This driver can also be built as a module. If so, the module will be
  called hi8435.
 
+config IMX7D_ADC
+   tristate "IMX7D ADC driver"
+   depends on ARCH_MXC || COMPILE_TEST
+   help
+ Say yes here to build support for IMX7D ADC.
+
+ This driver can also be built as a module. If so, the module will be
+ called imx7d_adc.
+
 config LP8788_ADC
tristate "LP8788 ADC driver"
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 99b37a9..282ffc01 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
new file mode 100644
index 000..d3511b9
--- /dev/null
+++ b/drivers/iio/adc/imx7d_adc.c
@@ -0,0 +1,589 @@
+/*
+ * Freescale i.MX7D ADC driver
+ *
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* ADC register */
+#define IMX7D_REG_ADC_CH_A_CFG10x00
+#define IMX7D_REG_ADC_CH_A_CFG20x10
+#define IMX7D_REG_ADC_CH_B_CFG10x20
+#define IMX7D_REG_ADC_CH_B_CFG20x30
+#define IMX7D_REG_ADC_CH_C_CFG10x40
+#define IMX7D_REG_ADC_CH_C_CFG20x50
+#define IMX7D_REG_ADC_CH_D_CFG10x60
+#define IMX7D_REG_ADC_CH_D_CFG20x70
+#define IMX7D_REG_ADC_CH_SW_CFG0x80
+#define IMX7D_REG_ADC_TIMER_UNIT   0x90
+#define IMX7D_REG_ADC_DMA_FIFO 0xa0
+#define IMX7D_REG_ADC_FIFO_STATUS  0xb0
+#define IMX7D_REG_ADC_INT_SIG_EN   0xc0
+#define IMX7D_REG_ADC_INT_EN   0xd0
+#define IMX7D_REG_ADC_INT_STATUS   0xe0
+#define IMX7D_REG_ADC_CHA_B_CNV_RSLT   0xf0
+#define IMX7D_REG_ADC_CHC_D_CNV_RSLT   0x100
+#define IMX7D_REG_ADC_CH_SW_CNV_RSLT   0x110
+#define IMX7D_REG_ADC_DMA_FIFO_DAT 0x120
+#define IMX7D_REG_ADC_ADC_CFG  0x130
+
+#define IMX7D_REG_ADC_CHANNEL_CFG2_BASE0x10
+#define IMX7D_EACH_CHANNEL_REG_OFFSET  0x20
+
+#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN   (0x1 << 31)
+#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLE   BIT(30)
+#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_EN   BIT(29)
+#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL(x)   ((x) << 24)
+
+#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4(0x0 << 
12)
+#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8(0x1 << 
12)
+#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16   (0x2 << 12)
+#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32   (0x3 << 12)
+
+#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_4 (0x0 << 29)
+#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_8 (0x1 << 29)
+#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_16(0x2 << 29)
+#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_32(0x3 << 29)
+#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_64(0x4 << 29)
+#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_128   (0x5 << 29)
+
+#define IMX7D_REG_ADC_ADC_CFG_ADC_CLK_DOWN BIT(31)
+#define IMX7D_REG_ADC_ADC_CFG_ADC_POWER_DOWN   BIT(1)
+#define IMX7D_REG_ADC_ADC_CFG_ADC_EN   BIT(0)
+
+#define IMX7D_REG_ADC_INT_CHA_COV_INT_EN   BIT(8)
+#define IMX7D_REG_ADC_INT_CHB_COV_INT_EN   BIT(9)
+#define IMX7D_REG_ADC_INT_CHC_COV_INT_EN

[PATCH v5 0/4] Add i.mx7d adc driver support

[Haibo Chen]

This patch set add imx7d adc driver support.

Changes in v5:
-call imx7d_adc_power_down() in driver probe when iio_device_register() failed
-handle with adc channel conversion timeout in imx7d_adc_isr()

Changes in v4:
-sort the include head file alphabetically
-really just clear the bit 31 of register REG_ADC_CH_A\B\C\D_CFG1 
 in function imx7d_adc_sample_rate_set()
-add document in imx7d_adc_isr() to clarify the clear operation
-add function imx7d_adc_power_down()
-adjust the format of the code and add some small changes

Changes in v3:
-move down the irq request in probe()
-remove the property 'num-channels' in dts
-remove some unused head file
-add clear register operation in imx7d_adc_isr()

Changes in v2:
-prefix defines with IMX7D_ for all the register
-use BIT macro to define a single bit
-remove the dma_en from struct adc_feature which is not support currently
-use static const array to replace the switch case code

Haibo Chen (4):
  iio: adc: add IMX7D ADC driver support
  Documentation: add the binding file for Freescale imx7d ADC driver
  ARM: dts: imx7d.dtsi: add ADC support
  ARM: dts: imx7d-sdb: add ADC support

 .../devicetree/bindings/iio/adc/imx7d-adc.txt  |  22 +
 arch/arm/boot/dts/imx7d-sdb.dts|  10 +
 arch/arm/boot/dts/imx7d.dtsi   |  18 +
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/imx7d_adc.c| 589 +
 6 files changed, 649 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
 create mode 100644 drivers/iio/adc/imx7d_adc.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 4/4] ARM: dts: imx7d-sdb: add ADC support

[Haibo Chen]

Add ADC support for imx7d-sdb board.

Signed-off-by: Haibo Chen 
---
 arch/arm/boot/dts/imx7d-sdb.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 432aaf5..b2c4536 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -97,6 +97,16 @@
};
 };
 
+&adc1 {
+   vref-supply = <®_vref_1v8>;
+   status = "okay";
+};
+
+&adc2 {
+   vref-supply = <®_vref_1v8>;
+   status = "okay";
+};
+
 &cpu0 {
arm-supply = <&sw1a_reg>;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] ARM: SWP emulation: Restore original *data when failed

[Vladimir Murzin]

On 15/10/15 10:30, Shengjiu Wang wrote:
> __user_swpX_asm maybe failed in first STREX operation, emulate_swpX
> will try again, but the *data has been changed in first time. which
> causes the result is wrong.
> This patch is to fix this issue. When STREX succeed, change the *data.
> if it fail, *data is not changed.
> 
> Signed-off-by: Shengjiu Wang 
> ---
>  arch/arm/kernel/swp_emulate.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
> index 5b26e7e..c3fe769d 100644
> --- a/arch/arm/kernel/swp_emulate.c
> +++ b/arch/arm/kernel/swp_emulate.c
> @@ -36,10 +36,10 @@
>   */
>  #define __user_swpX_asm(data, addr, res, temp, B)\
>   __asm__ __volatile__(   \
> - "   mov %2, %1\n"   \
> - "0: ldrex"B"%1, [%3]\n" \
> - "1: strex"B"%0, %2, [%3]\n" \
> + "0: ldrex"B"%2, [%3]\n" \
> + "1: strex"B"%0, %1, [%3]\n" \
>   "   cmp %0, #0\n"   \
> + "   moveq   %1, %2\n"   \
>   "   movne   %0, %4\n"   \
>   "2:\n"  \
>   "   .section .text.fixup,\"ax\"\n"  \
> 

I wonder what is status of this patch? I see that arm64 counterpart has
landed in mainline, but I didn't manage to track down this one - is it
because it never been submitted to patch system?

Thanks
Vladimir

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Staging: rdma:Delete unnecessary NULL check before calling function "kmem_cache_destroy"

[Shah, Yash (Y.)]

From: Yash Shah 

The kmem_cache_destroy() function tests whether its argument is NULL
and then returns immediately. 
Thus the NULL check before calling this function is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Yash Shah 
---
 drivers/staging/rdma/ehca/ehca_av.c   | 3 +--
 drivers/staging/rdma/ehca/ehca_cq.c   | 3 +--
 drivers/staging/rdma/ehca/ehca_main.c | 3 +--
 drivers/staging/rdma/ehca/ehca_mrmw.c | 6 ++
 drivers/staging/rdma/ehca/ehca_pd.c   | 3 +--
 drivers/staging/rdma/ehca/ehca_qp.c   | 3 +--
 6 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rdma/ehca/ehca_av.c 
b/drivers/staging/rdma/ehca/ehca_av.c
index fd7b6d0..94e088c 100644
--- a/drivers/staging/rdma/ehca/ehca_av.c
+++ b/drivers/staging/rdma/ehca/ehca_av.c
@@ -275,6 +275,5 @@ int ehca_init_av_cache(void)
 
 void ehca_cleanup_av_cache(void)
 {
-   if (av_cache)
-   kmem_cache_destroy(av_cache);
+   kmem_cache_destroy(av_cache);
 }
diff --git a/drivers/staging/rdma/ehca/ehca_cq.c 
b/drivers/staging/rdma/ehca/ehca_cq.c
index ea1b5c1..1aa7931 100644
--- a/drivers/staging/rdma/ehca/ehca_cq.c
+++ b/drivers/staging/rdma/ehca/ehca_cq.c
@@ -393,6 +393,5 @@ int ehca_init_cq_cache(void)
 
 void ehca_cleanup_cq_cache(void)
 {
-   if (cq_cache)
-   kmem_cache_destroy(cq_cache);
+   kmem_cache_destroy(cq_cache);
 }
diff --git a/drivers/staging/rdma/ehca/ehca_main.c 
b/drivers/staging/rdma/ehca/ehca_main.c
index 8246418..860b974 100644
--- a/drivers/staging/rdma/ehca/ehca_main.c
+++ b/drivers/staging/rdma/ehca/ehca_main.c
@@ -245,8 +245,7 @@ static void ehca_destroy_slab_caches(void)
ehca_cleanup_cq_cache();
ehca_cleanup_pd_cache();
 #ifdef CONFIG_PPC_64K_PAGES
-   if (ctblk_cache)
-   kmem_cache_destroy(ctblk_cache);
+   kmem_cache_destroy(ctblk_cache);
 #endif
 }
 
diff --git a/drivers/staging/rdma/ehca/ehca_mrmw.c 
b/drivers/staging/rdma/ehca/ehca_mrmw.c
index f914b30..553e883 100644
--- a/drivers/staging/rdma/ehca/ehca_mrmw.c
+++ b/drivers/staging/rdma/ehca/ehca_mrmw.c
@@ -2251,10 +2251,8 @@ int ehca_init_mrmw_cache(void)
 
 void ehca_cleanup_mrmw_cache(void)
 {
-   if (mr_cache)
-   kmem_cache_destroy(mr_cache);
-   if (mw_cache)
-   kmem_cache_destroy(mw_cache);
+   kmem_cache_destroy(mr_cache);
+   kmem_cache_destroy(mw_cache);
 }
 
 static inline int ehca_init_top_bmap(struct ehca_top_bmap *ehca_top_bmap,
diff --git a/drivers/staging/rdma/ehca/ehca_pd.c 
b/drivers/staging/rdma/ehca/ehca_pd.c
index 351577a..2a8aae4 100644
--- a/drivers/staging/rdma/ehca/ehca_pd.c
+++ b/drivers/staging/rdma/ehca/ehca_pd.c
@@ -119,6 +119,5 @@ int ehca_init_pd_cache(void)
 
 void ehca_cleanup_pd_cache(void)
 {
-   if (pd_cache)
-   kmem_cache_destroy(pd_cache);
+   kmem_cache_destroy(pd_cache);
 }
diff --git a/drivers/staging/rdma/ehca/ehca_qp.c 
b/drivers/staging/rdma/ehca/ehca_qp.c
index 2e89356..896c01f 100644
--- a/drivers/staging/rdma/ehca/ehca_qp.c
+++ b/drivers/staging/rdma/ehca/ehca_qp.c
@@ -2252,6 +2252,5 @@ int ehca_init_qp_cache(void)
 
 void ehca_cleanup_qp_cache(void)
 {
-   if (qp_cache)
-   kmem_cache_destroy(qp_cache);
+   kmem_cache_destroy(qp_cache);
 }
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/9] clk: hi3519: add dt-binding document and header file

[Arnd Bergmann]

On Tuesday 08 December 2015 17:45:25 xuejiancheng wrote:
> On 2015/12/7 17:36, Arnd Bergmann wrote:
> > On Monday 07 December 2015 16:01:03 xuejiancheng wrote:
> >> On 2015/12/4 18:56, Arnd Bergmann wrote:
> >>> On Friday 04 December 2015 11:21:28 xuejiancheng wrote:
>  Hi Arnd,
> 
>  On 2015/12/3 17:44, Arnd Bergmann wrote:
> > On Thursday 03 December 2015 10:39:24 Jiancheng Xue wrote:
> >> +#ifndef __DTS_HI3519_CLOCK_H
> >> +#define __DTS_HI3519_CLOCK_H
> >
> > Please try to avoid adding headers like this if you can at all.
> >
> > I might ask you to merge the header file in one merge window
> > otherwise and submit the platform code one kernel later, as they
> > tendn to cause us needless dependencies otherwise.
> >
> 
>  Sorry. In v1, Rob suggested putting binding doc and header files in
>  a separate patch. The clock driver indeed depends on the header.
> 
>  I will put the header and the clock driver in a patch, and keep the
>  binding doc in another patch.
> >>>
> >>> Having split patches is better, I was really commenting on the fact
> >>> that ideally you would not have a header file at all. If we merge
> >>> the header through arm-soc, then you won't be able to merge the
> >>> clk driver easily, and if you merge the header through the clk
> >>> maintainer, I'm can't take your dts files.
> >>
> >> Thank you for your comments. Because the clocks in the crg module have
> >> different types and random layouts. If this header file is removed,
> >> the clock driver and the dts files will get very complicated.
> >>
> >> Could you help me acknowledge it if I put the header file and clock driver
> >> in a patch?
> >>
> >> Could you give me some suggestions If I want to keep this header file?
> > 
> > If this is another clock controller that has a random register layout,
> > then adding the header file is the least problematic solution indeed.
> 
> Is it OK if I put the header file and the clock driver in a patch?
> 
> If it's not OK, could you tell me how should I separate the patches?

It's ok to do it like this, but then I can't easily merge any DT changes
based on the header file into the arm-soc tree in the same merge window.
Staging out the .dts files by one merge window is the easiest solution
here, otherwise you need to set up a shared branch with the headers
changes and base both the clk driver and the dts branch on top of that
and cannot rebase those patches.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller

[Cyrille Pitchen]

Hi Brian,

Le 07/12/2015 20:34, Brian Norris a écrit :
> + Bean Huo
> 
> Hi Cyrille,
> 
> On Mon, Dec 07, 2015 at 03:09:09PM +0100, Cyrille Pitchen wrote:
>> Hi all,
>>
>> this series of patches adds support to the Atmel QSPI controller available
>> on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra board with a 
>> Micron n25q128a13 QSPI memory and a at25df321a SPI memory.
>>
>> In order to use the Micron memory in its Quad SPI mode, the spi-nor
>> framework needed to be patched to fix the support of Quad/Dual SPI
>> protocols with some memory manufacturers such as Spansion, Micron and
>> Macronix. There are many comments in the source code to explain the
>> implementation choices based on the datasheets from memory manufacturers.
>>
>>
>> This series was based and tested on linux-next-20151207
>>
>> 1 - Atmel QSPI + Micron n25q128a13 (atmel-quadspi.c driver)
>>
>> SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by SPI_NOR_FAST as
>>argument to spi_nor_scan() called from atmel_qspi_probe().
>>
>> SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
>>mode of the Micron memory. When probed from Linux, the memory
>>uses its Extended SPI mode and replies to the regular Read ID
>>(0x9f) command.
>>
>> SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
>>before loading the at91bootstrap. When probed from Linux, the
>>memory uses its Quad SPI mode and no longer replies to the
>>regular Read ID (0x9f) command but instead to the Read ID
>>Multiple I/O (0xaf) command. The memory expects ALL commands
>>to use the SPI 4-4-4 protocol.
> 
> I'll admit I'm a little fuzzy on the differences between dual and quad
> modes on various flash manufacturers. Can you help clear it up for me?
> I think some of the comments on patch 2 help too, but I'll just comment
> here for now.
> 
> It looks like the current driver has problems regarding the non 1-x-y
> modes (e.g., 4-4-4), right? But I see that spi-nor.c never tries to
> send a 4_4_4 command; it only sets read_opcode to
> SPINOR_OP_READ_1_1_{1,2,4}. So is this an oversight in patches like
> Bean's patch?
> 
> commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> SPI NOR")
> 
> Why would we even need to enable quad modes like that, if we're not
> going to send the 4-4-4 opcodes?

First let me clarify one point. This series focuses on Spansion, Macronix
and Micron because when I wrote its patches few months ago, the spi-nor.c
driver supported QSPI protocols only for these three only manufacturers.
Today I notice that now some Winbond memories also use the
SPI_NOR_QUAD_READ flag. Though I try to deal with all manufacturers on a
equal foot, I currently have no knowledge on Windond memories so my
explanations only apply to Spansion, Macronix and Micron memories.

About the SPI 4-4-4 protocol, it is only supported by Micron and Macronix
memories but not by Spansion. Both Micron and Macronix memories provide us
with a special mode, let's call it the Quad SPI mode. As Bean Huo explained
for Micron, once this mode is enabled, the memory expects all commands to
use the SPI 4-4-4 protocol. Hence even if the spi-nor.c driver uses the Fast
Read Quad Output 1-1-4 (0x6b/0x6c) or the Fast Read Quad I/O 1-4-4 (0xeb/0xec)
op codes, the command is interpreted as a Fast Read Quad Command 4-4-4 so must
use the SPI 4-4-4 protocol. As far as I know, there is no currently existing
op code dedicated to the Fast Read Quad Command 4-4-4.

So the op codes may be confusing but when the Quad SPI mode is enabled we
actually use Fast Read 4-4-4 commands.

> 
> My next question (if my understanding is roughly correct) is, do we need
> the 4-4-4 modes, and what risks come with them? I understand we can
> shorten the command and address phases, but does that alone yield much
> performance benefit? And I think the risk is that a given system might
> not be prepared for the flash to be in a 4-4-4 mode, if the boot code
> tries to use 1-x-y commands.
> 

I did not run comparative tests between Fast Read 1-1-4, Fast Read 1-4-4
and Fast Read 4-4-4 yet. Honestly I don't expect much difference. However
performances were not the main purpose when I wrote these patches.
Actually the Quad SPI mode of Macronix and Micron comes with a side effect.
Once enable, not only the memory now expects all commands to use the
SPI 4-4-4 protocol but it no longer replies to the regular Read JEDEC ID
command (0x9f). Instead it replies to a new command, the Read JEDEC ID
Multiple I/O (0xaf).
Now let's imagine that the Quad SPI mode is either permanently enabled at
reset using non-volatile configuration registers or enabled by a early
bootloader. When the spi-nor driver tries to probe the memory, the 0x9f
command fails: the driver should adapt, that's why it tries other protocols
such as SPI 4-4-4 (Micron and Macronix) and SPI 2-2-2 (Micron only when in
Du

Re: [PATCH 05/23] mtd: nand: jz4770: kill the ->ecc_layout field

[Harvey Hunt]

Hi Boris,

On 07/12/15 22:26, Boris Brezillon wrote:

->ecc_layout is not used by any board file. Kill this field to avoid any
confusion. New boards are encouraged to use the default ECC layout defined
in NAND core.

Signed-off-by: Boris Brezillon 
---
  arch/mips/include/asm/mach-jz4740/jz4740_nand.h | 2 --
  drivers/mtd/nand/jz4740_nand.c  | 3 ---
  2 files changed, 5 deletions(-)

diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h 
b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
index 79cff26..398733e 100644
--- a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
+++ b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
@@ -25,8 +25,6 @@ struct jz_nand_platform_data {
int num_partitions;
struct mtd_partition*partitions;

-   struct nand_ecclayout   *ecc_layout;
-
unsigned char banks[JZ_NAND_NUM_BANKS];

void (*ident_callback)(struct platform_device *, struct nand_chip *,
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index 5a99a93..c4fe446 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -446,9 +446,6 @@ static int jz_nand_probe(struct platform_device *pdev)
chip->ecc.bytes  = 9;
chip->ecc.strength   = 4;

-   if (pdata)
-   chip->ecc.layout = pdata->ecc_layout;
-
chip->chip_delay = 50;
chip->cmd_ctrl = jz_nand_cmd_ctrl;
chip->select_chip = jz_nand_select_chip;



Is there a typo in this commit title? The JZ4740 and JZ4770 have quite 
different NAND controller interfaces, so I don't think that the JZ4740 
driver will support the JZ4770.


Thanks,

Harvey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/23] mtd: nand: jz4770: kill the ->ecc_layout field

[Boris Brezillon]

On Tue, 8 Dec 2015 10:30:40 +
Harvey Hunt  wrote:

> Hi Boris,
> 
> On 07/12/15 22:26, Boris Brezillon wrote:
> > ->ecc_layout is not used by any board file. Kill this field to avoid any
> > confusion. New boards are encouraged to use the default ECC layout defined
> > in NAND core.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> >   arch/mips/include/asm/mach-jz4740/jz4740_nand.h | 2 --
> >   drivers/mtd/nand/jz4740_nand.c  | 3 ---
> >   2 files changed, 5 deletions(-)
> >
> > diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h 
> > b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
> > index 79cff26..398733e 100644
> > --- a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
> > +++ b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
> > @@ -25,8 +25,6 @@ struct jz_nand_platform_data {
> > int num_partitions;
> > struct mtd_partition*partitions;
> >
> > -   struct nand_ecclayout   *ecc_layout;
> > -
> > unsigned char banks[JZ_NAND_NUM_BANKS];
> >
> > void (*ident_callback)(struct platform_device *, struct nand_chip *,
> > diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
> > index 5a99a93..c4fe446 100644
> > --- a/drivers/mtd/nand/jz4740_nand.c
> > +++ b/drivers/mtd/nand/jz4740_nand.c
> > @@ -446,9 +446,6 @@ static int jz_nand_probe(struct platform_device *pdev)
> > chip->ecc.bytes = 9;
> > chip->ecc.strength  = 4;
> >
> > -   if (pdata)
> > -   chip->ecc.layout = pdata->ecc_layout;
> > -
> > chip->chip_delay = 50;
> > chip->cmd_ctrl = jz_nand_cmd_ctrl;
> > chip->select_chip = jz_nand_select_chip;
> >
> 
> Is there a typo in this commit title? The JZ4740 and JZ4770 have quite 
> different NAND controller interfaces, so I don't think that the JZ4740 
> driver will support the JZ4770.

Yes, it's a typo, I meant jz4740, I'll fix my commit message
accordingly.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver

[kbuild test robot]

Hi Yong,

[auto build test ERROR on tegra/for-next]
[also build test ERROR on v4.4-rc4 next-20151208]

url:
https://github.com/0day-ci/linux/commits/Yong-Wu/MT8173-IOMMU-SUPPORT/20151208-175252
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux for-next
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/iommu/dma-iommu.c: In function '__iommu_dma_alloc_pages':
>> drivers/iommu/dma-iommu.c:198:11: error: implicit declaration of function 
>> 'vzalloc' [-Werror=implicit-function-declaration]
  pages = vzalloc(array_size);
  ^
>> drivers/iommu/dma-iommu.c:198:9: warning: assignment makes pointer from 
>> integer without a cast [-Wint-conversion]
  pages = vzalloc(array_size);
^
   cc1: some warnings being treated as errors
--
>> drivers/iommu/mtk_iommu.c:176:19: warning: initialization from incompatible 
>> pointer type [-Wincompatible-pointer-types]
 .tlb_add_flush = mtk_iommu_tlb_add_flush_nosync,
  ^
   drivers/iommu/mtk_iommu.c:176:19: note: (near initialization for 
'mtk_iommu_gather_ops.tlb_add_flush')
   drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_domain_finalise':
>> drivers/iommu/mtk_iommu.c:239:4: error: 'IO_PGTABLE_QUIRK_NO_PERMS' 
>> undeclared (first use in this function)
   IO_PGTABLE_QUIRK_NO_PERMS |
   ^
   drivers/iommu/mtk_iommu.c:239:4: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/iommu/mtk_iommu.c:240:4: error: 'IO_PGTABLE_QUIRK_TLBI_ON_MAP' 
>> undeclared (first use in this function)
   IO_PGTABLE_QUIRK_TLBI_ON_MAP,
   ^
>> drivers/iommu/mtk_iommu.c:248:34: error: 'ARM_V7S' undeclared (first use in 
>> this function)
 dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
 ^
   In file included from arch/x86/include/asm/realmode.h:5:0,
from arch/x86/include/asm/acpi.h:33,
from arch/x86/include/asm/fixmap.h:19,
from arch/x86/include/asm/apic.h:12,
from arch/x86/include/asm/smp.h:12,
from arch/x86/include/asm/mmzone_64.h:10,
from arch/x86/include/asm/mmzone.h:4,
from include/linux/mmzone.h:856,
from include/linux/topology.h:32,
from include/linux/of.h:24,
from include/linux/iommu.h:24,
from include/linux/dma-iommu.h:23,
from drivers/iommu/mtk_iommu.c:16:
>> drivers/iommu/mtk_iommu.c:257:35: error: 'struct io_pgtable_cfg' has no 
>> member named 'arm_v7s_cfg'
 writel_relaxed(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
  ^
   arch/x86/include/asm/io.h:81:39: note: in definition of macro 
'writel_relaxed'
#define writel_relaxed(v, a) __writel(v, a)
  ^
   drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_resume':
   drivers/iommu/mtk_iommu.c:702:35: error: 'struct io_pgtable_cfg' has no 
member named 'arm_v7s_cfg'
 writel_relaxed(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
  ^
   arch/x86/include/asm/io.h:81:39: note: in definition of macro 
'writel_relaxed'
#define writel_relaxed(v, a) __writel(v, a)
  ^

vim +/IO_PGTABLE_QUIRK_NO_PERMS +239 drivers/iommu/mtk_iommu.c

   170  /* Clear the CPE status */
   171  writel_relaxed(0, data->base + REG_MMU_CPE_DONE);
   172  }
   173  
   174  static const struct iommu_gather_ops mtk_iommu_gather_ops = {
   175  .tlb_flush_all = mtk_iommu_tlb_flush_all,
 > 176  .tlb_add_flush = mtk_iommu_tlb_add_flush_nosync,
   177  .tlb_sync = mtk_iommu_tlb_sync,
   178  };
   179  
   180  static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
   181  {
   182  struct mtk_iommu_data *data = dev_id;
   183  struct mtk_iommu_domain *dom = data->m4u_dom;
   184  u32 int_state, regval, fault_iova, fault_pa;
   185  unsigned int fault_larb, fault_port;
   186  bool layer, write;
   187  
   188  /* Read error info from registers */
   189  int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
   190  fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
   191  layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
   192  write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
   193  fault_iova &= F_MMU_FAULT_VA_MSK;
   194

[PATCH v5 3/4] ARM: dts: imx7d.dtsi: add ADC support

[Haibo Chen]

Add imx7d ADC support.

Signed-off-by: Haibo Chen 
---
 arch/arm/boot/dts/imx7d.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index ebc053a..aa0624d 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -583,6 +583,24 @@
reg = <0x3040 0x40>;
ranges;
 
+   adc1: adc@3061 {
+   compatible = "fsl,imx7d-adc";
+   reg = <0x3061 0x1>;
+   interrupts = ;
+   clocks = <&clks IMX7D_ADC_ROOT_CLK>;
+   clock-names = "adc";
+   status = "disabled";
+   };
+
+   adc2: adc@3062 {
+   compatible = "fsl,imx7d-adc";
+   reg = <0x3062 0x1>;
+   interrupts = ;
+   clocks = <&clks IMX7D_ADC_ROOT_CLK>;
+   clock-names = "adc";
+   status = "disabled";
+   };
+
pwm1: pwm@3066 {
compatible = "fsl,imx7d-pwm", "fsl,imx27-pwm";
reg = <0x3066 0x1>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/4] Documentation: add the binding file for Freescale imx7d ADC driver

[Haibo Chen]

The patch adds the binding file for Freescale imx7d ADC driver.

Signed-off-by: Haibo Chen 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/iio/adc/imx7d-adc.txt  | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
new file mode 100644
index 000..5c184b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/imx7d-adc.txt
@@ -0,0 +1,22 @@
+Freescale imx7d ADC bindings
+
+The devicetree bindings are for the ADC driver written for
+imx7d SoC.
+
+Required properties:
+- compatible: Should be "fsl,imx7d-adc"
+- reg: Offset and length of the register set for the ADC device
+- interrupts: The interrupt number for the ADC device
+- clocks: The root clock of the ADC controller
+- clock-names: Must contain "adc", matching entry in the clocks property
+- vref-supply: The regulator supply ADC reference voltage
+
+Example:
+adc1: adc@3061 {
+   compatible = "fsl,imx7d-adc";
+   reg = <0x3061 0x1>;
+   interrupts = ;
+   clocks = <&clks IMX7D_ADC_ROOT_CLK>;
+   clock-names = "adc";
+   vref-supply = <®_vcc_3v3_mcu>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

4.4-rc4: /etc/profile: interrupted system call

[Pavel Machek]

Hi!

While opening terminal in gnome2...

This is the first time I see the message, and it looks quite strange.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] ARM: SWP emulation: Restore original *data when failed

[Russell King - ARM Linux]

On Tue, Dec 08, 2015 at 10:22:53AM +, Vladimir Murzin wrote:
> On 15/10/15 10:30, Shengjiu Wang wrote:
> > __user_swpX_asm maybe failed in first STREX operation, emulate_swpX
> > will try again, but the *data has been changed in first time. which
> > causes the result is wrong.
> > This patch is to fix this issue. When STREX succeed, change the *data.
> > if it fail, *data is not changed.
> > 
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  arch/arm/kernel/swp_emulate.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
> > index 5b26e7e..c3fe769d 100644
> > --- a/arch/arm/kernel/swp_emulate.c
> > +++ b/arch/arm/kernel/swp_emulate.c
> > @@ -36,10 +36,10 @@
> >   */
> >  #define __user_swpX_asm(data, addr, res, temp, B)  \
> > __asm__ __volatile__(   \
> > -   "   mov %2, %1\n"   \
> > -   "0: ldrex"B"%1, [%3]\n" \
> > -   "1: strex"B"%0, %2, [%3]\n" \
> > +   "0: ldrex"B"%2, [%3]\n" \
> > +   "1: strex"B"%0, %1, [%3]\n" \
> > "   cmp %0, #0\n"   \
> > +   "   moveq   %1, %2\n"   \
> > "   movne   %0, %4\n"   \
> > "2:\n"  \
> > "   .section .text.fixup,\"ax\"\n"  \
> > 
> 
> I wonder what is status of this patch? I see that arm64 counterpart has
> landed in mainline, but I didn't manage to track down this one - is it
> because it never been submitted to patch system?

Most probably.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tip:locking/core] sched/wait: Fix signal handling in bit wait helpers

[Peter Zijlstra]

On Fri, Dec 04, 2015 at 03:52:12AM -0800, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  68985633bccb6066bf1803e316fbc6c1f5b796d6
> Gitweb: http://git.kernel.org/tip/68985633bccb6066bf1803e316fbc6c1f5b796d6
> Author: Peter Zijlstra 
> AuthorDate: Tue, 1 Dec 2015 14:04:04 +0100
> Committer:  Ingo Molnar 
> CommitDate: Fri, 4 Dec 2015 10:10:15 +0100
> 
> sched/wait: Fix signal handling in bit wait helpers
> 
> Vladimir reported getting RCU stall warnings and bisected it back to
> commit:
> 
>   743162013d40 ("sched: Remove proliferation of wait_on_bit() action 
> functions")
> 
> That commit inadvertently reversed the calls to schedule() and 
> signal_pending(),
> thereby not handling the case where the signal receives while we sleep.
> 
> Reported-by: Vladimir Murzin 
> Tested-by: Vladimir Murzin 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Linus Torvalds 
> Cc: Mike Galbraith 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: mark.rutl...@arm.com
> Cc: ne...@suse.de
> Cc: o...@redhat.com
> Fixes: 743162013d40 ("sched: Remove proliferation of wait_on_bit() action 
> functions")
> Fixes: cbbce8220949 ("SCHED: add some "wait..on_bit...timeout()" interfaces.")
> Link: 
> http://lkml.kernel.org/r/20151201130404.gl3...@twins.programming.kicks-ass.net
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/sched/wait.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
> index 052e026..f10bd87 100644
> --- a/kernel/sched/wait.c
> +++ b/kernel/sched/wait.c
> @@ -583,18 +583,18 @@ EXPORT_SYMBOL(wake_up_atomic_t);
>  
>  __sched int bit_wait(struct wait_bit_key *word)
>  {
> - if (signal_pending_state(current->state, current))
> - return 1;
>   schedule();
> + if (signal_pending(current))
> + return -EINTR;
>   return 0;
>  }

*sigh*, so that patch was broken.. the below might fix it, but please
someone look at it, I seem to have a less than stellar track record
here...

---
Subject: sched/wait: Fix the signal handling fix

Jan Stancek reported that I wrecked things for him by fixing things for
Vladimir :/

His report was due to an UNINTERRUPTIBLE wait getting -EINTR, which
should not be possible, however my previous patch made this possible by
unconditionally checking signal_pending().

We cannot use current->state as was done previously, because the
instruction after the store to that variable it can be changed. We must
instead pass the initial state along and use that.

Fixes: 68985633bccb ("sched/wait: Fix signal handling in bit wait helpers")
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: mark.rutl...@arm.com
Cc: ne...@suse.de
Cc: o...@redhat.com
Cc: Vladimir Murzin 
Reported-by: Jan Stancek 
Tested-by: Jan Stancek 
Signed-off-by: Peter Zijlstra (Intel) 
---
 fs/cifs/inode.c  |6 +++---
 fs/nfs/inode.c   |6 +++---
 fs/nfs/internal.h|2 +-
 fs/nfs/pagelist.c|2 +-
 fs/nfs/pnfs.c|4 ++--
 include/linux/wait.h |   10 +-
 kernel/sched/wait.c  |   20 ++--
 net/sunrpc/sched.c   |6 +++---
 8 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 6b66dd5..a329f5b 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1831,11 +1831,11 @@ cifs_invalidate_mapping(struct inode *inode)
  * @word: long word containing the bit lock
  */
 static int
-cifs_wait_bit_killable(struct wait_bit_key *key)
+cifs_wait_bit_killable(struct wait_bit_key *key, int mode)
 {
-   if (fatal_signal_pending(current))
-   return -ERESTARTSYS;
freezable_schedule_unsafe();
+   if (signal_pending_state(mode, current))
+   return -ERESTARTSYS;
return 0;
 }
 
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 31b0a52..c7e8b87 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -75,11 +75,11 @@ nfs_fattr_to_ino_t(struct nfs_fattr *fattr)
  * nfs_wait_bit_killable - helper for functions that are sleeping on bit locks
  * @word: long word containing the bit lock
  */
-int nfs_wait_bit_killable(struct wait_bit_key *key)
+int nfs_wait_bit_killable(struct wait_bit_key *key, int mode)
 {
-   if (fatal_signal_pending(current))
-   return -ERESTARTSYS;
freezable_schedule_unsafe();
+   if (signal_pending_state(mode, current))
+   return -ERESTARTSYS;
return 0;
 }
 EXPORT_SYMBOL_GPL(nfs_wait_bit_killable);
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 56cfde2..9dea85f 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -379,7 +379,7 @@ extern int nfs_drop_inode(struct inode *);
 extern void nfs_clear_inode(struct inode *);
 extern void nfs_evict_inode(struct inode *);
 void nfs_zap_acl_cache(struct inode *inode);
-extern int nfs_wait_bit_killable(struct wait_bit_key *key);
+extern int nfs_wait_bit_killable(struct wait_bit_key *key, int mode);
 
 /* super.c */
 extern const stru

Re: Ques: [kernel/time/*] Is there any disadvantage in using sleep_range for more than 20ms delay ?

[Thomas Gleixner]

On Tue, 8 Dec 2015, Aniroop Mathur wrote:
> On Tue, Dec 8, 2015 at 12:07 AM, Thomas Gleixner  wrote:
> > The real question is how precise must your delay be? If the delay
> > needs to be precise within the min/max sleep time limits, then
> > usleep_range() is probably the way to go. If the delay can be
> > imprecise then using msleep() is the right way because that lets the
> > kernel batch timers for power saving purposes.
>
> Thank you for the answer !
> Normally, we insert delays in driver while enabling the chip.
> So here usleep_range seems to service better as we do not want to delay
> the initialisation process of chip and make it ready to generate data,
> especially for faster devices like sensor.

The initialization process is hardly something critical, so why would
the delay need to be precise? What's the point of having data 10ms
earlier?
 
> One last thing,
> Considering HZ=100, would the power saving be same if we set the
> range in usleep_range equivalent to msleep ?
> For example: msleep (33) and usleep_range(33000, 4)
> So for such case, would both have same impact on power saving ?

Probably, but what's the point of doing that?

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm64
allnoconfig and others) failed like this:

arch/arm64/mm/mmap.c:54:1: error: unknown type name 'ifdef'
arch/arm64/mm/mmap.c:55:2: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'if'
arch/arm64/mm/mmap.c:57:2: error: 'else' without a previous 'if'
arch/arm64/mm/mmap.c:58:2: error: #endif without #if

Caused by commit

  2e4614190421 ("arm64-mm-support-arch_mmap_rnd_bits-v4")

An obvious typo :-(

I will add the missing '#' tomorrow if it si not fixed by then.

Reported by Mark's build bot.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

[Thomas Gleixner]

On Tue, 8 Dec 2015, Thomas Petazzoni wrote:
> When a device driver uses a normal (non per-CPU) interrupt, then it
> doesn't have to take care of disabling the interrupt on suspend and
> re-enabling the interrupt on resume at the interrupt controller level.
> This is all transparently handled by the irqchip driver.
> 
> Why should the handling of per-CPU interrupts be different and require
> explicit handling from each device driver rather than being
> transparently handled by the irqchip driver ?

Fair enough. Did not think about the boot cpu part.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/13] mvneta Buffer Management and enhancements

[Marcin Wojtas]

Hi David,

2015-12-04 21:15 GMT+01:00 Florian Fainelli :
> (no top posting please)
>
> On 02/12/15 00:26, Marcin Wojtas wrote:
>> Hi Florian,
>>
>> Can you please describe in more details, what would you expect from
>> such special abstraction layer regarding buffer managers? I'd like to
>> understand more of your expectations and evaluate possible work.
>
> Well, something along these lines:
>
> - have the ability to register a particular pool (location + number of
> buffers) in a way that is relatively device agnostic (initialization
> would of course be device specific)
>
> - provide a set of buffer management APIs like those you proposed below,
> and have some generic code that leverages what
> drivers/net/ethernet/sun/niu.c does for instance
>
> - introduce a netdev_alloc_skb_from_pool() or something like that which
> would limit the amount of code to change in your network driver to
> benefit from that feature so based
>
> I am sure David would be able to suggest more detailed API.
>

As we're getting closer to what a generic BM part, could you please
share your thoughts on the possible API?


>>>
 What kind of abstraction and helpers do you mean? Some kind of API
 (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer,
 bm_get_buffer), which would be used by platform drivers (and specific
 aplications if one wants to develop on top of the kernel)?

 In general, what is your top-view of such solution and its cooperation
 with the drivers?
>>>
>>> The tricky parts involved have to do with allocating pages for the
>>> buffer pools and minimizing the number of atomic refcounting
>>> operations on those pages for for the puts and gets, particularly
>>> around buffer replenish runs.
>>>
>>> For example, if you're allocating a page for a buffer pool the device
>>> will chop into N (for any N < PAGE_SIZE) byte pieces, you can
>>> eliminate many atomic operations.
>

Do you think you can point to anything similar that could be a sort of
reference for such solution?

Best regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701

[biao huang]

On Sat, 2015-11-28 at 04:38 +0800, Rob Herring wrote:
> On Thu, Nov 26, 2015 at 04:44:29PM +0800, Biao Huang wrote:
> > Signed-off-by: Biao Huang 
> > ---
> >  .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
> > index 0480bc3..ca6a27a 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
> > @@ -4,10 +4,11 @@ The Mediatek's Pin controller is used to control SoC pins.
> >  
> >  Required properties:
> >  - compatible: value should be one of the following.
> > -(a) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
> > -(b) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
> > -(c) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> > -(d) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
> > +(a) "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
> > +(b) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
> > +(c) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
> > +(d) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
> > +(e) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
> 
> If you were trying to sort these, they still aren't quite sorted. There 
> is no point in sorting if you number (or letter) them because you will 
> have to update many lines on any change. So drop the (a), (b), (c), etc.
> 
> Rob
> 
Thanks for your comments, I'll modify this in next patch. And patch v2
will be sent in next week.
> >  - pins-are-numbered: Specify the subnodes are using numbered pinmux to
> >specify pins.
> >  - gpio-controller : Marks the device node as a gpio controller.
> > -- 
> > 1.7.9.5
> > 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] keys, trusted: seal with a policy

[Jarkko Sakkinen]

On Tue, Dec 08, 2015 at 09:35:05AM +1100, James Morris wrote:
> On Mon, 7 Dec 2015, Jarkko Sakkinen wrote:
> 
> > On Fri, Nov 20, 2015 at 01:34:35PM +1100, James Morris wrote:
> > > On Wed, 18 Nov 2015, Jarkko Sakkinen wrote:
> > > 
> > > > On Wed, Nov 18, 2015 at 11:21:01AM +1100, James Morris wrote:
> > > > > On Tue, 17 Nov 2015, Jarkko Sakkinen wrote:
> > > > > 
> > > > > > }
> > > > > > break;
> > > > > > +   case Opt_policydigest:
> > > > > > +   if (!tpm2 ||
> > > > > > +   strlen(args[0].from) != (2 * 
> > > > > > opt->digest_len))
> > > > > > +   return -EINVAL;
> > > > > > +   kfree(opt->policydigest);
> > > > > > +   opt->policydigest = kzalloc(opt->digest_len,
> > > > > > +   GFP_KERNEL);
> > > > > 
> > > > > Is it correct to kfree opt->policydigest here before allocating it?
> > > > 
> > > > I think so. The same option might be encountered multiple times.
> > > 
> > > This would surely signify an error?
> > 
> > I'm following the semantics of other options. That's why I implemented
> > it that way for example:
> > 
> > keyctl add trusted kmk "new 32 keyhandle=0x8000 keyhandle=0x8000"
> > 
> > is perfectly OK. I just thought that it'd be more odd if this option
> > behaved in a different way...
> 
> It seems broken to me -- if you're messing up keyctl commands you might 
> want to know about it, but we should remain consistent.

So should I return error if policyhandle/digest appears a second time? I
agree that it'd be better to return -EINVAL.

The existing behavior is such that any option can appear multiple times
and I chose to be consistent with that.

> -- 
> James Morris
> 

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/