[RFC PATCH 0/5] arm64: prepare for basic Allwinner support

[RFC PATCH 0/5] arm64: prepare for basic Allwinner support

[Andre Przywara]

This is a first step for introducing support for the Allwinner A64
SoC that made a recent appearance on the Pine A64 board featured on
Kickstarter.
This mini-series prepares the ground by allowing ARCH_SUNXI to be
defined for an arm64 kernel.
The patches fix some minor warnings which appear when Allwinner
(aka. sunxi) drivers are compiled for a 64-bit architecture.

Due to a lack of official documentation and hardware availability
this doesn't go any further at this moment.

Please have a look and comment!

Cheers,
Andre.

Andre Przywara (5):
  drivers: sunxi-rsb: fix error output type
  crypto: sunxi-ss: fix min3() call to match types
  crypto: sunxi-ss: fix dev_dbg() output type
  irqchip: sun4i: fix compilation outside of arch/arm
  arm64: Introduce Allwinner SoC config option

 arch/arm64/Kconfig.platforms              |  5 +++++
 drivers/bus/sunxi-rsb.c                   |  4 ++--
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 14 +++++++-------
 drivers/crypto/sunxi-ss/sun4i-ss-hash.c   |  8 ++++----
 drivers/irqchip/irq-sun4i.c               |  1 -
 5 files changed, 18 insertions(+), 14 deletions(-)

-- 
2.5.1

[RFC PATCH 0/5] arm64: prepare for basic Allwinner support

[Andre Przywara]

This is a first step for introducing support for the Allwinner A64
SoC that made a recent appearance on the Pine A64 board featured on
Kickstarter.
This mini-series prepares the ground by allowing ARCH_SUNXI to be
defined for an arm64 kernel.
The patches fix some minor warnings which appear when Allwinner
(aka. sunxi) drivers are compiled for a 64-bit architecture.

Due to a lack of official documentation and hardware availability
this doesn't go any further at this moment.

Please have a look and comment!

Cheers,
Andre.

Andre Przywara (5):
  drivers: sunxi-rsb: fix error output type
  crypto: sunxi-ss: fix min3() call to match types
  crypto: sunxi-ss: fix dev_dbg() output type
  irqchip: sun4i: fix compilation outside of arch/arm
  arm64: Introduce Allwinner SoC config option

 arch/arm64/Kconfig.platforms              |  5 +++++
 drivers/bus/sunxi-rsb.c                   |  4 ++--
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 14 +++++++-------
 drivers/crypto/sunxi-ss/sun4i-ss-hash.c   |  8 ++++----
 drivers/irqchip/irq-sun4i.c               |  1 -
 5 files changed, 18 insertions(+), 14 deletions(-)

-- 
2.5.1

[RFC PATCH 1/5] drivers: sunxi-rsb: fix error output type

[Andre Przywara]

"len" is actually a size_t in this function here, so properly annotate
the dev_err printf type to allow compilation for 64-bit architectures.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/bus/sunxi-rsb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index 846bc29..7f26bc1d 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -330,7 +330,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
 		cmd = RSB_CMD_RD32;
 		break;
 	default:
-		dev_err(rsb->dev, "Invalid access width: %d\n", len);
+		dev_err(rsb->dev, "Invalid access width: %zd\n", len);
 		return -EINVAL;
 	}
 
@@ -372,7 +372,7 @@ static int sunxi_rsb_write(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
 		cmd = RSB_CMD_WR32;
 		break;
 	default:
-		dev_err(rsb->dev, "Invalid access width: %d\n", len);
+		dev_err(rsb->dev, "Invalid access width: %zd\n", len);
 		return -EINVAL;
 	}
 
-- 
2.5.1

[RFC PATCH 1/5] drivers: sunxi-rsb: fix error output type

[Andre Przywara]

"len" is actually a size_t in this function here, so properly annotate
the dev_err printf type to allow compilation for 64-bit architectures.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/bus/sunxi-rsb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index 846bc29..7f26bc1d 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -330,7 +330,7 @@ static int sunxi_rsb_read(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
 		cmd = RSB_CMD_RD32;
 		break;
 	default:
-		dev_err(rsb->dev, "Invalid access width: %d\n", len);
+		dev_err(rsb->dev, "Invalid access width: %zd\n", len);
 		return -EINVAL;
 	}
 
@@ -372,7 +372,7 @@ static int sunxi_rsb_write(struct sunxi_rsb *rsb, u8 rtaddr, u8 addr,
 		cmd = RSB_CMD_WR32;
 		break;
 	default:
-		dev_err(rsb->dev, "Invalid access width: %d\n", len);
+		dev_err(rsb->dev, "Invalid access width: %zd\n", len);
 		return -EINVAL;
 	}
 
-- 
2.5.1

[RFC PATCH 1/5] drivers: sunxi-rsb: fix error output type

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> "len" is actually a size_t in this function here, so properly annotate
> the dev_err printf type to allow compilation for 64-bit architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: 

Re: [RFC PATCH 1/5] drivers: sunxi-rsb: fix error output type

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> "len" is actually a size_t in this function here, so properly annotate
> the dev_err printf type to allow compilation for 64-bit architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: 

[RFC PATCH 1/5] drivers: sunxi-rsb: fix error output type

[Maxime Ripard]

On Tue, Dec 22, 2015 at 12:27:43PM +0000, Andre Przywara wrote:
> "len" is actually a size_t in this function here, so properly annotate
> the dev_err printf type to allow compilation for 64-bit architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Queued for 4.6, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151227/02507ba5/attachment.sig>

Re: [RFC PATCH 1/5] drivers: sunxi-rsb: fix error output type

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Tue, Dec 22, 2015 at 12:27:43PM +0000, Andre Przywara wrote:
> "len" is actually a size_t in this function here, so properly annotate
> the dev_err printf type to allow compilation for 64-bit architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Queued for 4.6, thanks!

Maxime

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Andre Przywara]

The min3() macro expects all arguments to be of the same type (or
size at least). While two arguments are ints or u32s, one is size_t,
which does not match on 64-bit architectures.
Cast the size_t to u32 to make min3() happy. In this context here the
length should never exceed 32 bits anyway.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 12 ++++++------
 drivers/crypto/sunxi-ss/sun4i-ss-hash.c   |  8 ++++----
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index a19ee12..b3bc7bd 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -79,7 +79,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
 	oi = 0;
 	oo = 0;
 	do {
-		todo = min3(rx_cnt, ileft, (mi.length - oi) / 4);
+		todo = min3(rx_cnt, ileft, (u32)(mi.length - oi) / 4);
 		if (todo > 0) {
 			ileft -= todo;
 			writesl(ss->base + SS_RXFIFO, mi.addr + oi, todo);
@@ -94,7 +94,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
 		rx_cnt = SS_RXFIFO_SPACES(spaces);
 		tx_cnt = SS_TXFIFO_SPACES(spaces);
 
-		todo = min3(tx_cnt, oleft, (mo.length - oo) / 4);
+		todo = min3(tx_cnt, oleft, (u32)(mo.length - oo) / 4);
 		if (todo > 0) {
 			oleft -= todo;
 			readsl(ss->base + SS_TXFIFO, mo.addr + oo, todo);
@@ -216,7 +216,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 			 * todo is the number of consecutive 4byte word that we
 			 * can read from current SG
 			 */
-			todo = min3(rx_cnt, ileft / 4, (mi.length - oi) / 4);
+			todo = min3(rx_cnt, ileft / 4, (u32)(mi.length - oi) / 4);
 			if (todo > 0 && ob == 0) {
 				writesl(ss->base + SS_RXFIFO, mi.addr + oi,
 					todo);
@@ -231,7 +231,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 				 * pass, so it is why we min() with rx_cnt
 				 */
 				todo = min3(rx_cnt * 4 - ob, ileft,
-					    mi.length - oi);
+					    (u32)mi.length - oi);
 				memcpy(buf + ob, mi.addr + oi, todo);
 				ileft -= todo;
 				oi += todo;
@@ -260,7 +260,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 		if (tx_cnt == 0)
 			continue;
 		/* todo in 4bytes word */
-		todo = min3(tx_cnt, oleft / 4, (mo.length - oo) / 4);
+		todo = min3(tx_cnt, oleft / 4, (u32)(mo.length - oo) / 4);
 		if (todo > 0) {
 			readsl(ss->base + SS_TXFIFO, mo.addr + oo, todo);
 			oleft -= todo * 4;
@@ -284,7 +284,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 				 * no more than remaining buffer
 				 * no need to test against oleft
 				 */
-				todo = min(mo.length - oo, obl - obo);
+				todo = min((u32)mo.length - oo, obl - obo);
 				memcpy(mo.addr + oo, bufo + obo, todo);
 				oleft -= todo;
 				obo += todo;
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index ff80314..cd29009 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -245,7 +245,7 @@ int sun4i_hash_update(struct ahash_request *areq)
 			 */
 			while (op->len < 64 && i < end) {
 				/* how many bytes we can read from current SG */
-				in_r = min3(mi.length - in_i, end - i,
+				in_r = min3((u32)mi.length - in_i, end - i,
 					    64 - op->len);
 				memcpy(op->buf + op->len, mi.addr + in_i, in_r);
 				op->len += in_r;
@@ -266,8 +266,8 @@ int sun4i_hash_update(struct ahash_request *areq)
 		}
 		if (mi.length - in_i > 3 && i < end) {
 			/* how many bytes we can read from current SG */
-			in_r = min3(mi.length - in_i, areq->nbytes - i,
-				    ((mi.length - in_i) / 4) * 4);
+			in_r = min3((u32)mi.length - in_i, areq->nbytes - i,
+				    ((u32)(mi.length - in_i) / 4) * 4);
 			/* how many bytes we can write in the device*/
 			todo = min3((u32)(end - i) / 4, rx_cnt, (u32)in_r / 4);
 			writesl(ss->base + SS_RXFIFO, mi.addr + in_i, todo);
@@ -289,7 +289,7 @@ int sun4i_hash_update(struct ahash_request *areq)
 	if ((areq->nbytes - i) < 64) {
 		while (i < areq->nbytes && in_i < mi.length && op->len < 64) {
 			/* how many bytes we can read from current SG */
-			in_r = min3(mi.length - in_i, areq->nbytes - i,
+			in_r = min3((u32)mi.length - in_i, areq->nbytes - i,
 				    64 - op->len);
 			memcpy(op->buf + op->len, mi.addr + in_i, in_r);
 			op->len += in_r;
-- 
2.5.1

[RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Andre Przywara]

The min3() macro expects all arguments to be of the same type (or
size at least). While two arguments are ints or u32s, one is size_t,
which does not match on 64-bit architectures.
Cast the size_t to u32 to make min3() happy. In this context here the
length should never exceed 32 bits anyway.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 12 ++++++------
 drivers/crypto/sunxi-ss/sun4i-ss-hash.c   |  8 ++++----
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index a19ee12..b3bc7bd 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -79,7 +79,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
 	oi = 0;
 	oo = 0;
 	do {
-		todo = min3(rx_cnt, ileft, (mi.length - oi) / 4);
+		todo = min3(rx_cnt, ileft, (u32)(mi.length - oi) / 4);
 		if (todo > 0) {
 			ileft -= todo;
 			writesl(ss->base + SS_RXFIFO, mi.addr + oi, todo);
@@ -94,7 +94,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
 		rx_cnt = SS_RXFIFO_SPACES(spaces);
 		tx_cnt = SS_TXFIFO_SPACES(spaces);
 
-		todo = min3(tx_cnt, oleft, (mo.length - oo) / 4);
+		todo = min3(tx_cnt, oleft, (u32)(mo.length - oo) / 4);
 		if (todo > 0) {
 			oleft -= todo;
 			readsl(ss->base + SS_TXFIFO, mo.addr + oo, todo);
@@ -216,7 +216,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 			 * todo is the number of consecutive 4byte word that we
 			 * can read from current SG
 			 */
-			todo = min3(rx_cnt, ileft / 4, (mi.length - oi) / 4);
+			todo = min3(rx_cnt, ileft / 4, (u32)(mi.length - oi) / 4);
 			if (todo > 0 && ob == 0) {
 				writesl(ss->base + SS_RXFIFO, mi.addr + oi,
 					todo);
@@ -231,7 +231,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 				 * pass, so it is why we min() with rx_cnt
 				 */
 				todo = min3(rx_cnt * 4 - ob, ileft,
-					    mi.length - oi);
+					    (u32)mi.length - oi);
 				memcpy(buf + ob, mi.addr + oi, todo);
 				ileft -= todo;
 				oi += todo;
@@ -260,7 +260,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 		if (tx_cnt == 0)
 			continue;
 		/* todo in 4bytes word */
-		todo = min3(tx_cnt, oleft / 4, (mo.length - oo) / 4);
+		todo = min3(tx_cnt, oleft / 4, (u32)(mo.length - oo) / 4);
 		if (todo > 0) {
 			readsl(ss->base + SS_TXFIFO, mo.addr + oo, todo);
 			oleft -= todo * 4;
@@ -284,7 +284,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 				 * no more than remaining buffer
 				 * no need to test against oleft
 				 */
-				todo = min(mo.length - oo, obl - obo);
+				todo = min((u32)mo.length - oo, obl - obo);
 				memcpy(mo.addr + oo, bufo + obo, todo);
 				oleft -= todo;
 				obo += todo;
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index ff80314..cd29009 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -245,7 +245,7 @@ int sun4i_hash_update(struct ahash_request *areq)
 			 */
 			while (op->len < 64 && i < end) {
 				/* how many bytes we can read from current SG */
-				in_r = min3(mi.length - in_i, end - i,
+				in_r = min3((u32)mi.length - in_i, end - i,
 					    64 - op->len);
 				memcpy(op->buf + op->len, mi.addr + in_i, in_r);
 				op->len += in_r;
@@ -266,8 +266,8 @@ int sun4i_hash_update(struct ahash_request *areq)
 		}
 		if (mi.length - in_i > 3 && i < end) {
 			/* how many bytes we can read from current SG */
-			in_r = min3(mi.length - in_i, areq->nbytes - i,
-				    ((mi.length - in_i) / 4) * 4);
+			in_r = min3((u32)mi.length - in_i, areq->nbytes - i,
+				    ((u32)(mi.length - in_i) / 4) * 4);
 			/* how many bytes we can write in the device*/
 			todo = min3((u32)(end - i) / 4, rx_cnt, (u32)in_r / 4);
 			writesl(ss->base + SS_RXFIFO, mi.addr + in_i, todo);
@@ -289,7 +289,7 @@ int sun4i_hash_update(struct ahash_request *areq)
 	if ((areq->nbytes - i) < 64) {
 		while (i < areq->nbytes && in_i < mi.length && op->len < 64) {
 			/* how many bytes we can read from current SG */
-			in_r = min3(mi.length - in_i, areq->nbytes - i,
+			in_r = min3((u32)mi.length - in_i, areq->nbytes - i,
 				    64 - op->len);
 			memcpy(op->buf + op->len, mi.addr + in_i, in_r);
 			op->len += in_r;
-- 
2.5.1

Re: [RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The min3() macro expects all arguments to be of the same type (or
> size at least). While two arguments are ints or u32s, one is size_t,
> which does not match on 64-bit architectures.
> Cast the size_t to u32 to make min3() happy. In this context here the
> length should never exceed 32 bits anyway.
> 
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>

Looks correct, but a bit ugly. Could we avoid the casts by using
temporary variables to keep the size_t based data?

	Arnd

Re: [RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The min3() macro expects all arguments to be of the same type (or
> size at least). While two arguments are ints or u32s, one is size_t,
> which does not match on 64-bit architectures.
> Cast the size_t to u32 to make min3() happy. In this context here the
> length should never exceed 32 bits anyway.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Looks correct, but a bit ugly. Could we avoid the casts by using
temporary variables to keep the size_t based data?

	Arnd

[RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The min3() macro expects all arguments to be of the same type (or
> size at least). While two arguments are ints or u32s, one is size_t,
> which does not match on 64-bit architectures.
> Cast the size_t to u32 to make min3() happy. In this context here the
> length should never exceed 32 bits anyway.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Looks correct, but a bit ugly. Could we avoid the casts by using
temporary variables to keep the size_t based data?

	Arnd

Re: [RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[André Przywara]

Hi Arnd,
On 12/22/15 22:06, Arnd Bergmann wrote:
> On Tuesday 22 December 2015, Andre Przywara wrote:
>> The min3() macro expects all arguments to be of the same type (or
>> size at least). While two arguments are ints or u32s, one is size_t,
>> which does not match on 64-bit architectures.
>> Cast the size_t to u32 to make min3() happy. In this context here the
>> length should never exceed 32 bits anyway.
>>
>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> 
> Looks correct, but a bit ugly. Could we avoid the casts by using
> temporary variables to keep the size_t based data?

I guess this gets even uglier, but I found a better solution by
promoting the other involved variables to size_t in this function. This
works nicely for most of the cases, I just need two size_t casts now.
Will send an updated version soon.

Cheers,
Andre.

Re: [RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[André Przywara]

Hi Arnd,
On 12/22/15 22:06, Arnd Bergmann wrote:
> On Tuesday 22 December 2015, Andre Przywara wrote:
>> The min3() macro expects all arguments to be of the same type (or
>> size at least). While two arguments are ints or u32s, one is size_t,
>> which does not match on 64-bit architectures.
>> Cast the size_t to u32 to make min3() happy. In this context here the
>> length should never exceed 32 bits anyway.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> Looks correct, but a bit ugly. Could we avoid the casts by using
> temporary variables to keep the size_t based data?

I guess this gets even uglier, but I found a better solution by
promoting the other involved variables to size_t in this function. This
works nicely for most of the cases, I just need two size_t casts now.
Will send an updated version soon.

Cheers,
Andre.

[RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[André Przywara]

Hi Arnd,
On 12/22/15 22:06, Arnd Bergmann wrote:
> On Tuesday 22 December 2015, Andre Przywara wrote:
>> The min3() macro expects all arguments to be of the same type (or
>> size at least). While two arguments are ints or u32s, one is size_t,
>> which does not match on 64-bit architectures.
>> Cast the size_t to u32 to make min3() happy. In this context here the
>> length should never exceed 32 bits anyway.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> Looks correct, but a bit ugly. Could we avoid the casts by using
> temporary variables to keep the size_t based data?

I guess this gets even uglier, but I found a better solution by
promoting the other involved variables to size_t in this function. This
works nicely for most of the cases, I just need two size_t casts now.
Will send an updated version soon.

Cheers,
Andre.

Re: [RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Uwe Kleine-König]

On Tue, Dec 22, 2015 at 12:27:44PM +0000, Andre Przywara wrote:
> The min3() macro expects all arguments to be of the same type (or
> size at least). While two arguments are ints or u32s, one is size_t,
> which does not match on 64-bit architectures.
> Cast the size_t to u32 to make min3() happy. In this context here the
> length should never exceed 32 bits anyway.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 12 ++++++------
>  drivers/crypto/sunxi-ss/sun4i-ss-hash.c   |  8 ++++----
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> index a19ee12..b3bc7bd 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> @@ -79,7 +79,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
>  	oi = 0;
>  	oo = 0;
>  	do {
> -		todo = min3(rx_cnt, ileft, (mi.length - oi) / 4);
> +		todo = min3(rx_cnt, ileft, (u32)(mi.length - oi) / 4);

For this case the min function has a min_t variant to specify the
argument. What about introducing min3_t?

BTW, I don't understand why min3(x, y, z) isn't just defined as

	#define min3(x, y, z) min(min(x, y), z)

but instead as:

	#define min3(x, y, z) min((typeof(x))min(x, y), z)

. I thought min(x, y) has the same type as x anyhow?

Best regards
Uwe


-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[RFC PATCH 2/5] crypto: sunxi-ss: fix min3() call to match types

[Uwe Kleine-König]

On Tue, Dec 22, 2015 at 12:27:44PM +0000, Andre Przywara wrote:
> The min3() macro expects all arguments to be of the same type (or
> size at least). While two arguments are ints or u32s, one is size_t,
> which does not match on 64-bit architectures.
> Cast the size_t to u32 to make min3() happy. In this context here the
> length should never exceed 32 bits anyway.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 12 ++++++------
>  drivers/crypto/sunxi-ss/sun4i-ss-hash.c   |  8 ++++----
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> index a19ee12..b3bc7bd 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> @@ -79,7 +79,7 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
>  	oi = 0;
>  	oo = 0;
>  	do {
> -		todo = min3(rx_cnt, ileft, (mi.length - oi) / 4);
> +		todo = min3(rx_cnt, ileft, (u32)(mi.length - oi) / 4);

For this case the min function has a min_t variant to specify the
argument. What about introducing min3_t?

BTW, I don't understand why min3(x, y, z) isn't just defined as

	#define min3(x, y, z) min(min(x, y), z)

but instead as:

	#define min3(x, y, z) min((typeof(x))min(x, y), z)

. I thought min(x, y) has the same type as x anyhow?

Best regards
Uwe


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Andre Przywara]

The length parameter in this dev_dbg() call is actually a size_t,
so use the proper type to avoid warnings when compiling for 64-bit
architectures.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index b3bc7bd..af2690c 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -251,7 +251,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 		spaces = readl(ss->base + SS_FCSR);
 		rx_cnt = SS_RXFIFO_SPACES(spaces);
 		tx_cnt = SS_TXFIFO_SPACES(spaces);
-		dev_dbg(ss->dev, "%x %u/%u %u/%u cnt=%u %u/%u %u/%u cnt=%u %u %u\n",
+		dev_dbg(ss->dev, "%x %u/%zu %u/%u cnt=%u %u/%zu %u/%u cnt=%u %u %u\n",
 			mode,
 			oi, mi.length, ileft, areq->nbytes, rx_cnt,
 			oo, mo.length, oleft, areq->nbytes, tx_cnt,
-- 
2.5.1

[RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Andre Przywara]

The length parameter in this dev_dbg() call is actually a size_t,
so use the proper type to avoid warnings when compiling for 64-bit
architectures.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index b3bc7bd..af2690c 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -251,7 +251,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
 		spaces = readl(ss->base + SS_FCSR);
 		rx_cnt = SS_RXFIFO_SPACES(spaces);
 		tx_cnt = SS_TXFIFO_SPACES(spaces);
-		dev_dbg(ss->dev, "%x %u/%u %u/%u cnt=%u %u/%u %u/%u cnt=%u %u %u\n",
+		dev_dbg(ss->dev, "%x %u/%zu %u/%u cnt=%u %u/%zu %u/%u cnt=%u %u %u\n",
 			mode,
 			oi, mi.length, ileft, areq->nbytes, rx_cnt,
 			oo, mo.length, oleft, areq->nbytes, tx_cnt,
-- 
2.5.1

Re: [RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>

Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>

Re: [RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

[RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Corentin LABBE]

Le 22/12/2015 13:27, Andre Przywara a écrit :
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> ---
>  drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> index b3bc7bd..af2690c 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> @@ -251,7 +251,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
>  		spaces = readl(ss->base + SS_FCSR);
>  		rx_cnt = SS_RXFIFO_SPACES(spaces);
>  		tx_cnt = SS_TXFIFO_SPACES(spaces);
> -		dev_dbg(ss->dev, "%x %u/%u %u/%u cnt=%u %u/%u %u/%u cnt=%u %u %u\n",
> +		dev_dbg(ss->dev, "%x %u/%zu %u/%u cnt=%u %u/%zu %u/%u cnt=%u %u %u\n",
>  			mode,
>  			oi, mi.length, ileft, areq->nbytes, rx_cnt,
>  			oo, mo.length, oleft, areq->nbytes, tx_cnt,
> 

Acked-by: LABBE Corentin <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

-- 
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

Re: [RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Corentin LABBE]

Le 22/12/2015 13:27, Andre Przywara a écrit :
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> index b3bc7bd..af2690c 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> @@ -251,7 +251,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
>  		spaces = readl(ss->base + SS_FCSR);
>  		rx_cnt = SS_RXFIFO_SPACES(spaces);
>  		tx_cnt = SS_TXFIFO_SPACES(spaces);
> -		dev_dbg(ss->dev, "%x %u/%u %u/%u cnt=%u %u/%u %u/%u cnt=%u %u %u\n",
> +		dev_dbg(ss->dev, "%x %u/%zu %u/%u cnt=%u %u/%zu %u/%u cnt=%u %u %u\n",
>  			mode,
>  			oi, mi.length, ileft, areq->nbytes, rx_cnt,
>  			oo, mo.length, oleft, areq->nbytes, tx_cnt,
> 

Acked-by: LABBE Corentin <clabbe.montjoie@gmail.com>

[RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Corentin LABBE]

Le 22/12/2015 13:27, Andre Przywara a ?crit :
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> index b3bc7bd..af2690c 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> @@ -251,7 +251,7 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
>  		spaces = readl(ss->base + SS_FCSR);
>  		rx_cnt = SS_RXFIFO_SPACES(spaces);
>  		tx_cnt = SS_TXFIFO_SPACES(spaces);
> -		dev_dbg(ss->dev, "%x %u/%u %u/%u cnt=%u %u/%u %u/%u cnt=%u %u %u\n",
> +		dev_dbg(ss->dev, "%x %u/%zu %u/%u cnt=%u %u/%zu %u/%u cnt=%u %u %u\n",
>  			mode,
>  			oi, mi.length, ileft, areq->nbytes, rx_cnt,
>  			oo, mo.length, oleft, areq->nbytes, tx_cnt,
> 

Acked-by: LABBE Corentin <clabbe.montjoie@gmail.com>

Re: [RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Tue, Dec 22, 2015 at 12:27:45PM +0000, Andre Przywara wrote:
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 3/5] crypto: sunxi-ss: fix dev_dbg() output type

[Maxime Ripard]

On Tue, Dec 22, 2015 at 12:27:45PM +0000, Andre Przywara wrote:
> The length parameter in this dev_dbg() call is actually a size_t,
> so use the proper type to avoid warnings when compiling for 64-bit
> architectures.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151227/d5a6521c/attachment.sig>

[RFC PATCH 4/5] irqchip: sun4i: fix compilation outside of arch/arm

[Andre Przywara]

The Allwinner sunxi specific interrupt controller cannot be compiled
for any architecture except arm:

drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
compilation terminated.

It turns out that this header is actually not needed for the driver,
so remove it and allow compilation for other architectures like
arm64.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/irqchip/irq-sun4i.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 0704362..376b280 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -22,7 +22,6 @@
 #include <linux/of_irq.h>
 
 #include <asm/exception.h>
-#include <asm/mach/irq.h>
 
 #define SUN4I_IRQ_VECTOR_REG		0x00
 #define SUN4I_IRQ_PROTECTION_REG	0x08
-- 
2.5.1

[RFC PATCH 4/5] irqchip: sun4i: fix compilation outside of arch/arm

[Andre Przywara]

The Allwinner sunxi specific interrupt controller cannot be compiled
for any architecture except arm:

drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
compilation terminated.

It turns out that this header is actually not needed for the driver,
so remove it and allow compilation for other architectures like
arm64.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/irqchip/irq-sun4i.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 0704362..376b280 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -22,7 +22,6 @@
 #include <linux/of_irq.h>
 
 #include <asm/exception.h>
-#include <asm/mach/irq.h>
 
 #define SUN4I_IRQ_VECTOR_REG		0x00
 #define SUN4I_IRQ_PROTECTION_REG	0x08
-- 
2.5.1

[RFC PATCH 4/5] irqchip: sun4i: fix compilation outside of arch/arm

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The Allwinner sunxi specific interrupt controller cannot be compiled
> for any architecture except arm:
> 
> drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
> compilation terminated.
> 
> It turns out that this header is actually not needed for the driver,
> so remove it and allow compilation for other architectures like
> arm64.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [RFC PATCH 4/5] irqchip: sun4i: fix compilation outside of arch/arm

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> The Allwinner sunxi specific interrupt controller cannot be compiled
> for any architecture except arm:
> 
> drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
> compilation terminated.
> 
> It turns out that this header is actually not needed for the driver,
> so remove it and allow compilation for other architectures like
> arm64.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

[RFC PATCH 4/5] irqchip: sun4i: fix compilation outside of arch/arm

[Maxime Ripard]

Hi,

On Tue, Dec 22, 2015 at 12:27:46PM +0000, Andre Przywara wrote:
> The Allwinner sunxi specific interrupt controller cannot be compiled
> for any architecture except arm:
> 
> drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
> compilation terminated.
> 
> It turns out that this header is actually not needed for the driver,
> so remove it and allow compilation for other architectures like
> arm64.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151227/65bacc72/attachment.sig>

Re: [RFC PATCH 4/5] irqchip: sun4i: fix compilation outside of arch/arm

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

Hi,

On Tue, Dec 22, 2015 at 12:27:46PM +0000, Andre Przywara wrote:
> The Allwinner sunxi specific interrupt controller cannot be compiled
> for any architecture except arm:
> 
> drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
> compilation terminated.
> 
> It turns out that this header is actually not needed for the driver,
> so remove it and allow compilation for other architectures like
> arm64.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Thanks!
Maxime

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Andre Przywara]

To prepare for supporting the Allwinner A64 SoC, introduce a config
option to allow compiling Allwinner (aka. sunxi) specific drivers
for ARM64.
This patch just defines the ARCH_SUNXI symbol to allow Allwinner
specific drivers to be selected during kernel configuration.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/Kconfig.platforms | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4043c35..235e376 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,10 @@
 menu "Platform selection"
 
+config ARCH_SUNXI
+	bool "Allwinner sunxi 64-bit SoC Family"
+	help
+	  This enables support for Allwinner sunxi based SoCs like the A64.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.5.1

[RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Andre Przywara]

To prepare for supporting the Allwinner A64 SoC, introduce a config
option to allow compiling Allwinner (aka. sunxi) specific drivers
for ARM64.
This patch just defines the ARCH_SUNXI symbol to allow Allwinner
specific drivers to be selected during kernel configuration.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/Kconfig.platforms | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4043c35..235e376 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,10 @@
 menu "Platform selection"
 
+config ARCH_SUNXI
+	bool "Allwinner sunxi 64-bit SoC Family"
+	help
+	  This enables support for Allwinner sunxi based SoCs like the A64.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.5.1

[RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> To prepare for supporting the Allwinner A64 SoC, introduce a config
> option to allow compiling Allwinner (aka. sunxi) specific drivers
> for ARM64.
> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> specific drivers to be selected during kernel configuration.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Arnd Bergmann]

On Tuesday 22 December 2015, Andre Przywara wrote:
> To prepare for supporting the Allwinner A64 SoC, introduce a config
> option to allow compiling Allwinner (aka. sunxi) specific drivers
> for ARM64.
> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> specific drivers to be selected during kernel configuration.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

[RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Maxime Ripard]

Hi Andre, Arnd,

On Tue, Dec 22, 2015 at 12:27:47PM +0000, Andre Przywara wrote:
> To prepare for supporting the Allwinner A64 SoC, introduce a config
> option to allow compiling Allwinner (aka. sunxi) specific drivers
> for ARM64.
> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> specific drivers to be selected during kernel configuration.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

I'm ok taking this patch.

I'm not quite sure how the process works though with arm64. Should I
send a PR with this patch to Catalin, or does it go through the usual
arm-soc maintainers?

We should also probably extend the MAINTAINERS entry, shouldn't we?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160104/3fa8d2eb/attachment.sig>

Re: [RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

Hi Andre, Arnd,

On Tue, Dec 22, 2015 at 12:27:47PM +0000, Andre Przywara wrote:
> To prepare for supporting the Allwinner A64 SoC, introduce a config
> option to allow compiling Allwinner (aka. sunxi) specific drivers
> for ARM64.
> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> specific drivers to be selected during kernel configuration.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

I'm ok taking this patch.

I'm not quite sure how the process works though with arm64. Should I
send a PR with this patch to Catalin, or does it go through the usual
arm-soc maintainers?

We should also probably extend the MAINTAINERS entry, shouldn't we?

Thanks,
Maxime

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Arnd Bergmann]

On Monday 04 January 2016 12:26:48 Maxime Ripard wrote:
> Hi Andre, Arnd,
> 
> On Tue, Dec 22, 2015 at 12:27:47PM +0000, Andre Przywara wrote:
> > To prepare for supporting the Allwinner A64 SoC, introduce a config
> > option to allow compiling Allwinner (aka. sunxi) specific drivers
> > for ARM64.
> > This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> > specific drivers to be selected during kernel configuration.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> I'm ok taking this patch.
> 
> I'm not quite sure how the process works though with arm64. Should I
> send a PR with this patch to Catalin, or does it go through the usual
> arm-soc maintainers?

We usually take these through arm-soc. 
 
> We should also probably extend the MAINTAINERS entry, shouldn't we?
> 

A lot of the arm64 changes get sent to arm-soc from random developers that
are not in the MAINTAINERS file at the moment, and I'd like to reduce
that, so please pick up whatever arm64 sunxi changes you see that look ok
and send a separate pull request as you do for arm32. Sending patches
separately is fine too, but I'd like to see them come from you to arm at kernel.org
so I don't need to guess whether we should pick them up or not.

This time around, we have two arm64 branches, one for boot/dts and one
combined for Kconfig and defconfig (MAINTAINERS can also go in there). We
are still experimenting with that model though, and it may change in
the future.

	Arnd

Re: [RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Arnd Bergmann]

On Monday 04 January 2016 12:26:48 Maxime Ripard wrote:
> Hi Andre, Arnd,
> 
> On Tue, Dec 22, 2015 at 12:27:47PM +0000, Andre Przywara wrote:
> > To prepare for supporting the Allwinner A64 SoC, introduce a config
> > option to allow compiling Allwinner (aka. sunxi) specific drivers
> > for ARM64.
> > This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> > specific drivers to be selected during kernel configuration.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> I'm ok taking this patch.
> 
> I'm not quite sure how the process works though with arm64. Should I
> send a PR with this patch to Catalin, or does it go through the usual
> arm-soc maintainers?

We usually take these through arm-soc. 
 
> We should also probably extend the MAINTAINERS entry, shouldn't we?
> 

A lot of the arm64 changes get sent to arm-soc from random developers that
are not in the MAINTAINERS file at the moment, and I'd like to reduce
that, so please pick up whatever arm64 sunxi changes you see that look ok
and send a separate pull request as you do for arm32. Sending patches
separately is fine too, but I'd like to see them come from you to arm@kernel.org
so I don't need to guess whether we should pick them up or not.

This time around, we have two arm64 branches, one for boot/dts and one
combined for Kconfig and defconfig (MAINTAINERS can also go in there). We
are still experimenting with that model though, and it may change in
the future.

	Arnd

[RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Maxime Ripard]

Hi Arnd,

On Mon, Jan 04, 2016 at 01:12:53PM +0100, Arnd Bergmann wrote:
> On Monday 04 January 2016 12:26:48 Maxime Ripard wrote:
> > Hi Andre, Arnd,
> > 
> > On Tue, Dec 22, 2015 at 12:27:47PM +0000, Andre Przywara wrote:
> > > To prepare for supporting the Allwinner A64 SoC, introduce a config
> > > option to allow compiling Allwinner (aka. sunxi) specific drivers
> > > for ARM64.
> > > This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> > > specific drivers to be selected during kernel configuration.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > 
> > I'm ok taking this patch.
> > 
> > I'm not quite sure how the process works though with arm64. Should I
> > send a PR with this patch to Catalin, or does it go through the usual
> > arm-soc maintainers?
> 
> We usually take these through arm-soc. 

Ok.

> > We should also probably extend the MAINTAINERS entry, shouldn't we?
> > 
> 
> A lot of the arm64 changes get sent to arm-soc from random developers that
> are not in the MAINTAINERS file at the moment, and I'd like to reduce
> that, so please pick up whatever arm64 sunxi changes you see that look ok
> and send a separate pull request as you do for arm32. Sending patches
> separately is fine too, but I'd like to see them come from you to arm at kernel.org
> so I don't need to guess whether we should pick them up or not.
> 
> This time around, we have two arm64 branches, one for boot/dts and one
> combined for Kconfig and defconfig (MAINTAINERS can also go in there). We
> are still experimenting with that model though, and it may change in
> the future.

Understood. Thanks a lot!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160106/e8aec8cf/attachment.sig>

Re: [RFC PATCH 5/5] arm64: Introduce Allwinner SoC config option

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Hi Arnd,

On Mon, Jan 04, 2016 at 01:12:53PM +0100, Arnd Bergmann wrote:
> On Monday 04 January 2016 12:26:48 Maxime Ripard wrote:
> > Hi Andre, Arnd,
> > 
> > On Tue, Dec 22, 2015 at 12:27:47PM +0000, Andre Przywara wrote:
> > > To prepare for supporting the Allwinner A64 SoC, introduce a config
> > > option to allow compiling Allwinner (aka. sunxi) specific drivers
> > > for ARM64.
> > > This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> > > specific drivers to be selected during kernel configuration.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > 
> > I'm ok taking this patch.
> > 
> > I'm not quite sure how the process works though with arm64. Should I
> > send a PR with this patch to Catalin, or does it go through the usual
> > arm-soc maintainers?
> 
> We usually take these through arm-soc. 

Ok.

> > We should also probably extend the MAINTAINERS entry, shouldn't we?
> > 
> 
> A lot of the arm64 changes get sent to arm-soc from random developers that
> are not in the MAINTAINERS file at the moment, and I'd like to reduce
> that, so please pick up whatever arm64 sunxi changes you see that look ok
> and send a separate pull request as you do for arm32. Sending patches
> separately is fine too, but I'd like to see them come from you to arm@kernel.org
> so I don't need to guess whether we should pick them up or not.
> 
> This time around, we have two arm64 branches, one for boot/dts and one
> combined for Kconfig and defconfig (MAINTAINERS can also go in there). We
> are still experimenting with that model though, and it may change in
> the future.

Understood. Thanks a lot!
Maxime

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]