> Ok, but if we do that we need to be careful with the standard. Things
> like BLOBLISTT_U_BOOT_VIDEO dont feel U-Boot specific.
The idea behind the Transfer List tag allocation policy is low
friction allocation and organically emerging standards. You're not
supposed to need to have big up-front
Here are a couple of other differences I have found between the
bloblist code after applying your patches and the TL specification:
* bloblist seems to explicitly disallow having the same tag more than
once in the list (e.g. see documentation of bloblist_add()), whereas
the TL specification
I'm not sure why you would add an API to allow setting this
explicitly, that's not really how it is supposed to work according to
the spec. New TLs are always supposed to start with an alignment
requirement of 8 (2^3) and then automatically increase that value if a
TE gets added that has a larger
> - rec->tag = tag;
> - rec->hdr_size = sizeof(struct bloblist_rec);
> + rec->tag_and_hdr_size = tag | sizeof(*rec) <<
> BLOBLISTR_HDR_SIZE_SHIFT;
nit: Might be a good idea to mask the tag or double-check that it fits
the field size here.
> - * 5. Bloblist uses 16-byte
> /* Calculate the new allocated total */
> - new_alloced = data_start + ALIGN(size, 1U << align_log2);
> + new_alloced = data_start - map_to_sysmem(hdr) +
> + ALIGN(size, 1U << align_log2);
I think this is incorrect. There's no requirement that the size of an
> diff --git a/include/bloblist.h b/include/bloblist.h
> index 7ea72c6bd46..bad5fbbb889 100644
> --- a/include/bloblist.h
> +++ b/include/bloblist.h
nit: I would suggest also updating the documentation at the top of
this file (point 7) to clarify that new standardized tags must be
allocated in
> OK, this seems to be the crux of the problem. Is it possible for us say that
> users are free to register new TLs, while at the same time recommending the
> use of existing formats for complex structures (e.g. FDT, HOB)?
I'm not really sure what qualifies as a "complex structure" in this
It seems like some of us still have very different opinions about how
this handoff structure should and shouldn't be used, which I really
think need to be worked out and then codified in the spec before we
can call the document final, because otherwise no firmware project can
trust that it is safe
Okay, FWIW I created a pull request with my suggestions here:
https://github.com/FirmwareHandoff/firmware_handoff/pull/4
That should make it easier to discuss specific details, hopefully. As
I was looking at the header size and format more closely I noticed
that the checksum calculation and some
Hi Jose,
Apologies for the late response, I had to find some time to dig back
into this topic first.
> The proposal is that the tag assignments are handled via a PR to [1].
> A PR should provide reasoning for the proposed entry layout as well as a
> description of the use-case being serviced.
>
> That draft is the DEN0135 document [2].
> I realise that I haven’t made it sufficiently explicit in this thread that
> the DEN0135 document [2] is still at draft quality (see ALP maturity called
> out in the title page and footers).
> Please do not consider this a finished document . We’ve
Hi Jose,
Can you provide a bit more background on where this proposal suddenly
came from and what considerations went into its design? The mailing
list discussion from last year sort of petered out without much
concrete agreement, and now you're here with a full specification.
It's hard to
> Since it doesn't seem possible to have each boot component using the same log
> format, we added a log_format and log_phys_addr fields to give flexibility in
> how logs are stored. An example of a different log format that can be used is
> the cbmem_console log format used by coreboot:
I am not
> - fuller implementation with more features
Is that a good thing? Didn't we just have a long discussion eschewing
a heavy-handed, bulky hand-off block design in favor of more simple
and flexible structures? I think simplicity is key for this and the
bl_aux_params are trying to be about as simple
> - "bloblist" is a general term for concept of linked list and it's not
> exactly U-boot implementation. The proposed solution will cause some degree
> of changes in all the participating projects. For backward compatibility
> issue, we have already though about it and proposed to have build
> Of course every project would like not to change...
>
> For TF-A I wonder whether it will/should in fact use devicetree if there is a
> lot of complex data? TBD, I suppose.
Okay, sorry, now I'm a bit confused -- I thought the discussion in
this thread was about which parameter hand-off
>
> Thank you all for your feedback.
>
> It appears that in theory we are all happy with using bloblist with few
> implementation details which needs to be taken care of during
> implementation.
>
Just to clarify: are you using "bloblist" as a general term for the concept
of a simple linked list
> These structures we are talking about may not be defined by the SiP, and
just saying we have SiP specific tags is not good enough.
There is enough room in 64-bits to create separate tag spaces for every
kind of category you can think of. (In fact, we could also just let every
vendor allocate
Hi Raghu,
> It appears there are opinions you carry around UUID being complicated,
> bloated, code being an eyesore, parsing these lists early with MMU/Caches
> disabled, calculating checksums etc. While there is certainly a LOT of
> truth to those statements, these concerns need to be put into
Just want to point out that TF-A currently already supports a (very simple)
mechanism like this:
https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/refs/heads/master/include/export/lib/bl_aux_params/bl_aux_params_exp.h
Standardizing in-memory logging sounds like an interesting idea,
especially with regards to components that can run on top of different
firmware stacks (things like GRUB or TF-A). But I would be a bit wary
of creating a "new standard to rule them all" and then expecting all
projects to switch what
the identifiers "has_content_checksum" and "lz4_frame_header" have
> never appeared anywhere in the source (and he uses camelCase).
That comment refers to the lz4.c file that's included by the line
right below it. That was copied 1-to-1 from Yann's code. The
lz4_wrapper.c file was written fr
m to avoid these issues. Still, setting the
'compression' node like that is wrong in the first place, so we still
want to print out a warning so that third-party distributions doing this
can notice and fix it.
Signed-off-by: Julius Werner
---
common/image-fit.c| 13 +
tes
> OK. So lets special case ramdisk to just note that we see it's
> compressed ("compression: %s, ignored" ?) and then we'll find out if
> there's really a bunch of cases where people assumed it was decompressed
> by us or not.
Sounds good! I'll send a patch.
> Well, I'm sure you'd find enough FIT images where the uncompression
> might succeed but the target space for decompression is not big enough
> (see bootm_size), would such an error be fixed as well?
I think so? Assuming all the compression algorithms check for an
output buffer overrun (looks
> First, we have a problem as we need to support what's out in the world.
How about I write a patch to change the decompression call in
fit_image_load() to fall back to a memcpy() if the decompression fails
(and print a big warning that the FIT image is wrong and should be
updated)? That should
> OK, this now causes 'make tests' to fail on the FIT image tests, please
> look. Thanks!
Whoops, sorry, should have run that again. This was just a printf()
without a newline at the end, apparently pytest really doesn't like
that. (I took out the "OK" at the end of the "Loading kernel..."
be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
Reviewed-by: Simon Glass
---
- No changes for v2
- No changes for v3
- Changes for v4:
- Added documentation for compatible string in config node.
- Added
.
Sandbox-tested with FIT images with and without compressed FDTs, with
and without overlays, in both compatible string matching and direct
config selection modes. Also expanded the test_fit pytest to include a
case with compressed kernel, FDT and ramdisk.
Julius Werner (3):
common: Move
and renames it to image_decomp() in
preparation of those upcoming patches.
Signed-off-by: Julius Werner
---
- First version: v5
- Changes for v6
- Fixed test_fit.py (had a printf() without a newline)
common/bootm.c | 148 ++---
common/image.c
> I'd like to review this, but maybe you can help me speed up the process and
> tell
> us if the move has been a 1:1 code move or if you had to adapt things to the
> new
> location (other than the function being renamed)?
print_decomp_msg() is a 1:1 move. bootm_decomp_image() is mostly 1:1
> This kind of interleaved change log is kind of hard to read. A higher-level,
> manually written changelog for the cover letter would be better I think.
Sorry, will rewrite the cover letter next time. For v5 I just added
the new patch and didn't change the other two.
> If there haven't been any changes from v4, why did you drop Simon Glass's
> Reviewed-by tag?
Same here:
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
> If there haven't been any changes from v4, why did you drop Simon Glass's
> Reviewed-by tag?
Sorry, I wasn't aware I was supposed to preserve those manually. Yes,
there were no changes so this should still be considered
Reviewed-by: Simon Glass
___
Hi Tom,
> This breaks tools-only_defconfig in non-trivial ways due to calling
> bootm_decomp_image() which is not normally available to it. Can you
> please update things (it may just end up being common/Makefile that
> needs tweaking) so that tools-only builds? I'll then take a look and
> make
the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
- No changes for v2
- No changes for v3
- Changes for v4:
- Added documentation for compatible string in config node.
- Added example .its file
be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
and renames it to image_decomp() in
preparation of those upcoming patches.
Signed-off-by: Julius Werner
---
- First version: v5
common/bootm.c | 148 ++---
common/image.c | 111 ++
include/bootm.h| 17
.
Sandbox-tested with FIT images with and without compressed FDTs, with
and without overlays, in both compatible string matching and direct
config selection modes. Also expanded the test_fit pytest to include a
case with compressed kernel, FDT and ramdisk.
Julius Werner (3):
common: Move
Hi Simon,
I forgot about these for a while, but I believe I addressed all the
feedback you still had in the latest version (v4). Looks like they
didn't get picked up anywhere though. Can you help?
On Thu, May 16, 2019 at 7:34 PM Simon Glass wrote:
>
> On Wed, 15 May 2019 at 16:30, Julius
the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
- No changes for v2
- No changes for v3
- Changes for v4:
- Added documentation for compatible string in config node.
- Added example .its file
compressed FDTs, with
and without overlays, in both compatible string matching and direct
config selection modes. Also expanded the test_fit pytest to include a
case with compressed kernel, FDT and ramdisk.
Julius Werner (2):
fit: Support compression for non-kernel components (e.g. FDT
be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
PM Simon Glass wrote:
> > >
> > > Hi Julius,
> > >
> > > On Mon, 13 May 2019 at 19:13, Julius Werner wrote:
> > > >
> > > > > Is there a change log for this patch?I think we discussed having a
> > > > > test.
> >
> Can you please add a change log, as this is a v3 patch.
I didn't change anything in this one. (Should I have not called it v3
then? Sorry, I'm not familiar with the submission process here. I
thought letting the individual patches in the series have different
version numbers for the same set
> Is there a change log for this patch?I think we discussed having a test.
Sorry, forgot that. Is it okay if I just put it here or do you need me
to resend a v4?
---
Changes for v2:
- made decompression work for all non-kernel images, not just FDTs
Changes for v3:
- fixed up debug output
> Oh, ok. Guess I was just surprised that it says "can't extract compat"
> when it tries to check "comp"...
Well, what I'm trying to say in that error is "can't extract the
compatible string *because* the FDT is compressed", but without making
it three lines long.
> We should get a test together
the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
common/image-fit.c | 67 +++---
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/common/image-fit.c b
be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
compressed FDTs, with
and without overlays, in both compatible string matching and direct
config selection modes. Also expanded the test_fit pytest to include a
case with compressed kernel, FDT and ramdisk.
Julius Werner (2):
fit: Support compression for non-kernel components (e.g. FDT
On Tue, Apr 30, 2019 at 11:25 AM Simon Goldschmidt
wrote:
>
> Am 18.04.2019 um 23:08 schrieb Julius Werner:
> > This patch adds support for compressing non-kernel image nodes in a FIT
> > image (kernel nodes could already be compressed previously). This can
> > reduc
> However, compared to my above mentioned RFC patch, this here somehow
> fails when loading something from the image, e.g. using the cmd 'fpga
> loadmk'. Seems like this one doesn't transparently uncompress?
It looks to me like do_fpga_loadmk() doesn't actually call
fit_load_image()? It calls
be decompressed on load.
This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
> Hmm, I think we might want to use the lmb functions here to allocate a
> buffer instead of relyling on malloc? The malloc pool might be large
> enough for an uncompressed devicetree, but not for an 8 MByte FPGA image...
>
> But starting with malloc might be ok.
Okay, that sounds like a good
the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
common/image-fit.c | 67 +++---
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/common/image-fit.c b
compressed FDTs, with
and without overlays, in both compatible string matching and direct
config selection modes.
Julius Werner (2):
fit: Support compression for non-kernel components (e.g. FDT)
- Changes for v2:
- Changed from only supporting compressed FDTs to supporting all
> My approach was to uncompress all compressed images on-the-fly in
> fit_image_load().
Right, that's essentially what this patch is doing too.
> Or I could dig up my patches from October and we'll see how far you get
> with those?
I think I found your patch:
Hi Simon,
Is your approach similar to what I did here (decompressing
transparently as part of fit_image_load())? I think I could easily
expand this to other image types, I just don't always know how to test
those. Really, the only thing that can't be decompressed there is the
kernel image
the traditional extraction of the compatible string from
the kernel FDT itself is not easily possible.
Signed-off-by: Julius Werner
---
common/image-fit.c | 67 +++---
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/common/image-fit.c b
overlays, in both compatible string matching and direct
config selection modes.
Julius Werner (2):
fit: Support FDT compression
fit: Support compat string property in configuration node
common/image-fit.c | 142 +++--
1 file changed, 85 insertions(+), 57
compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.
Signed-off-by: Julius Werner
---
common/image-fit.c | 85
Hi U-Boot developers,
(I picked a few of you out that seem to be most related to this code,
hope that's okay,)
I am interested in booting device trees with overlays from a FIT image
(actually for a different bootloader, but we're trying to stay
compatible with U-Boot's FIT format so I'm asking
have a U-Boot development system set
up right now. The code was imported unchanged from coreboot where it's
proven to work, though. I'm mostly interested in getting this recognized
by mkImage for use in a downstream project.
Signed-off-by: Julius Werner <jwer...@chromium.org>
---
common/b
Well then... a few hours and a significant reduction in sanity later,
I found that I'm shadowing the new 'ret' variable from changing the
API around because I forgot to remove the declaration part from the
'ret' that already existed in the else block. It would be nice if
U-Boot compiled with
> You can build U-Boot with NO_SDL=1
Ah, thanks... that was the important magic flag I needed!
> Actually you should enable the option in configs/sandbox_defconfig,
> not lib/Kconfig. See the condition used by compression.c:
>
> obj-$(CONFIG_SANDBOX) += compression.o
Okay, makes sense. I looked
have a U-Boot development system set
up right now. The code was imported unchanged from coreboot where it's
proven to work, though. I'm mostly interested in getting this recognized
by mkImage for use in a downstream project.
Signed-off-by: Julius Werner <jwer...@chromium.org>
---
common/b
>
> I get this build error with sandbox.
>
> test/built-in.o: In function `uncompress_using_lz4':
> /home/sjg/c/src/third_party/u-boot/files/test/compression.c:278:
> undefined reference to `ulz4fn'
>
Yeah... that's because you didn't configure it in. I'm not really sure how
this is supposed to
have a U-Boot development system set
up right now. The code was imported unchanged from coreboot where it's
proven to work, though. I'm mostly interested in getting this recognized
by mkImage for use in a downstream project.
Signed-off-by: Julius Werner <jwer...@chromium.org>
---
cleaner.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/ehci-hcd.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fdad739..3ae04c0 100644
--- a/drivers/usb/host/ehci
Hi Simon,
It seems like you could do something like
/*
* This is the delay for ...the spec requires a minimum of ...
*/
#define SOME_SUITABLE_NAME 8000
at the top of the file and then use it twice in your function.
The file contains a dozen handshake() calls that have a literal 100 *
Hello Marek,
8 seemed like a reasonable value. It is not the only possible one. As
I said, the spec requires a minimum of 4.125 (125us to make sure the
current microframe finishes, and 16 * 125us to wait for the 16 full
microframes listed on page 20). 8 fulfills that constraint and leaves
a
Why 8 * 1000? It's not clear.
I am not quite sure to be honest... it's been a while since I actually
wrote this patch. The EHCI spec gives no clear max for the
Periodic/Async Schedule disable (I assume not more than a frame,
though), and says the Run/Stop bit must halt within 16 microframes
cleaner.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/ehci-hcd.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index fdad739..3143021 100644
--- a/drivers/usb/host/ehci-hcd.c
I saw that you had proposed a patch for increasing the U-Boot timeout to
work with some USB flash devices:
http://lists.denx.de/pipermail/u-boot/2010-December/083467.html
Some devices do have strange characteristics, and increasing the
timeout can make them work. However, it's tricky since
How would that make the code more consistent ? It seems if the device can not
even provide valid config ep descriptor, the device is broken beyond
salvation.
Okay, sure, it's not important enough to argue about. Will resubmit it this way.
The sizeof() thing is true for the configuration
some safety to potential out-of-order descriptors.
Change-Id: I16f69dfdd6793aa0fe930b5148d4521f3e5c3090
Signed-off-by: Julius Werner jwer...@chromium.org
---
common/usb.c | 87 +---
common/usb_hub.c | 14 +++--
2 files changed, 75
From a security / robustness standpoint,
- if the descriptor length field is found to be abnormal, then the code
should not process the packet at all. Here it seems it only warns
then goes on to use the descriptor.
Weren't you the guy who was so worried about poor Chinese devices who
Mulling over this some more, I suspect if the device does have incorrect
config
descriptor, we should just ignore the device because it's broken piece of
junk.
I can change it if you insist, but I'd like to keep it to make the
code look more consistent (since later on with the
some safety to potential out-of-order descriptors.
Change-Id: I16f69dfdd6793aa0fe930b5148d4521f3e5c3090
Signed-off-by: Julius Werner jwer...@chromium.org
---
common/usb.c | 73 ++--
common/usb_hub.c | 14 ---
2 files changed, 64
some safety to potential out-of-order descriptors.
Change-Id: I16f69dfdd6793aa0fe930b5148d4521f3e5c3090
Signed-off-by: Julius Werner jwer...@chromium.org
---
common/usb.c | 62
common/usb_hub.c | 14 -
2 files changed, 53
Thanks for taking charge of this Simon, looks good to me. Good catch
with the missing break!
Now that I look at it, the FEAT_C_ENABLE section seems to be broken as
well, it should be setting EHCI_PS_PEC instead of EHCI_PS_PE. Maybe
that code path is never used in practice.
Acked-by: Julius
On Wed, Apr 24, 2013 at 5:50 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Fix the Port status bit constants and Port feature number
constants as a part of USB 2.0 and USB 3.0 Hub class.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
common/usb_hub.c | 40
Sorry, forgot this one yesterday. I would consider to just drop/revert
this patch entirely. It's not wrong, but it adds complexity where it is
not needed. You don't have to reset SuperSpeed devices, but it shouldn't
hurt either and from what I can tell Linux does it as well.
As per XHCI
This 20ms delay is truely being taken to be on safer side (twice of
Power-on-to-power-good),
its not observational.
In my earlier patch-series, we were doing the same way as you are
suggesting here (power-on
ports only if they aren't), however Marek suggested to power-cycle the
ports. This
I would reword Additions to Changes and explicitly state that these
fields
concern the new USB 3.0 hub descriptor format, which is different and
exclusively applies to SuperSpeed hubs.
This bit fields are actually additions to USB 3.0 framework. These
fields are not defined in
USB 2.0
Migrating my comments here for public discussion.
This adds usb framework support for super-speed usb, which will
further facilitate to add stack support for xHCI.
Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes
Fetch the device class into usb device's dwcriptors,
so that the host controller's driver can use this info
to differentiate between HUB and DEVICE.
Signed-off-by: Amar amarendra...@samsung.com
---
Changes from v2:
- none
common/usb.c |5 +
1 files changed, 5
XHCI ports are powered on after a H/W reset, however
EHCI ports are not. So disabling and re-enabling power
on all ports invariably.
Signed-off-by: Amar amarendra...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Changes from v2:
- Replaced USB_HUB_PRINTFs to
These patches haven't gone in yet, right? I think Vivek wants to
discuss/update them himself, he just asked me to move my reviews to
this thread.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
. But now that I'm looking at
it, it's this patch that caused it, sorry.
commit 28b31a5937b89528c40df24dd6c9122578880605
Author: Julius Werner jwer...@chromium.org
Date: Thu Feb 28 18:08:40 2013 +
usb: Add new command to set USB 2.0 port test modes
diff --git a/drivers/usb/host/ehci
Oops... I somehow pulled three lines of other local changes in there
that don't belong when I cherry-picked this into my upstream branch.
Sorry, will resubmit this once more.
On Tue, Feb 19, 2013 at 5:14 PM, Julius Werner jwer...@chromium.org wrote:
This patch adds a new 'usb test' command
This patch adds a new 'usb test' command, that will set a port to a USB
2.0 test mode (see USB 2.0 spec 7.1.20). It supports all five test modes
on both downstream hub ports and ordinary device's upstream ports. In
addition, it supports EHCI root hub ports.
Signed-off-by: Julius Werner jwer
Hi Tom,
This patch is not really target specific, it works on all platforms that
support USB 2.0. I just wrapped it in a new config option because most
people probably won't need it… it is only really useful for hardware
verification, so I figured whoever needs it can hack in the config option
I guess you are right about the bit rot, it makes more sense to keep
this on so people notice when things break. I have compiled it for
smdk5250 (though it's all common and EHCI code, so that should make no
difference) and only measured a 1.1k increase in uncompressed code
size (less than 0.3%). I
This patch adds a new 'usb test' command, that will set a port to a USB
2.0 test mode (see USB 2.0 spec 7.1.20). It supports all five test modes
on both downstream hub ports and ordinary device's upstream ports. In
addition, it supports EHCI root hub ports.
Signed-off-by: Julius Werner jwer
by the
CONFIG_CMD_USB_TEST ifdef (disabled by default).
Signed-off-by: Julius Werner jwer...@chromium.org
---
README | 1 +
common/cmd_usb.c| 127
doc/README.usb | 1 +
drivers/usb/host/ehci-hcd.c | 32
97 matches
Mail list logo
