public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] usb: Use well-known descriptor sizes when parsing configuration
Date: Sun, 21 Jul 2013 04:32:36 +0200	[thread overview]
Message-ID: <201307210432.36967.marex@denx.de> (raw)
In-Reply-To: <CAODwPW-gfjVhWG9v1rDtT7=thN1jy2jEPyop0t6CaKy9bqgjJg@mail.gmail.com>

Hi Julius,

> > 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 descriptor, but not
> >> for some others (e.g. endpoint) because U-Boot reserves fields for
> >> it's own stuff behind that.
> > 
> > Urgh, then the structure defining the descriptor shall be separated out.
> 
> Yes, maybe. But let's please not blow this patch up any more than it
> already is.
> 
> >> > Would be nice to clean this up into "understandable" format by
> >> > defining a variable for the &buffer[index] and than just simply
> >> > comparing this var-
> >> > 
> >> >>bInterfaceNumber and curr_if_num .
> >> 
> >> Agreed, but let's clean this up one patch at a time.
> > 
> > Would you do a series on this maybe?
> 
> On second thought, we already have the variable head (respectively
> head->bLength) to point there... I can just use that instead.
> 
> > So, let's just ignore broken descriptors.
> 
> Done.
> 
> > Document this properly then.
> 
> I'm already adding a comment to usb_parse_config() to point that
> out... I'll clarify that this includes sanitization in addition to
> byte swapping.

THanks a lot! I'm glad you're cleaning this horror up.

Best regards,
Marek Vasut

      reply	other threads:[~2013-07-21  2:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18  0:55 [U-Boot] [PATCH v2] usb: Use well-known descriptor sizes when parsing configuration Julius Werner
2013-07-18 16:43 ` Albert ARIBAUD
2013-07-18 17:11   ` Julius Werner
2013-07-18 18:25     ` Marek Vasut
2013-07-18 18:49 ` Marek Vasut
2013-07-18 19:22   ` Julius Werner
2013-07-19  1:49     ` Marek Vasut
2013-07-19 20:11       ` Julius Werner
2013-07-21  2:32         ` Marek Vasut [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201307210432.36967.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox