On Wed, Sep 10, 2008 at 04:52:03PM -0700, Tony Lindgren wrote:
> I guess you're talking about 8cc4af26d1e2b01cd9dc2c5e6b166d08946bc2e6
> that I just pushed?
Precisely.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
* Felipe Balbi <[EMAIL PROTECTED]> [080910 04:27]:
> On Wed, Sep 10, 2008 at 02:20:35PM +0300, ext Kevin Hilman wrote:
> > Felipe Balbi wrote:
> >> Let's keep linux-usb on the loop for musb related patches ;-)
> >>
> >> On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
> >>> There i
On Wed, Sep 10, 2008 at 02:20:35PM +0300, ext Kevin Hilman wrote:
> Felipe Balbi wrote:
>> Let's keep linux-usb on the loop for musb related patches ;-)
>>
>> On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
>>> There is no check if platform code passes in more endpoints (num_eps)
Felipe Balbi wrote:
Let's keep linux-usb on the loop for musb related patches ;-)
On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
There is no check if platform code passes in more endpoints (num_eps)
than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
that all
Let's keep linux-usb on the loop for musb related patches ;-)
On Wed, Sep 10, 2008 at 08:53:56AM +0300, ext Kevin Hilman wrote:
> There is no check if platform code passes in more endpoints (num_eps)
> than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
> that allocate_instance()
There is no check if platform code passes in more endpoints (num_eps)
than the maximum number of enpoints (MUSB_C_NUM_EPS.) The result is
that allocate_instance() happily writes past the end of 'struct musb'
corrupting memory.
The fix below increases the max to 32 (used on omap3) and also adds a
