[U-Boot] [PATCH 1/2] mmc: use new hwpart API when CONFIG_BLK enabled

[U-Boot] [PATCH 1/2] mmc: use new hwpart API when CONFIG_BLK enabled

[Kever Yang]

When CONFIG_BLK is enabled, the hwpart id is different with legacy
interface, update it to kame driver work with CONFIG_BLK.

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---

 cmd/mmc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index 832eeb0..c0ff49a 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -258,7 +258,11 @@ static int do_mmcrpmb(cmd_tbl_t *cmdtp, int flag,
 		return CMD_RET_FAILURE;
 	}
 	/* Switch to the RPMB partition */
+#ifndef CONFIG_BLK
 	original_part = mmc->block_dev.hwpart;
+#else
+	original_part = mmc_get_blk_desc(mmc)->hwpart;
+#endif
 	if (blk_select_hwpart_devnum(IF_TYPE_MMC, curr_device, MMC_PART_RPMB) !=
 	    0)
 		return CMD_RET_FAILURE;
-- 
1.9.1

[U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Kever Yang]

According to MMC spec, the write_counter is 4-byte length,
use 'int' instead of 'long' type for the 'long' is not 4-byte
in 64 bit CPU.

Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---

 drivers/mmc/rpmb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index 1c6888f..0b6b622 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -67,7 +67,7 @@ struct s_rpmb {
 	unsigned char mac[RPMB_SZ_MAC];
 	unsigned char data[RPMB_SZ_DATA];
 	unsigned char nonce[RPMB_SZ_NONCE];
-	unsigned long write_counter;
+	unsigned int write_counter;
 	unsigned short address;
 	unsigned short block_count;
 	unsigned short result;
-- 
1.9.1

[U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Simon Glass]

On 7 June 2017 at 19:20, Kever Yang <kever.yang@rock-chips.com> wrote:
> According to MMC spec, the write_counter is 4-byte length,
> use 'int' instead of 'long' type for the 'long' is not 4-byte
> in 64 bit CPU.
>
> Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
>
>  drivers/mmc/rpmb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

So should we use uint32_t?

>
> diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
> index 1c6888f..0b6b622 100644
> --- a/drivers/mmc/rpmb.c
> +++ b/drivers/mmc/rpmb.c
> @@ -67,7 +67,7 @@ struct s_rpmb {
>         unsigned char mac[RPMB_SZ_MAC];
>         unsigned char data[RPMB_SZ_DATA];
>         unsigned char nonce[RPMB_SZ_NONCE];
> -       unsigned long write_counter;
> +       unsigned int write_counter;
>         unsigned short address;
>         unsigned short block_count;
>         unsigned short result;
> --
> 1.9.1
>

[U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Kever Yang]

Hi Simon,


On 06/09/2017 08:28 PM, Simon Glass wrote:
> On 7 June 2017 at 19:20, Kever Yang <kever.yang@rock-chips.com> wrote:
>> According to MMC spec, the write_counter is 4-byte length,
>> use 'int' instead of 'long' type for the 'long' is not 4-byte
>> in 64 bit CPU.
>>
>> Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>> ---
>>
>>   drivers/mmc/rpmb.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
> So should we use uint32_t?

Yes, we can use uint32_t, I use 'unsigned int' just for the same format 
with other
members in the structure which using unsigned char/short.

Is there a doc for which kind of data format prefer to use first in U-Boot?
unsigned int, uint32_t, u32;

Thanks,
- Kever
>> diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
>> index 1c6888f..0b6b622 100644
>> --- a/drivers/mmc/rpmb.c
>> +++ b/drivers/mmc/rpmb.c
>> @@ -67,7 +67,7 @@ struct s_rpmb {
>>          unsigned char mac[RPMB_SZ_MAC];
>>          unsigned char data[RPMB_SZ_DATA];
>>          unsigned char nonce[RPMB_SZ_NONCE];
>> -       unsigned long write_counter;
>> +       unsigned int write_counter;
>>          unsigned short address;
>>          unsigned short block_count;
>>          unsigned short result;
>> --
>> 1.9.1
>>

[U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Simon Glass]

On 12 June 2017 at 20:11, Kever Yang <kever.yang@rock-chips.com> wrote:
> Hi Simon,
>
>
> On 06/09/2017 08:28 PM, Simon Glass wrote:
>>
>> On 7 June 2017 at 19:20, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>
>>> According to MMC spec, the write_counter is 4-byte length,
>>> use 'int' instead of 'long' type for the 'long' is not 4-byte
>>> in 64 bit CPU.
>>>
>>> Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>> ---
>>>
>>>   drivers/mmc/rpmb.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> So should we use uint32_t?
>
>
> Yes, we can use uint32_t, I use 'unsigned int' just for the same format with
> other
> members in the structure which using unsigned char/short.
>
> Is there a doc for which kind of data format prefer to use first in U-Boot?
> unsigned int, uint32_t, u32;

Reviewed-by: Simon Glass <sjg@chromium.org>

Well I am mostly wondering about what happens on a 64-bit machine
where this would be 64-bits long. There is also u32 which is shorter.

>
> Thanks,
> - Kever
>
>>> diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
>>> index 1c6888f..0b6b622 100644
>>> --- a/drivers/mmc/rpmb.c
>>> +++ b/drivers/mmc/rpmb.c
>>> @@ -67,7 +67,7 @@ struct s_rpmb {
>>>          unsigned char mac[RPMB_SZ_MAC];
>>>          unsigned char data[RPMB_SZ_DATA];
>>>          unsigned char nonce[RPMB_SZ_NONCE];
>>> -       unsigned long write_counter;
>>> +       unsigned int write_counter;
>>>          unsigned short address;
>>>          unsigned short block_count;
>>>          unsigned short result;
>>> --
>>> 1.9.1
>>>
>
>

[U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Lothar Waßmann]

Hi,

On Tue, 13 Jun 2017 10:11:17 +0800 Kever Yang wrote:
> Hi Simon,
> 
> 
> On 06/09/2017 08:28 PM, Simon Glass wrote:
> > On 7 June 2017 at 19:20, Kever Yang <kever.yang@rock-chips.com> wrote:
> >> According to MMC spec, the write_counter is 4-byte length,
> >> use 'int' instead of 'long' type for the 'long' is not 4-byte
> >> in 64 bit CPU.
> >>
> >> Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
> >> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> >> ---
> >>
> >>   drivers/mmc/rpmb.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > So should we use uint32_t?
> 
> Yes, we can use uint32_t, I use 'unsigned int' just for the same format 
> with other
> members in the structure which using unsigned char/short.
> 
> Is there a doc for which kind of data format prefer to use first in U-Boot?
> unsigned int, uint32_t, u32;
> 
uint32_t is guaranteed to be of size 32bit according to the C spec.
'[unsigned] int' is only guaranteed to be at least 32bit but can be
larger on some machine.
A good overview of the C data types and their properties can be found
at: https://en.wikipedia.org/wiki/C_data_types


Lothar Waßmann

[U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Jaehoon Chung]

On 06/08/2017 10:20 AM, Kever Yang wrote:
> According to MMC spec, the write_counter is 4-byte length,
> use 'int' instead of 'long' type for the 'long' is not 4-byte
> in 64 bit CPU.
> 
> Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung


> ---
> 
>  drivers/mmc/rpmb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
> index 1c6888f..0b6b622 100644
> --- a/drivers/mmc/rpmb.c
> +++ b/drivers/mmc/rpmb.c
> @@ -67,7 +67,7 @@ struct s_rpmb {
>  	unsigned char mac[RPMB_SZ_MAC];
>  	unsigned char data[RPMB_SZ_DATA];
>  	unsigned char nonce[RPMB_SZ_NONCE];
> -	unsigned long write_counter;
> +	unsigned int write_counter;
>  	unsigned short address;
>  	unsigned short block_count;
>  	unsigned short result;
> 

[U-Boot] [PATCH 1/2] mmc: use new hwpart API when CONFIG_BLK enabled

[Simon Glass]

On 7 June 2017 at 19:20, Kever Yang <kever.yang@rock-chips.com> wrote:
> When CONFIG_BLK is enabled, the hwpart id is different with legacy
> interface, update it to kame driver work with CONFIG_BLK.
>
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
>
>  cmd/mmc.c | 4 ++++
>  1 file changed, 4 insertions(+)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

nit (for future) I think it is best to put the driver-model code
first, so change #iifndef to #ifdef.

> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 832eeb0..c0ff49a 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -258,7 +258,11 @@ static int do_mmcrpmb(cmd_tbl_t *cmdtp, int flag,
>                 return CMD_RET_FAILURE;
>         }
>         /* Switch to the RPMB partition */
> +#ifndef CONFIG_BLK
>         original_part = mmc->block_dev.hwpart;
> +#else
> +       original_part = mmc_get_blk_desc(mmc)->hwpart;
> +#endif
>         if (blk_select_hwpart_devnum(IF_TYPE_MMC, curr_device, MMC_PART_RPMB) !=
>             0)
>                 return CMD_RET_FAILURE;
> --
> 1.9.1
>

[U-Boot] [PATCH 1/2] mmc: use new hwpart API when CONFIG_BLK enabled

[Jaehoon Chung]

On 06/08/2017 10:20 AM, Kever Yang wrote:
> When CONFIG_BLK is enabled, the hwpart id is different with legacy
> interface, update it to kame driver work with CONFIG_BLK.
> 
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> ---
> 
>  cmd/mmc.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 832eeb0..c0ff49a 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -258,7 +258,11 @@ static int do_mmcrpmb(cmd_tbl_t *cmdtp, int flag,
>  		return CMD_RET_FAILURE;
>  	}
>  	/* Switch to the RPMB partition */
> +#ifndef CONFIG_BLK
>  	original_part = mmc->block_dev.hwpart;
> +#else
> +	original_part = mmc_get_blk_desc(mmc)->hwpart;
> +#endif
>  	if (blk_select_hwpart_devnum(IF_TYPE_MMC, curr_device, MMC_PART_RPMB) !=
>  	    0)
>  		return CMD_RET_FAILURE;
>