All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: netdev@vger.kernel.org, linux-net-drivers@solarflare.com
Subject: Re: New driver "sfc" for Solarstorm SFC4000 controller.
Date: Fri, 2 May 2008 11:09:08 -0700	[thread overview]
Message-ID: <20080502110908.93c79d81.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080502160530.GN14219@solarflare.com>

On Fri, 2 May 2008 17:05:35 +0100 Ben Hutchings <bhutchings@solarflare.com> wrote:

> > Oh dear, it found
> > 
> > #5617: FILE: drivers/net/sfc/falcon.c:1877:
> > +               if (*(volatile u32 *)dma_done == FALCON_STATS_DONE)
> > 
> > which was naughty of you.  Perhaps this was already discussed in review
> > with the people who actually know what they're talking about.
> 
> There wasn't any specific discussion of this.  Is it wrong?  We want to
> prevent the compiler from caching *dma_done, which is itself written by DMA.

Documentation/volatile-considered-harmful.txt has some dicussion.

> ...
> > > +#define EFX_DRIVER_VERSION	"2.2.0136"
> > 
> > I would suggest that you remove this.  It's just not a useful way of
> > establishing what version of the driver your users are running.  We use the
> > kernel version information for this.
>  
> This is common practice for net drivers.  Maybe we are in our own little
> world on netdev?

That would make it easy for a researcher to work out how often we change a
driver versus how often we increment its private version number.

> > > +static inline int efx_init_rx_buffer_page(struct efx_rx_queue *rx_queue,
> > > +					  struct efx_rx_buffer *rx_buf)
> > > +{
> > > +	struct efx_nic *efx = rx_queue->efx;
> > > +	int bytes, space, offset;
> > > +
> > > +	bytes = efx->rx_buffer_len - EFX_PAGE_IP_ALIGN;
> > > +
> > > +	/* If there is space left in the previously allocated page,
> > > +	 * then use it. Otherwise allocate a new one */
> > > +	rx_buf->page = rx_queue->buf_page;
> > > +	if (rx_buf->page == NULL) {
> > > +		dma_addr_t dma_addr;
> > > +
> > > +		rx_buf->page = alloc_pages(__GFP_COLD | __GFP_COMP | GFP_ATOMIC,
> > > +					   efx->rx_buffer_order);
> > 
> > I don't think we should be using the open-coded __GFP_COMP here.  That's
> > more an mm-internal thing.
> 
> What's the alternative?

Just remove the __GFP_COMP, I expect.  __GFP_COMP will ask the page
allocator to add extra book-keeping info to the pageframe (via
prep_compound_page()).  I doubt if the driver uses that information.



  reply	other threads:[~2008-05-02 18:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200804301925.m3UJPc72001651@hera.kernel.org>
2008-05-01 19:08 ` New driver "sfc" for Solarstorm SFC4000 controller Andrew Morton
2008-05-02 16:05   ` Ben Hutchings
2008-05-02 18:09     ` Andrew Morton [this message]
2008-05-06 12:50       ` Ben Hutchings
2008-05-06 14:24         ` Andrew Morton
2008-05-06 15:04           ` Ben Hutchings
2008-05-06 15:12             ` Andrew Morton
2008-05-06 15:40               ` Ben Hutchings
2008-05-07 17:55         ` Ben Hutchings
2008-05-02 19:10   ` Michael Brown
2008-05-03 20:01     ` Ben Hutchings

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=20080502110908.93c79d81.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bhutchings@solarflare.com \
    --cc=linux-net-drivers@solarflare.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.