Dan, ---------------- Thanks & Regards, Pavan Savoy | x0099669
> -----Original Message----- > From: Dan Carpenter [mailto:[email protected]] > Sent: Friday, August 27, 2010 4:53 PM > To: Savoy, Pavan > Cc: [email protected] > Subject: Re: [bug report] ti-st: potential overflow calling st_send_frame() > > On Fri, Aug 27, 2010 at 07:43:02PM +0530, Savoy, Pavan wrote: > > I am not sure I understand, the logic is something like this, when the > > state of the recv is W4_DATA, the protoid would be already set to > > either ST_BT, ST_FM or ST_GPS based on the packet id received under > > state HCI_EVENT_PKT or ST_FM_CH8_PKT or 0x9. > > > > The protoid is set to ST_MAX after doing a st_send_frame because the > > protoid variable needs to be sort of reset (not absolutely necessary), > > but the state has to be carefully updated to W4_PACKET_TYPE so that > > protoid is set to right value upon recv-ing next packet.. > > > > It's also initialized to ST_MAX at the start of the function. It hard > to follow the flow so I wasn't sure that st_gdata->rx_state couldn't be > ST_BT_W4_DATA when st_int_recv() is called. > > But now that you've explained it, it's cool. Sorry for the noise. No problem, Thanks and appreciate you running audits over my driver :) Please report any other findings to help improve.. > regards, > dan carpenter > > > > This is all because the UART may send in 100 bytes of BT data in chunks > > of 5 20bytes packets. > > > > Does this make sense? > > > > > > > > > > > regards, > > > dan carpenter _______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
