[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0C18FE92A7765D4EB9EE5D38D86A563A05D30D56@SHSMSX103.ccr.corp.intel.com>
Date: Thu, 19 May 2016 02:31:02 +0000
From: "Du, Changbin" <changbin.du@...el.com>
To: Felipe Balbi <felipe.balbi@...ux.intel.com>,
Michal Nazarewicz <mina86@...a86.com>,
Alan Stern <stern@...land.harvard.edu>
CC: Al Viro <viro@...iv.linux.org.uk>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"rui.silva@...aro.org" <rui.silva@...aro.org>,
"k.opasiak@...sung.com" <k.opasiak@...sung.com>,
"lars@...afoo.de" <lars@...afoo.de>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: gadget: f_fs: report error if excess data received
> >> thanks Alan Stern and Michal.
> >> Here just have a comment - the buffered data need be dropped when
> the
> >> epfile is closed, because it means the session is terminated.
> >
> > I blame that on sleep deprivation. Another issue is what to do when
> > endpoint is disabled. Should the buffer be cleared as soon as the
> > endpoint is disabled? Or maybe when the endpoint is enabled again? Or
> > maybe it should never be cleared?
> >
> > If the buffer is cleared when endpoint is disabled, we again silently
> > drop data. On the other hand, if we don’t do that, read() on the
> > endpoint will may succeed even if the configuration is disabled which
> > may be surprising for users.
>
> tough decision... but seems like clearing the buffer as soon as ep is
> disabled is the way to go.
>
> --
> Balbi
I agree with Balbi, seems it is not easy to maintain the excess buffer... I was to
implement it at the beginning but I am not confident everything is done correctly.
Powered by blists - more mailing lists