Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access

[Petko Manolov <petkan@nucleusys.com>]

On 17-02-06 09:28:22, Greg KH wrote:
> On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> > On 17-02-05 01:30:39, Greg KH wrote:
> > > On Sat, Feb 04, 2017 at 04:56:03PM +0000, Ben Hutchings wrote:
> > > > Allocating USB buffers on the stack is not portable, and no longer works 
> > > > on x86_64 (with VMAP_STACK enabled as per default).
> > > 
> > > It's never worked on other platforms, so these should go to the stable 
> > > releases please.
> > 
> > As far as i know both drivers works fine on other platforms, though I only 
> > tested it on arm and mipsel. ;)
> 
> It all depends on the arm and mips platforms, the ones that can not DMA from 
> stack memory are the ones that would always fail here (since the 2.2 kernel 
> days).

Seems like most modern SOCs have decent DMA controllers.

> > Random thought: isn't it better to add the alloc/free code in 
> > usb_control_msg() and avoid code duplication all over the driver space?
> 
> A very long time ago we considered it, but realized that the majority of 
> drivers already had the memory dynamically allocated, so we just went with 
> this.  Perhaps we could revisit that if it turns out we were wrong, and would 
> simplify things.

A quick glance at usb_control_msg() users (looked only at .../net/usb and 
.../usb/serial) shows that most of them have the buffer allocated in stack.  
These transfers are relatively infrequent and quite small the performance hit 
caused by memcpy() should also be negligible.

I suspect getting the buffer allocation in usb_control_msg() will help with two 
things in the same time:

 - allocate in DMA-able memory;
 - code reduction;

On the bad side i've no idea who'll volunteer to go through all 
usb_control_msg() sites and perform the fix.  Seems like the right job for an 
intern to me. :D


cheers,
Petko