On Tue, Sep 09, 2014 at 10:04:26AM -0500, Felipe Balbi wrote:
> On Tue, Sep 09, 2014 at 08:23:15AM +0200, Robert Baldyga wrote:
> > Up to now, when endpoint addresses in descriptors were non-consecutive,
> > there were created redundant files, which could cause problems in kernel,
> > when user
On Tue, Sep 09, 2014 at 08:23:15AM +0200, Robert Baldyga wrote:
> Up to now, when endpoint addresses in descriptors were non-consecutive,
> there were created redundant files, which could cause problems in kernel,
> when user tried to read/write to them. It was result of fact that maximum
>
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tried to read/write to them. It was result of fact that maximum
endpoint address was taken as total number of endpoints in funciton.
This
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tried to read/write to them. It was result of fact that maximum
endpoint address was taken as total number of endpoints in funciton.
This
On Tue, Sep 09, 2014 at 08:23:15AM +0200, Robert Baldyga wrote:
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tried to read/write to them. It was result of fact that maximum
endpoint
On Tue, Sep 09, 2014 at 10:04:26AM -0500, Felipe Balbi wrote:
On Tue, Sep 09, 2014 at 08:23:15AM +0200, Robert Baldyga wrote:
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tried to
6 matches
Mail list logo