[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Eric Nelson]

While trying to configure Nitrogen6X boards to use Android Fastboot,
I found a number of places where the implementation doesn't appear
to match the latest host tools on AOSP.

Eric Nelson (3):
  usb: gadget: fastboot: add max-download-size variable
  usb: gadget: fastboot: explicitly set radix of maximum download size
  usb: gadget: fastboot: terminate commands with NULL

 drivers/usb/gadget/f_fastboot.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
1.9.1

[U-Boot] [PATCH 1/3] usb: gadget: fastboot: add max-download-size variable

[Eric Nelson]

Current Android Fastboot seems to use 'max-download-size' instead
of 'downloadsize' variable to indicate the maximum size of sparse
segments.

See function get_target_sparse_limit() in file fastboot/fastboot.c
in the AOSP:
	 https://android.googlesource.com/platform/system/core/+/master

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 drivers/usb/gadget/f_fastboot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 38c0965..f970f89 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
 		strncat(response, FASTBOOT_VERSION, chars_left);
 	} else if (!strcmp_l1("bootloader-version", cmd)) {
 		strncat(response, U_BOOT_VERSION, chars_left);
-	} else if (!strcmp_l1("downloadsize", cmd)) {
+	} else if (!strcmp_l1("downloadsize", cmd) ||
+		!strcmp_l1("max-download-size", cmd)) {
 		char str_num[12];
 
 		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
-- 
1.9.1

[U-Boot] [PATCH 2/3] usb: gadget: fastboot: explicitly set radix of maximum download size

[Eric Nelson]

The processing of the max-download-size variable requires a
radix specifier, or the fastboot host tool will interpret
it as an octal number.

See function get_target_sparse_limit() in file fastboot/fastboot.c
in the AOSP:
        https://android.googlesource.com/platform/system/core/+/master

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 drivers/usb/gadget/f_fastboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index f970f89..86700f5 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -355,7 +355,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
 		!strcmp_l1("max-download-size", cmd)) {
 		char str_num[12];
 
-		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
+		sprintf(str_num, "0x%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
 		strncat(response, str_num, chars_left);
 	} else if (!strcmp_l1("serialno", cmd)) {
 		s = getenv("serial#");
-- 
1.9.1

[U-Boot] [PATCH 3/3] usb: gadget: fastboot: terminate commands with NULL

[Eric Nelson]

Without NULL termination, various commands will read past the
end of input. In particular, this was noticed with error()
calls in cb_getvar and simple_strtoul() in cb_download.

Since the download callback happens elsewhere, the 4k buffer
should always be sufficient to handle command arguments.

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 drivers/usb/gadget/f_fastboot.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 86700f5..0950ea8 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -542,6 +542,13 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
 		error("unknown command: %s\n", cmdbuf);
 		fastboot_tx_write_str("FAILunknown command");
 	} else {
+		if (req->actual < req->length) {
+			u8 *buf = (u8 *)req->buf;
+			buf[req->actual] = 0;
+			func_cb(ep, req);
+		} else {
+			error("buffer overflow\n");
+		}
 		func_cb(ep, req);
 	}
 
-- 
1.9.1

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
> While trying to configure Nitrogen6X boards to use Android Fastboot,
> I found a number of places where the implementation doesn't appear
> to match the latest host tools on AOSP.
> 
> Eric Nelson (3):
>   usb: gadget: fastboot: add max-download-size variable
>   usb: gadget: fastboot: explicitly set radix of maximum download size
>   usb: gadget: fastboot: terminate commands with NULL

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Eric Nelson]

Hi Marek,

On 09/30/2014 12:37 PM, Marek Vasut wrote:
> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
>> While trying to configure Nitrogen6X boards to use Android Fastboot,
>> I found a number of places where the implementation doesn't appear
>> to match the latest host tools on AOSP.
>>
>> Eric Nelson (3):
>>   usb: gadget: fastboot: add max-download-size variable
>>   usb: gadget: fastboot: explicitly set radix of maximum download size
>>   usb: gadget: fastboot: terminate commands with NULL
> 
> Just to make sure, are those fixes for 2014.10 or new stuff for next ?
> 

These patches are against master, but should apply against usb/next and
dfu/next and "next" is fine for us.

I just thought I'd forward patches for what I've seen so far as I'm
trying to understand how the parts fit together.

The current dependencies on PART_EFI and a fixed MMC device don't fit
our needs very well, since we have our boot loader in SPI-NOR and
support a variety of MMC, eMMC, and SATA drives for booting Android
and structure in fb_mmc.c and aboot.c seems to require some compile-time
decisions.

Regards,


Eric

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson wrote:
> Hi Marek,
> 
> On 09/30/2014 12:37 PM, Marek Vasut wrote:
> > On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
> >> While trying to configure Nitrogen6X boards to use Android Fastboot,
> >> I found a number of places where the implementation doesn't appear
> >> to match the latest host tools on AOSP.
> >> 
> >> Eric Nelson (3):
> >>   usb: gadget: fastboot: add max-download-size variable
> >>   usb: gadget: fastboot: explicitly set radix of maximum download size
> >>   usb: gadget: fastboot: terminate commands with NULL
> > 
> > Just to make sure, are those fixes for 2014.10 or new stuff for next ?
> 
> These patches are against master, but should apply against usb/next and
> dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Eric Nelson]

Hi Marek,

On 09/30/2014 04:59 PM, Marek Vasut wrote:
> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson wrote:
>> Hi Marek,
>>
>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
>>>> While trying to configure Nitrogen6X boards to use Android Fastboot,
>>>> I found a number of places where the implementation doesn't appear
>>>> to match the latest host tools on AOSP.
>>>>
>>>> Eric Nelson (3):
>>>>   usb: gadget: fastboot: add max-download-size variable
>>>>   usb: gadget: fastboot: explicitly set radix of maximum download size
>>>>   usb: gadget: fastboot: terminate commands with NULL
>>>
>>> Just to make sure, are those fixes for 2014.10 or new stuff for next ?
>>
>> These patches are against master, but should apply against usb/next and
>> dfu/next and "next" is fine for us.
> 
> 3/3 looks like a bugfix though. Is that a bugfix ?
> 

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads
-- the missing radix caused my host to think that the 0x07000000
size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
-- the lack of termination showed up as a request to download
a **huge** image when I tried to send u-boot.imx. I think I got
lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches
or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on
an MMC device, but I don't have anything configured to use EFI
partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx"
and program SPI-NOR and also be able to boot a kernel and RAM disk
using "fastboot boot uImage uramdisk.img", but neither of them seems
very close. The first needs some more structure, and the latter seemed
to decide its' own address for the kernel and simply ignore the
RAM disk.

I have the sense that this code is pretty much a work in progress,
but I'd like to hear otherwise from those who have used it.

Regards,


Eric

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson wrote:
> Hi Marek,
> 
> On 09/30/2014 04:59 PM, Marek Vasut wrote:
> > On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson wrote:
> >> Hi Marek,
> >> 
> >> On 09/30/2014 12:37 PM, Marek Vasut wrote:
> >>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
> >>>> While trying to configure Nitrogen6X boards to use Android Fastboot,
> >>>> I found a number of places where the implementation doesn't appear
> >>>> to match the latest host tools on AOSP.
> >>>> 
> >>>> Eric Nelson (3):
> >>>>   usb: gadget: fastboot: add max-download-size variable
> >>>>   usb: gadget: fastboot: explicitly set radix of maximum download size
> >>>>   usb: gadget: fastboot: terminate commands with NULL
> >>> 
> >>> Just to make sure, are those fixes for 2014.10 or new stuff for next ?
> >> 
> >> These patches are against master, but should apply against usb/next and
> >> dfu/next and "next" is fine for us.
> > 
> > 3/3 looks like a bugfix though. Is that a bugfix ?
> 
> I wasn't able to get fastboot to do much of anything without all three.
> 
> -- lack of max-download-size simply stopped downloads
> -- the missing radix caused my host to think that the 0x07000000
> size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
> -- the lack of termination showed up as a request to download
> a **huge** image when I tried to send u-boot.imx. I think I got
> lucky that the next characters in the buffer looked like hex digits.
> 
> I suspect that others are either holding on to some local patches
> or are perhaps using old versions of the Fastboot host program.
> 
> After applying all three, I was able to configure for flashing on
> an MMC device, but I don't have anything configured to use EFI
> partitions, so there's no immediate route to usage for us.
> 
> I'd really like to be able to "fastboot flash bootloader u-boot.imx"
> and program SPI-NOR and also be able to boot a kernel and RAM disk
> using "fastboot boot uImage uramdisk.img", but neither of them seems
> very close. The first needs some more structure, and the latter seemed
> to decide its' own address for the kernel and simply ignore the
> RAM disk.
> 
> I have the sense that this code is pretty much a work in progress,
> but I'd like to hear otherwise from those who have used it.

OK, so let's wait for the others' opinions.

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] usb: gadget: fastboot: add max-download-size variable

[Steve Rae]

On 14-09-30 12:05 PM, Eric Nelson wrote:
> Current Android Fastboot seems to use 'max-download-size' instead
> of 'downloadsize' variable to indicate the maximum size of sparse
> segments.
>
> See function get_target_sparse_limit() in file fastboot/fastboot.c
> in the AOSP:
> 	 https://android.googlesource.com/platform/system/core/+/master
>
> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> ---
>   drivers/usb/gadget/f_fastboot.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> index 38c0965..f970f89 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
>   		strncat(response, FASTBOOT_VERSION, chars_left);
>   	} else if (!strcmp_l1("bootloader-version", cmd)) {
>   		strncat(response, U_BOOT_VERSION, chars_left);
> -	} else if (!strcmp_l1("downloadsize", cmd)) {
> +	} else if (!strcmp_l1("downloadsize", cmd) ||
> +		!strcmp_l1("max-download-size", cmd)) {
>   		char str_num[12];
>
>   		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
>
(the host version of fastboot that I'm using requires this change!)
Tested-by: Steve Rae <srae@broadcom.com>

[U-Boot] [PATCH 2/3] usb: gadget: fastboot: explicitly set radix of maximum download size

[Steve Rae]

On 14-09-30 12:05 PM, Eric Nelson wrote:
> The processing of the max-download-size variable requires a
> radix specifier, or the fastboot host tool will interpret
> it as an octal number.
>
> See function get_target_sparse_limit() in file fastboot/fastboot.c
> in the AOSP:
>          https://android.googlesource.com/platform/system/core/+/master
>
> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> ---
>   drivers/usb/gadget/f_fastboot.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> index f970f89..86700f5 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -355,7 +355,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
>   		!strcmp_l1("max-download-size", cmd)) {
>   		char str_num[12];
>
> -		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
> +		sprintf(str_num, "0x%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
>   		strncat(response, str_num, chars_left);
>   	} else if (!strcmp_l1("serialno", cmd)) {
>   		s = getenv("serial#");
>
(the host version of fastboot that I'm using requires this change!)
Tested-by: Steve Rae <srae@broadcom.com>

[U-Boot] [PATCH 3/3] usb: gadget: fastboot: terminate commands with NULL

[Steve Rae]

On 14-09-30 12:05 PM, Eric Nelson wrote:
> Without NULL termination, various commands will read past the
> end of input. In particular, this was noticed with error()
> calls in cb_getvar and simple_strtoul() in cb_download.
>
> Since the download callback happens elsewhere, the 4k buffer
> should always be sufficient to handle command arguments.
>
> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> ---
>   drivers/usb/gadget/f_fastboot.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> index 86700f5..0950ea8 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -542,6 +542,13 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
>   		error("unknown command: %s\n", cmdbuf);
>   		fastboot_tx_write_str("FAILunknown command");
>   	} else {
> +		if (req->actual < req->length) {
> +			u8 *buf = (u8 *)req->buf;
> +			buf[req->actual] = 0;
> +			func_cb(ep, req);
> +		} else {
> +			error("buffer overflow\n");
                         fastboot_tx_write_str("FAILbuffer overflow");
ADD this line
> +		}
>   		func_cb(ep, req);
AND delete this line (otherwise the func_cb() is called twice!!!)
>   	}
>
>
I have not experienced this issue, however, if it is to be accepted, 
then please update these two lines.... Afterwards:
Tested-by: Steve Rae <srae@broadcom.com>

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Steve Rae]

On 14-10-01 05:13 AM, Marek Vasut wrote:
> On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson wrote:
>> Hi Marek,
>>
>> On 09/30/2014 04:59 PM, Marek Vasut wrote:
>>> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson wrote:
>>>> Hi Marek,
>>>>
>>>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
>>>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
>>>>>> While trying to configure Nitrogen6X boards to use Android Fastboot,
>>>>>> I found a number of places where the implementation doesn't appear
>>>>>> to match the latest host tools on AOSP.
>>>>>>
>>>>>> Eric Nelson (3):
>>>>>>    usb: gadget: fastboot: add max-download-size variable
>>>>>>    usb: gadget: fastboot: explicitly set radix of maximum download size
>>>>>>    usb: gadget: fastboot: terminate commands with NULL
>>>>>
>>>>> Just to make sure, are those fixes for 2014.10 or new stuff for next ?
>>>>
>>>> These patches are against master, but should apply against usb/next and
>>>> dfu/next and "next" is fine for us.
>>>
>>> 3/3 looks like a bugfix though. Is that a bugfix ?
>>
>> I wasn't able to get fastboot to do much of anything without all three.
>>
>> -- lack of max-download-size simply stopped downloads
>> -- the missing radix caused my host to think that the 0x07000000
>> size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
>> -- the lack of termination showed up as a request to download
>> a **huge** image when I tried to send u-boot.imx. I think I got
>> lucky that the next characters in the buffer looked like hex digits.
>>
>> I suspect that others are either holding on to some local patches
>> or are perhaps using old versions of the Fastboot host program.
>>
>> After applying all three, I was able to configure for flashing on
>> an MMC device, but I don't have anything configured to use EFI
>> partitions, so there's no immediate route to usage for us.
>>
>> I'd really like to be able to "fastboot flash bootloader u-boot.imx"
>> and program SPI-NOR and also be able to boot a kernel and RAM disk
>> using "fastboot boot uImage uramdisk.img", but neither of them seems
>> very close. The first needs some more structure, and the latter seemed
>> to decide its' own address for the kernel and simply ignore the
>> RAM disk.
>>
>> I have the sense that this code is pretty much a work in progress,
>> but I'd like to hear otherwise from those who have used it.
>
> OK, so let's wait for the others' opinions.
>
> Best regards,
> Marek Vasut
>

I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3 
because I don't think that it can actually occur on my boards....)
Thanks, Steve

[U-Boot] [PATCH 3/3] usb: gadget: fastboot: terminate commands with NULL

[Eric Nelson]

Thanks Steve,

On 10/01/2014 01:40 PM, Steve Rae wrote:
> 
> 
> On 14-09-30 12:05 PM, Eric Nelson wrote:
>> Without NULL termination, various commands will read past the
>> end of input. In particular, this was noticed with error()
>> calls in cb_getvar and simple_strtoul() in cb_download.
>>
>> Since the download callback happens elsewhere, the 4k buffer
>> should always be sufficient to handle command arguments.
>>
>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
>> ---
>>   drivers/usb/gadget/f_fastboot.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/f_fastboot.c
>> b/drivers/usb/gadget/f_fastboot.c
>> index 86700f5..0950ea8 100644
>> --- a/drivers/usb/gadget/f_fastboot.c
>> +++ b/drivers/usb/gadget/f_fastboot.c
>> @@ -542,6 +542,13 @@ static void rx_handler_command(struct usb_ep *ep,
>> struct usb_request *req)
>>           error("unknown command: %s\n", cmdbuf);
>>           fastboot_tx_write_str("FAILunknown command");
>>       } else {
>> +        if (req->actual < req->length) {
>> +            u8 *buf = (u8 *)req->buf;
>> +            buf[req->actual] = 0;
>> +            func_cb(ep, req);
>> +        } else {
>> +            error("buffer overflow\n");
>                         fastboot_tx_write_str("FAILbuffer overflow");
> ADD this line
>> +        }
>>           func_cb(ep, req);
> AND delete this line (otherwise the func_cb() is called twice!!!)
>>       }
>>

Ouch. It appears I pooched the patch when trying to make checkpatch
happy with the extra(neous) braces.

I'll forward V2 shortly.

Regards,


Eric

[U-Boot] [PATCH V2 3/3] usb: gadget: fastboot: terminate commands with NULL

[Eric Nelson]

Without NULL termination, various commands will read past the
end of input. In particular, this was noticed with error()
calls in cb_getvar and simple_strtoul() in cb_download.

Since the download callback happens elsewhere, the 4k buffer
should always be sufficient to handle command arguments.

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
 V2 adds response to host in the event of failure and removes
    double call-back via func_cb as pointed out by Steve Rae.
 drivers/usb/gadget/f_fastboot.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 86700f5..0c91d3c 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -542,7 +542,14 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
 		error("unknown command: %s\n", cmdbuf);
 		fastboot_tx_write_str("FAILunknown command");
 	} else {
-		func_cb(ep, req);
+		if (req->actual < req->length) {
+			u8 *buf = (u8 *)req->buf;
+			buf[req->actual] = 0;
+			func_cb(ep, req);
+		} else {
+			error("buffer overflow\n");
+			fastboot_tx_write_str("FAILbuffer overflow"); 
+		}
 	}
 
 	if (req->status == 0) {
-- 
1.9.1

[U-Boot] [PATCH 1/3] usb: gadget: fastboot: add max-download-size variable

[Marek Vasut]

On Wednesday, October 01, 2014 at 10:38:57 PM, Steve Rae wrote:
> On 14-09-30 12:05 PM, Eric Nelson wrote:
> > Current Android Fastboot seems to use 'max-download-size' instead
> > of 'downloadsize' variable to indicate the maximum size of sparse
> > segments.
> > 
> > See function get_target_sparse_limit() in file fastboot/fastboot.c
> > 
> > in the AOSP:
> > 	 https://android.googlesource.com/platform/system/core/+/master
> > 
> > Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
> > ---
> > 
> >   drivers/usb/gadget/f_fastboot.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/gadget/f_fastboot.c
> > b/drivers/usb/gadget/f_fastboot.c index 38c0965..f970f89 100644
> > --- a/drivers/usb/gadget/f_fastboot.c
> > +++ b/drivers/usb/gadget/f_fastboot.c
> > @@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct
> > usb_request *req)
> > 
> >   		strncat(response, FASTBOOT_VERSION, chars_left);
> >   	
> >   	} else if (!strcmp_l1("bootloader-version", cmd)) {
> >   	
> >   		strncat(response, U_BOOT_VERSION, chars_left);
> > 
> > -	} else if (!strcmp_l1("downloadsize", cmd)) {
> > +	} else if (!strcmp_l1("downloadsize", cmd) ||
> > +		!strcmp_l1("max-download-size", cmd)) {
> > 
> >   		char str_num[12];
> >   		
> >   		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
> 
> (the host version of fastboot that I'm using requires this change!)
> Tested-by: Steve Rae <srae@broadcom.com>

Wow, so the previous code that was accepted was broken ? Did you know about that 
breakage ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/3] usb: gadget: fastboot: add max-download-size variable

[Steve Rae]

On 14-10-01 07:37 PM, Marek Vasut wrote:
> On Wednesday, October 01, 2014 at 10:38:57 PM, Steve Rae wrote:
>> On 14-09-30 12:05 PM, Eric Nelson wrote:
>>> Current Android Fastboot seems to use 'max-download-size' instead
>>> of 'downloadsize' variable to indicate the maximum size of sparse
>>> segments.
>>>
>>> See function get_target_sparse_limit() in file fastboot/fastboot.c
>>>
>>> in the AOSP:
>>> 	 https://android.googlesource.com/platform/system/core/+/master
>>>
>>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
>>> ---
>>>
>>>    drivers/usb/gadget/f_fastboot.c | 3 ++-
>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/f_fastboot.c
>>> b/drivers/usb/gadget/f_fastboot.c index 38c0965..f970f89 100644
>>> --- a/drivers/usb/gadget/f_fastboot.c
>>> +++ b/drivers/usb/gadget/f_fastboot.c
>>> @@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct
>>> usb_request *req)
>>>
>>>    		strncat(response, FASTBOOT_VERSION, chars_left);
>>>    	
>>>    	} else if (!strcmp_l1("bootloader-version", cmd)) {
>>>    	
>>>    		strncat(response, U_BOOT_VERSION, chars_left);
>>>
>>> -	} else if (!strcmp_l1("downloadsize", cmd)) {
>>> +	} else if (!strcmp_l1("downloadsize", cmd) ||
>>> +		!strcmp_l1("max-download-size", cmd)) {
>>>
>>>    		char str_num[12];
>>>    		
>>>    		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
>>
>> (the host version of fastboot that I'm using requires this change!)
>> Tested-by: Steve Rae <srae@broadcom.com>
>
> Wow, so the previous code that was accepted was broken ? Did you know about that
> breakage ?

It wasn't broken; let me try to clarify....
It seems that different host versions of "fastboot" use either 
"downloadsize" or "max-download-size" (I am not certain about the 
history...) The original code has "downloadsize", and with the host 
version of fastboot that I am testing with (which uses 
"max-download-size"), this reports as "unknown variable" - however, the 
download still occurs successfully (there must be some default size that 
it is using...) Therefore, it isn't broken (for me). However, Eric has 
reported that for his host version of fastboot, that it stops!
So his changes (1/3 and 2/3) are required for his host version of 
fastboot (and they work properly with my version)
Hope that clarifies it,
Thanks, Steve
PS. none of these host versions of fastboot have any version 
identification -- so it is really difficult to determine what "host 
version" we are actually talking about....

>
> Best regards,
> Marek Vasut
>

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Wednesday, October 01, 2014 at 10:44:46 PM, Steve Rae wrote:
> On 14-10-01 05:13 AM, Marek Vasut wrote:
> > On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson wrote:
> >> Hi Marek,
> >> 
> >> On 09/30/2014 04:59 PM, Marek Vasut wrote:
> >>> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson wrote:
> >>>> Hi Marek,
> >>>> 
> >>>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
> >>>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson wrote:
> >>>>>> While trying to configure Nitrogen6X boards to use Android Fastboot,
> >>>>>> I found a number of places where the implementation doesn't appear
> >>>>>> to match the latest host tools on AOSP.
> >>>>>> 
> >>>>>> Eric Nelson (3):
> >>>>>>    usb: gadget: fastboot: add max-download-size variable
> >>>>>>    usb: gadget: fastboot: explicitly set radix of maximum download
> >>>>>>    size usb: gadget: fastboot: terminate commands with NULL
> >>>>> 
> >>>>> Just to make sure, are those fixes for 2014.10 or new stuff for next
> >>>>> ?
> >>>> 
> >>>> These patches are against master, but should apply against usb/next
> >>>> and dfu/next and "next" is fine for us.
> >>> 
> >>> 3/3 looks like a bugfix though. Is that a bugfix ?
> >> 
> >> I wasn't able to get fastboot to do much of anything without all three.
> >> 
> >> -- lack of max-download-size simply stopped downloads
> >> -- the missing radix caused my host to think that the 0x07000000
> >> size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
> >> -- the lack of termination showed up as a request to download
> >> a **huge** image when I tried to send u-boot.imx. I think I got
> >> lucky that the next characters in the buffer looked like hex digits.
> >> 
> >> I suspect that others are either holding on to some local patches
> >> or are perhaps using old versions of the Fastboot host program.
> >> 
> >> After applying all three, I was able to configure for flashing on
> >> an MMC device, but I don't have anything configured to use EFI
> >> partitions, so there's no immediate route to usage for us.
> >> 
> >> I'd really like to be able to "fastboot flash bootloader u-boot.imx"
> >> and program SPI-NOR and also be able to boot a kernel and RAM disk
> >> using "fastboot boot uImage uramdisk.img", but neither of them seems
> >> very close. The first needs some more structure, and the latter seemed
> >> to decide its' own address for the kernel and simply ignore the
> >> RAM disk.
> >> 
> >> I have the sense that this code is pretty much a work in progress,
> >> but I'd like to hear otherwise from those who have used it.
> > 
> > OK, so let's wait for the others' opinions.
> > 
> > Best regards,
> > Marek Vasut
> 
> I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3
> because I don't think that it can actually occur on my boards....)
> Thanks, Steve

OK, Lukasz, do you want to send me a PR with those two ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Lukasz Majewski]

Hi Marek,

> On Wednesday, October 01, 2014 at 10:44:46 PM, Steve Rae wrote:
> > On 14-10-01 05:13 AM, Marek Vasut wrote:
> > > On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson wrote:
> > >> Hi Marek,
> > >> 
> > >> On 09/30/2014 04:59 PM, Marek Vasut wrote:
> > >>> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson
> > >>> wrote:
> > >>>> Hi Marek,
> > >>>> 
> > >>>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
> > >>>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson
> > >>>>> wrote:
> > >>>>>> While trying to configure Nitrogen6X boards to use Android
> > >>>>>> Fastboot, I found a number of places where the
> > >>>>>> implementation doesn't appear to match the latest host tools
> > >>>>>> on AOSP.
> > >>>>>> 
> > >>>>>> Eric Nelson (3):
> > >>>>>>    usb: gadget: fastboot: add max-download-size variable
> > >>>>>>    usb: gadget: fastboot: explicitly set radix of maximum
> > >>>>>> download size usb: gadget: fastboot: terminate commands with
> > >>>>>> NULL
> > >>>>> 
> > >>>>> Just to make sure, are those fixes for 2014.10 or new stuff
> > >>>>> for next ?
> > >>>> 
> > >>>> These patches are against master, but should apply against
> > >>>> usb/next and dfu/next and "next" is fine for us.
> > >>> 
> > >>> 3/3 looks like a bugfix though. Is that a bugfix ?
> > >> 
> > >> I wasn't able to get fastboot to do much of anything without all
> > >> three.
> > >> 
> > >> -- lack of max-download-size simply stopped downloads
> > >> -- the missing radix caused my host to think that the 0x07000000
> > >> size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
> > >> -- the lack of termination showed up as a request to download
> > >> a **huge** image when I tried to send u-boot.imx. I think I got
> > >> lucky that the next characters in the buffer looked like hex
> > >> digits.
> > >> 
> > >> I suspect that others are either holding on to some local patches
> > >> or are perhaps using old versions of the Fastboot host program.
> > >> 
> > >> After applying all three, I was able to configure for flashing on
> > >> an MMC device, but I don't have anything configured to use EFI
> > >> partitions, so there's no immediate route to usage for us.
> > >> 
> > >> I'd really like to be able to "fastboot flash bootloader
> > >> u-boot.imx" and program SPI-NOR and also be able to boot a
> > >> kernel and RAM disk using "fastboot boot uImage uramdisk.img",
> > >> but neither of them seems very close. The first needs some more
> > >> structure, and the latter seemed to decide its' own address for
> > >> the kernel and simply ignore the RAM disk.
> > >> 
> > >> I have the sense that this code is pretty much a work in
> > >> progress, but I'd like to hear otherwise from those who have
> > >> used it.
> > > 
> > > OK, so let's wait for the others' opinions.
> > > 
> > > Best regards,
> > > Marek Vasut
> > 
> > I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3
> > because I don't think that it can actually occur on my boards....)
> > Thanks, Steve
> 
> OK, Lukasz, do you want to send me a PR with those two ?

There aren't any pending DFU patches, so I don't plan any PR before
our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

> 
> Best regards,
> Marek Vasut



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Monday, October 06, 2014 at 11:23:53 AM, Lukasz Majewski wrote:
> Hi Marek,
> 
> > On Wednesday, October 01, 2014 at 10:44:46 PM, Steve Rae wrote:
> > > On 14-10-01 05:13 AM, Marek Vasut wrote:
> > > > On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson wrote:
> > > >> Hi Marek,
> > > >> 
> > > >> On 09/30/2014 04:59 PM, Marek Vasut wrote:
> > > >>> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson
> > > >>> 
> > > >>> wrote:
> > > >>>> Hi Marek,
> > > >>>> 
> > > >>>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
> > > >>>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson
> > > >>>>> 
> > > >>>>> wrote:
> > > >>>>>> While trying to configure Nitrogen6X boards to use Android
> > > >>>>>> Fastboot, I found a number of places where the
> > > >>>>>> implementation doesn't appear to match the latest host tools
> > > >>>>>> on AOSP.
> > > >>>>>> 
> > > >>>>>> Eric Nelson (3):
> > > >>>>>>    usb: gadget: fastboot: add max-download-size variable
> > > >>>>>>    usb: gadget: fastboot: explicitly set radix of maximum
> > > >>>>>> 
> > > >>>>>> download size usb: gadget: fastboot: terminate commands with
> > > >>>>>> NULL
> > > >>>>> 
> > > >>>>> Just to make sure, are those fixes for 2014.10 or new stuff
> > > >>>>> for next ?
> > > >>>> 
> > > >>>> These patches are against master, but should apply against
> > > >>>> usb/next and dfu/next and "next" is fine for us.
> > > >>> 
> > > >>> 3/3 looks like a bugfix though. Is that a bugfix ?
> > > >> 
> > > >> I wasn't able to get fastboot to do much of anything without all
> > > >> three.
> > > >> 
> > > >> -- lack of max-download-size simply stopped downloads
> > > >> -- the missing radix caused my host to think that the 0x07000000
> > > >> size (copied from Beagle) was 1.8 MiB instead of 100+ MiB.
> > > >> -- the lack of termination showed up as a request to download
> > > >> a **huge** image when I tried to send u-boot.imx. I think I got
> > > >> lucky that the next characters in the buffer looked like hex
> > > >> digits.
> > > >> 
> > > >> I suspect that others are either holding on to some local patches
> > > >> or are perhaps using old versions of the Fastboot host program.
> > > >> 
> > > >> After applying all three, I was able to configure for flashing on
> > > >> an MMC device, but I don't have anything configured to use EFI
> > > >> partitions, so there's no immediate route to usage for us.
> > > >> 
> > > >> I'd really like to be able to "fastboot flash bootloader
> > > >> u-boot.imx" and program SPI-NOR and also be able to boot a
> > > >> kernel and RAM disk using "fastboot boot uImage uramdisk.img",
> > > >> but neither of them seems very close. The first needs some more
> > > >> structure, and the latter seemed to decide its' own address for
> > > >> the kernel and simply ignore the RAM disk.
> > > >> 
> > > >> I have the sense that this code is pretty much a work in
> > > >> progress, but I'd like to hear otherwise from those who have
> > > >> used it.
> > > > 
> > > > OK, so let's wait for the others' opinions.
> > > > 
> > > > Best regards,
> > > > Marek Vasut
> > > 
> > > I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3
> > > because I don't think that it can actually occur on my boards....)
> > > Thanks, Steve
> > 
> > OK, Lukasz, do you want to send me a PR with those two ?
> 
> There aren't any pending DFU patches, so I don't plan any PR before
> our ELCE2014 meeting.
> 
> Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

OK, done. Would you please keep an eye on 3/3 for me ?

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Eric Nelson]

Hi Marek,

On 10/06/2014 05:50 AM, Marek Vasut wrote:
> On Monday, October 06, 2014 at 11:23:53 AM, Lukasz Majewski wrote:
>> Hi Marek,
>>
>> <snip>
>>
>> There aren't any pending DFU patches, so I don't plan any PR before
>> our ELCE2014 meeting.
>>
>> Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.
> 
> OK, done. Would you please keep an eye on 3/3 for me ?
> 

Is there an issue with 3/3? It seems to be needed to prevent
reading of portions of the buffer that aren't part of the current
command (especially strtoul).

Please advise,


Eric

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Lukasz Majewski]

Hi Marek,

> On Monday, October 06, 2014 at 11:23:53 AM, Lukasz Majewski wrote:
> > Hi Marek,
> > 
> > > On Wednesday, October 01, 2014 at 10:44:46 PM, Steve Rae wrote:
> > > > On 14-10-01 05:13 AM, Marek Vasut wrote:
> > > > > On Wednesday, October 01, 2014 at 04:03:21 AM, Eric Nelson
> > > > > wrote:
> > > > >> Hi Marek,
> > > > >> 
> > > > >> On 09/30/2014 04:59 PM, Marek Vasut wrote:
> > > > >>> On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson
> > > > >>> 
> > > > >>> wrote:
> > > > >>>> Hi Marek,
> > > > >>>> 
> > > > >>>> On 09/30/2014 12:37 PM, Marek Vasut wrote:
> > > > >>>>> On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson
> > > > >>>>> 
> > > > >>>>> wrote:
> > > > >>>>>> While trying to configure Nitrogen6X boards to use
> > > > >>>>>> Android Fastboot, I found a number of places where the
> > > > >>>>>> implementation doesn't appear to match the latest host
> > > > >>>>>> tools on AOSP.
> > > > >>>>>> 
> > > > >>>>>> Eric Nelson (3):
> > > > >>>>>>    usb: gadget: fastboot: add max-download-size variable
> > > > >>>>>>    usb: gadget: fastboot: explicitly set radix of maximum
> > > > >>>>>> 
> > > > >>>>>> download size usb: gadget: fastboot: terminate commands
> > > > >>>>>> with NULL
> > > > >>>>> 
> > > > >>>>> Just to make sure, are those fixes for 2014.10 or new
> > > > >>>>> stuff for next ?
> > > > >>>> 
> > > > >>>> These patches are against master, but should apply against
> > > > >>>> usb/next and dfu/next and "next" is fine for us.
> > > > >>> 
> > > > >>> 3/3 looks like a bugfix though. Is that a bugfix ?
> > > > >> 
> > > > >> I wasn't able to get fastboot to do much of anything without
> > > > >> all three.
> > > > >> 
> > > > >> -- lack of max-download-size simply stopped downloads
> > > > >> -- the missing radix caused my host to think that the
> > > > >> 0x07000000 size (copied from Beagle) was 1.8 MiB instead of
> > > > >> 100+ MiB. -- the lack of termination showed up as a request
> > > > >> to download a **huge** image when I tried to send
> > > > >> u-boot.imx. I think I got lucky that the next characters in
> > > > >> the buffer looked like hex digits.
> > > > >> 
> > > > >> I suspect that others are either holding on to some local
> > > > >> patches or are perhaps using old versions of the Fastboot
> > > > >> host program.
> > > > >> 
> > > > >> After applying all three, I was able to configure for
> > > > >> flashing on an MMC device, but I don't have anything
> > > > >> configured to use EFI partitions, so there's no immediate
> > > > >> route to usage for us.
> > > > >> 
> > > > >> I'd really like to be able to "fastboot flash bootloader
> > > > >> u-boot.imx" and program SPI-NOR and also be able to boot a
> > > > >> kernel and RAM disk using "fastboot boot uImage
> > > > >> uramdisk.img", but neither of them seems very close. The
> > > > >> first needs some more structure, and the latter seemed to
> > > > >> decide its' own address for the kernel and simply ignore the
> > > > >> RAM disk.
> > > > >> 
> > > > >> I have the sense that this code is pretty much a work in
> > > > >> progress, but I'd like to hear otherwise from those who have
> > > > >> used it.
> > > > > 
> > > > > OK, so let's wait for the others' opinions.
> > > > > 
> > > > > Best regards,
> > > > > Marek Vasut
> > > > 
> > > > I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about
> > > > 3/3 because I don't think that it can actually occur on my
> > > > boards....) Thanks, Steve
> > > 
> > > OK, Lukasz, do you want to send me a PR with those two ?
> > 
> > There aren't any pending DFU patches, so I don't plan any PR before
> > our ELCE2014 meeting.
> > 
> > Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb
> > directly.
> 
> OK, done. Would you please keep an eye on 3/3 for me ?

Ok. No problem (If I would be added to CC).

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Monday, October 06, 2014 at 05:49:11 PM, Eric Nelson wrote:
> Hi Marek,
> 
> On 10/06/2014 05:50 AM, Marek Vasut wrote:
> > On Monday, October 06, 2014 at 11:23:53 AM, Lukasz Majewski wrote:
> >> Hi Marek,
> >> 
> >> <snip>
> >> 
> >> There aren't any pending DFU patches, so I don't plan any PR before
> >> our ELCE2014 meeting.
> >> 
> >> Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.
> > 
> > OK, done. Would you please keep an eye on 3/3 for me ?
> 
> Is there an issue with 3/3? It seems to be needed to prevent
> reading of portions of the buffer that aren't part of the current
> command (especially strtoul).
> 
> Please advise,

OK, I will pick the 3/3 too.

btw. The patch is not checkpatch clear. I _do_ know you know better than to 
submit such a poor patch. I will fix this locally.

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Eric Nelson]

On 10/06/2014 12:07 PM, Marek Vasut wrote:
> On Monday, October 06, 2014 at 05:49:11 PM, Eric Nelson wrote:
>> Hi Marek,
>>
>> On 10/06/2014 05:50 AM, Marek Vasut wrote:
>>> On Monday, October 06, 2014 at 11:23:53 AM, Lukasz Majewski wrote:
>>>> Hi Marek,
>>>>
>>>> <snip>
>>>>
>>>> There aren't any pending DFU patches, so I don't plan any PR before
>>>> our ELCE2014 meeting.
>>>>
>>>> Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.
>>>
>>> OK, done. Would you please keep an eye on 3/3 for me ?
>>
>> Is there an issue with 3/3? It seems to be needed to prevent
>> reading of portions of the buffer that aren't part of the current
>> command (especially strtoul).
>>
>> Please advise,
> 
> OK, I will pick the 3/3 too.
> 
> btw. The patch is not checkpatch clear. I _do_ know you know better than to 
> submit such a poor patch. I will fix this locally.
> 
Thanks Marek,

I do know better and missed it in V2.

[U-Boot] [PATCH 0/3] usb: gadget: fastboot miscellaneous patches

[Marek Vasut]

On Monday, October 06, 2014 at 10:01:47 PM, Eric Nelson wrote:
> On 10/06/2014 12:07 PM, Marek Vasut wrote:
> > On Monday, October 06, 2014 at 05:49:11 PM, Eric Nelson wrote:
> >> Hi Marek,
> >> 
> >> On 10/06/2014 05:50 AM, Marek Vasut wrote:
> >>> On Monday, October 06, 2014 at 11:23:53 AM, Lukasz Majewski wrote:
> >>>> Hi Marek,
> >>>> 
> >>>> <snip>
> >>>> 
> >>>> There aren't any pending DFU patches, so I don't plan any PR before
> >>>> our ELCE2014 meeting.
> >>>> 
> >>>> Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb
> >>>> directly.
> >>> 
> >>> OK, done. Would you please keep an eye on 3/3 for me ?
> >> 
> >> Is there an issue with 3/3? It seems to be needed to prevent
> >> reading of portions of the buffer that aren't part of the current
> >> command (especially strtoul).
> >> 
> >> Please advise,
> > 
> > OK, I will pick the 3/3 too.
> > 
> > btw. The patch is not checkpatch clear. I _do_ know you know better than
> > to submit such a poor patch. I will fix this locally.
> 
> Thanks Marek,
> 
> I do know better and missed it in V2.

No worries, thank you!

Best regards,
Marek Vasut