From: Ben Hutchings <bhutchings@solarflare.com>
To: Greg KH <greg@kroah.com>
Cc: Steve Glendinning <steve.glendinning@smsc.com>,
netdev@vger.kernel.org, Ian Saturley <ian.saturley@smsc.com>,
Catalin Marinas <catalin.marinas@arm.com>,
David Brownell <dbrownell@users.sourceforge.net>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/1] SMSC LAN9500 USB2.0 10/100 ethernet adapter driver
Date: Tue, 09 Sep 2008 15:30:10 +0100 [thread overview]
Message-ID: <1220970610.2381.64.camel@achroite> (raw)
In-Reply-To: <20080909140224.GA3095@kroah.com>
On Tue, 2008-09-09 at 07:02 -0700, Greg KH wrote:
> On Tue, Sep 09, 2008 at 02:19:47PM +0100, Ben Hutchings wrote:
> > On Tue, 2008-09-09 at 12:36 +0100, Steve Glendinning wrote:
> > [...]
> > > diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> > > new file mode 100644
> > > index 0000000..60ffd90
> > > --- /dev/null
> > > +++ b/drivers/net/usb/smsc95xx.c
> > [...]
> > > +static int smsc95xx_read_reg(struct usbnet *dev, u32 index, u32 *data)
> > > +{
> > > + u32 *buf = kmalloc(4, GFP_KERNEL);
> > > + int ret;
> > > +
> > > + BUG_ON(!dev);
> > > +
> > > + if (!buf)
> > > + return -ENOMEM;
> > > +
> > > + ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
> > > + USB_VENDOR_REQUEST_READ_REGISTER,
> > > + USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
> > > + 00, index, buf, 4, USB_CTRL_GET_TIMEOUT);
> > > +
> > > + if (unlikely(ret < 0))
> > > + SMSC_WARNING("Failed to read register index 0x%08x", index);
> > > +
> > > + le32_to_cpus(buf);
> > > + *data = *buf;
> > > + kfree(buf);
> > > +
> > > + return ret;
> > > +}
> >
> > Why are you allocating a buffer on the heap? What's wrong with
>
> USB requires data to be allocated off of the heap when you use it to
> send or receive data.
I don't really know USB (it's not very useful for 1G/10G networking :-)
which is why I asked. Is this because the data may be transferred by
DMA and the stack might not be DMA-mappable?
I'd be inclined to allocate a persistent buffer for register reads and
writes, but then that seems to introduce the need for another lock.
Presumably the heap allocation is reckoned to add very little overhead
compared to the inherent cost of synchronous USB requests?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2008-09-09 14:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 11:36 [PATCH 0/1] SMSC LAN9500 USB2.0 10/100 ethernet adapter driver Steve Glendinning
2008-09-09 11:36 ` [PATCH 1/1] " Steve Glendinning
2008-09-09 13:19 ` Ben Hutchings
2008-09-09 13:56 ` Steve.Glendinning
2008-09-09 14:02 ` Greg KH
2008-09-09 14:30 ` Ben Hutchings [this message]
2008-09-10 5:07 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2008-09-15 15:33 [PATCH 0/1] " Steve Glendinning
2008-09-15 15:33 ` [PATCH 1/1] " Steve Glendinning
2008-09-29 14:30 [PATCH 0/1] " Steve Glendinning
2008-09-29 14:30 ` [PATCH 1/1] " Steve Glendinning
2008-10-01 11:14 ` Ben Hutchings
2008-10-02 15:27 [PATCH 0/1] " Steve Glendinning
2008-10-02 15:27 ` [PATCH 1/1] " Steve Glendinning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1220970610.2381.64.camel@achroite \
--to=bhutchings@solarflare.com \
--cc=catalin.marinas@arm.com \
--cc=dbrownell@users.sourceforge.net \
--cc=greg@kroah.com \
--cc=ian.saturley@smsc.com \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=steve.glendinning@smsc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).