twitter: linux.kernel - 25 new messages in 20 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* [PATCH -next] scsi: RAID_ATTRS depends on SCSI - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/71c7bcb275f3e323?hl=en
* memcg: dirty pages instrumentation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
* [patch] should use scheduler sync hint in tcp_prequeue()? - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/e8dcdc3429ff4045?hl=en
* crypto, Speed testing support for ghash - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a321188e29e359e3?hl=en
* sata_nv times out for BD-ROM iHOS104-08 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/301737bea068ddda?hl=en
* RFC directio: partial writes support - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/5f95397237af6d75?hl=en
* perf_events: add sampling period randomization support - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/54108222cc877582?hl=en
* sound/pci/hda/hda_codec.c: various coding style fixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/06de93666c701ff7?hl=en
* please pull infiniband.git - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d9f49d52282a9f5f?hl=en
* sound/oss/v_midi.h: Checkpatch cleanup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b800dd4f0f5d9f27?hl=en
* : Networking - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3b5e7c1b17c71f01?hl=en
* sparc: use asm-generic/scatterlist.h - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/18cde759295738d0?hl=en
* Regression 2.6.32 -> 2.6.33, Kernel needs a helping key to boot :) - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/77b179817e736908?hl=en
* usbaudio: Fix wrong bitrate for Creative Creative VF0470 Live Cam - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/829b9e9d076b418c?hl=en
* pktcdvd: improve BKL and compat_ioctl.c usage - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/34267fa09ddc834e?hl=en
* mtd/nand/r852: fix build for CONFIG_PM=n - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/56fd47df335c0b65?hl=en
* compiler: prevent dead store elimination - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1182a2565515906c?hl=en
* percpu changes for 2.6.34-rc1 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9916c24c50e83791?hl=en
* USB mass storage and ARM cache coherency - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
* rcu: suppress RCU lockdep warnings during early boot - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/793bcd4fc844361a?hl=en

==============================================================================
TOPIC: [PATCH -next] scsi: RAID_ATTRS depends on SCSI
http://groups.google.com/group/linux.kernel/t/71c7bcb275f3e323?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:30 am
From: Ingo Molnar

* Randy Dunlap <rdunlap@xenotime.net> wrote:

> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> raid_class uses scsi interfaces, so it should depend on SCSI.
> Otherwise build errors occur when RAID_ATTRS=y and SCSI=m:
>
> ERROR: "raid_class_release" [drivers/scsi/mpt2sas/mpt2sas.ko] undefined!
> ERROR: "raid_class_attach" [drivers/scsi/mpt2sas/mpt2sas.ko] undefined!

FYI, this build bug has been pushed upstream via the SCSI tree, without
Randy's fix.

I have applied Randy's drivers/scsi/Kconfig fix to tip:out-of-tree and that
solves the build bug here.

Tested-by: Ingo Molnar <mingo@elte.hu>

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: memcg: dirty pages instrumentation
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:40 am
From: Andrea Righi

On Tue, Mar 02, 2010 at 01:09:24PM +0200, Kirill A. Shutemov wrote:
> On Tue, Mar 2, 2010 at 1:02 PM, Andrea Righi <arighi@develer.com> wrote:
> > On Tue, Mar 02, 2010 at 12:11:10PM +0200, Kirill A. Shutemov wrote:
> >> On Mon, Mar 1, 2010 at 11:23 PM, Andrea Righi <arighi@develer.com> wrote:
> >> > Apply the cgroup dirty pages accounting and limiting infrastructure to
> >> > the opportune kernel functions.
> >> >
> >> > Signed-off-by: Andrea Righi <arighi@develer.com>
> >> > ---
> >> > �fs/fuse/file.c � � �| � �5 +++
> >> > �fs/nfs/write.c � � �| � �4 ++
> >> > �fs/nilfs2/segment.c | � 10 +++++-
> >> > �mm/filemap.c � � � �| � �1 +
> >> > �mm/page-writeback.c | � 84 ++++++++++++++++++++++++++++++++------------------
> >> > �mm/rmap.c � � � � � | � �4 +-
> >> > �mm/truncate.c � � � | � �2 +
> >> > �7 files changed, 76 insertions(+), 34 deletions(-)
> >> >
> >> > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> >> > index a9f5e13..dbbdd53 100644
> >> > --- a/fs/fuse/file.c
> >> > +++ b/fs/fuse/file.c
> >> > @@ -11,6 +11,7 @@
> >> > �#include <linux/pagemap.h>
> >> > �#include <linux/slab.h>
> >> > �#include <linux/kernel.h>
> >> > +#include <linux/memcontrol.h>
> >> > �#include <linux/sched.h>
> >> > �#include <linux/module.h>
> >> >
> >> > @@ -1129,6 +1130,8 @@ static void fuse_writepage_finish(struct fuse_conn *fc, struct fuse_req *req)
> >> >
> >> > � � � �list_del(&req->writepages_entry);
> >> > � � � �dec_bdi_stat(bdi, BDI_WRITEBACK);
> >> > + � � � mem_cgroup_update_stat(req->pages[0],
> >> > + � � � � � � � � � � � MEM_CGROUP_STAT_WRITEBACK_TEMP, -1);
> >> > � � � �dec_zone_page_state(req->pages[0], NR_WRITEBACK_TEMP);
> >> > � � � �bdi_writeout_inc(bdi);
> >> > � � � �wake_up(&fi->page_waitq);
> >> > @@ -1240,6 +1243,8 @@ static int fuse_writepage_locked(struct page *page)
> >> > � � � �req->inode = inode;
> >> >
> >> > � � � �inc_bdi_stat(mapping->backing_dev_info, BDI_WRITEBACK);
> >> > + � � � mem_cgroup_update_stat(tmp_page,
> >> > + � � � � � � � � � � � MEM_CGROUP_STAT_WRITEBACK_TEMP, 1);
> >> > � � � �inc_zone_page_state(tmp_page, NR_WRITEBACK_TEMP);
> >> > � � � �end_page_writeback(page);
> >> >
> >> > diff --git a/fs/nfs/write.c b/fs/nfs/write.c
> >> > index b753242..7316f7a 100644
> >> > --- a/fs/nfs/write.c
> >> > +++ b/fs/nfs/write.c
> >> > @@ -439,6 +439,7 @@ nfs_mark_request_commit(struct nfs_page *req)
> >> > � � � � � � � � � � � �req->wb_index,
> >> > � � � � � � � � � � � �NFS_PAGE_TAG_COMMIT);
> >> > � � � �spin_unlock(&inode->i_lock);
> >> > + � � � mem_cgroup_update_stat(req->wb_page, MEM_CGROUP_STAT_UNSTABLE_NFS, 1);
> >> > � � � �inc_zone_page_state(req->wb_page, NR_UNSTABLE_NFS);
> >> > � � � �inc_bdi_stat(req->wb_page->mapping->backing_dev_info, BDI_UNSTABLE);
> >> > � � � �__mark_inode_dirty(inode, I_DIRTY_DATASYNC);
> >> > @@ -450,6 +451,7 @@ nfs_clear_request_commit(struct nfs_page *req)
> >> > � � � �struct page *page = req->wb_page;
> >> >
> >> > � � � �if (test_and_clear_bit(PG_CLEAN, &(req)->wb_flags)) {
> >> > + � � � � � � � mem_cgroup_update_stat(page, MEM_CGROUP_STAT_UNSTABLE_NFS, -1);
> >> > � � � � � � � �dec_zone_page_state(page, NR_UNSTABLE_NFS);
> >> > � � � � � � � �dec_bdi_stat(page->mapping->backing_dev_info, BDI_UNSTABLE);
> >> > � � � � � � � �return 1;
> >> > @@ -1273,6 +1275,8 @@ nfs_commit_list(struct inode *inode, struct list_head *head, int how)
> >> > � � � � � � � �req = nfs_list_entry(head->next);
> >> > � � � � � � � �nfs_list_remove_request(req);
> >> > � � � � � � � �nfs_mark_request_commit(req);
> >> > + � � � � � � � mem_cgroup_update_stat(req->wb_page,
> >> > + � � � � � � � � � � � � � � � MEM_CGROUP_STAT_UNSTABLE_NFS, -1);
> >> > � � � � � � � �dec_zone_page_state(req->wb_page, NR_UNSTABLE_NFS);
> >> > � � � � � � � �dec_bdi_stat(req->wb_page->mapping->backing_dev_info,
> >> > � � � � � � � � � � � � � � � �BDI_UNSTABLE);
> >> > diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c
> >> > index ada2f1b..aef6d13 100644
> >> > --- a/fs/nilfs2/segment.c
> >> > +++ b/fs/nilfs2/segment.c
> >> > @@ -1660,8 +1660,11 @@ nilfs_copy_replace_page_buffers(struct page *page, struct list_head *out)
> >> > � � � �} while (bh = bh->b_this_page, bh2 = bh2->b_this_page, bh != head);
> >> > � � � �kunmap_atomic(kaddr, KM_USER0);
> >> >
> >> > - � � � if (!TestSetPageWriteback(clone_page))
> >> > + � � � if (!TestSetPageWriteback(clone_page)) {
> >> > + � � � � � � � mem_cgroup_update_stat(clone_page,
> >>
> >> s/clone_page/page/
> >
> > mmh... shouldn't we use the same page used by TestSetPageWriteback() and
> > inc_zone_page_state()?
>
> Sorry, I've commented wrong hunk. It's for the next one.

Yes. Good catch! Will fix in the next version.

Thanks,
-Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [patch] should use scheduler sync hint in tcp_prequeue()?
http://groups.google.com/group/linux.kernel/t/e8dcdc3429ff4045?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 3:40 am
From: Mike Galbraith

On Tue, 2010-03-02 at 12:27 +0100, Eric Dumazet wrote:

> This wake_up_interruptible_sync_poll() change might be good for loopback
> communications (and pleases tbench), but is it desirable for regular
> multi flows NIC traffic ?

If you can take high frequency cache misses, likely yes. For localhost,
that's pretty much guaranteed currently (ergo the question).

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Mar 2 2010 3:40 am
From: Peter Zijlstra

On Tue, 2010-03-02 at 12:27 +0100, Eric Dumazet wrote:
> My Q6600 has shared caches

Isn't core2quad a dual die construct, having 2 cache domains?

== 3 of 3 ==
Date: Tues, Mar 2 2010 3:50 am
From: Mike Galbraith

On Tue, 2010-03-02 at 12:32 +0100, Peter Zijlstra wrote:
> On Tue, 2010-03-02 at 12:27 +0100, Eric Dumazet wrote:
> > My Q6600 has shared caches
>
> Isn't core2quad a dual die construct, having 2 cache domains?

(yes.. am I using wrong terminology?)

==============================================================================
TOPIC: crypto, Speed testing support for ghash
http://groups.google.com/group/linux.kernel/t/a321188e29e359e3?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:40 am
From: Herbert Xu

On Mon, Mar 01, 2010 at 04:06:44PM +0800, Huang Ying wrote:
> Because ghash needs setkey, the setkey and keysize template support
> for test_hash_speed is added.
>
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> ---
> crypto/tcrypt.c | 122 +++++++++++++++++++++++++++++++++++---------------------
> crypto/tcrypt.h | 1
> 2 files changed, 78 insertions(+), 45 deletions(-)
>
> --- a/crypto/tcrypt.c
> +++ b/crypto/tcrypt.c
> @@ -395,12 +395,13 @@ out:
> }
>
> static void test_hash_speed(const char *algo, unsigned int sec,
> - struct hash_speed *speed)
> + struct hash_speed *speed, u8 *keysize)

Can we possibly move keysize into struct hash_speed to reduce
the churn?

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: sata_nv times out for BD-ROM iHOS104-08
http://groups.google.com/group/linux.kernel/t/301737bea068ddda?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:40 am
From: Tejun Heo

Hello,

On 03/01/2010 02:24 AM, Cengiz Günay wrote:
> Before and after the swncq-atapi-pio patch I still get awful read
> times from the BD-ROM drive:
>
> $ time dd if=/dev/sr0 of=/dev/null bs=64k count=1024
> 67108864 bytes (67 MB) copied, 106.945 seconds, 628 kB/s
> => real 1m46.977s

Hmmm... the drive is timing out even on 4k READ10's. This shouldn't
really be happening. Can you please try this one?

--
tejun

==============================================================================
TOPIC: RFC directio: partial writes support
http://groups.google.com/group/linux.kernel/t/5f95397237af6d75?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 3:40 am
From: Jan Kara

On Tue 02-03-10 20:25:02, Nick Piggin wrote:
> On Mon, Mar 01, 2010 at 03:21:49PM -0800, Andrew Morton wrote:
> > On Thu, 25 Feb 2010 15:45:58 +0300
> > Dmitry Monakhov <dmonakhov@openvz.org> wrote:
> >
> > > Can someone please describe me why directio deny partial writes.
> > > For example if someone try to write 100Mb but file system has less
> > > data it return ENOSPC in the middle of block allocation.
> > > All allocated blocks will be truncated (it may be 100Mb -4k) end
> > > ENOSPC will be returned. As far as i remember direct_io always act
> > > like this, but i never asked why?
> > > Why do we have to give up all the progress we made?
> > > In fact partial writes are possible in case of holes, when we
> > > fall back to buffered write. XFS implemented partial writes.
> >
> > The problem with direct-io writes is that the writes don't necessarily
> > complete in file-offset-ascending order. So if we've issued 50 write
> > BIOs and then hit an EIO on a BIO then we could have a hunk of
> > unwritten data with newly-writted data either side of it. If we get a
> > bunch of discontiguous EIO BIOs coming in then the problem gets even
> > messier - we have a span of disk which has a random mix of
> > correctly-written and not-correctly-written runs of sectors. What do
> > we do with that?
>
> Hmm, what if we're filling in a hole with direct IO? I don't see where
> blocks allocated in DIO code will be trimmed on a failed write (because
> it's within isize). This could cause uninitalized data of the block to
> leak couldn't it?
The trick is that blockdev_direct_IO is defined to pass
DIO_SKIP_HOLES to __blockdev_direct_IO. Thus e.g. ext2 or ext3 will just
fail the direct IO if there is a hole and we fall back to buffered IO
which should handle that just fine.

Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Mar 2 2010 4:40 am
From: Nick Piggin

On Tue, Mar 02, 2010 at 12:34:06PM +0100, Jan Kara wrote:
> On Tue 02-03-10 20:25:02, Nick Piggin wrote:
> > On Mon, Mar 01, 2010 at 03:21:49PM -0800, Andrew Morton wrote:
> > > On Thu, 25 Feb 2010 15:45:58 +0300
> > > Dmitry Monakhov <dmonakhov@openvz.org> wrote:
> > >
> > > > Can someone please describe me why directio deny partial writes.
> > > > For example if someone try to write 100Mb but file system has less
> > > > data it return ENOSPC in the middle of block allocation.
> > > > All allocated blocks will be truncated (it may be 100Mb -4k) end
> > > > ENOSPC will be returned. As far as i remember direct_io always act
> > > > like this, but i never asked why?
> > > > Why do we have to give up all the progress we made?
> > > > In fact partial writes are possible in case of holes, when we
> > > > fall back to buffered write. XFS implemented partial writes.
> > >
> > > The problem with direct-io writes is that the writes don't necessarily
> > > complete in file-offset-ascending order. So if we've issued 50 write
> > > BIOs and then hit an EIO on a BIO then we could have a hunk of
> > > unwritten data with newly-writted data either side of it. If we get a
> > > bunch of discontiguous EIO BIOs coming in then the problem gets even
> > > messier - we have a span of disk which has a random mix of
> > > correctly-written and not-correctly-written runs of sectors. What do
> > > we do with that?
> >
> > Hmm, what if we're filling in a hole with direct IO? I don't see where
> > blocks allocated in DIO code will be trimmed on a failed write (because
> > it's within isize). This could cause uninitalized data of the block to
> > leak couldn't it?
> The trick is that blockdev_direct_IO is defined to pass
> DIO_SKIP_HOLES to __blockdev_direct_IO. Thus e.g. ext2 or ext3 will just
> fail the direct IO if there is a hole and we fall back to buffered IO
> which should handle that just fine.

OK yes I see, I missed that.

==============================================================================
TOPIC: perf_events: add sampling period randomization support
http://groups.google.com/group/linux.kernel/t/54108222cc877582?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:50 am
From: Peter Zijlstra

On Tue, 2010-03-02 at 11:53 +0100, Robert Richter wrote:
>
> Only adding the random value will lead to longer sample periods on
> average. To compensate this you could calculate something like:
>
> event->hw.sample_period = event->attr.sample_period + (new_seed & mask) - (mask >> 1);

Or cheat and do something like:

sample_period ^= (new_seed & mask);

==============================================================================
TOPIC: sound/pci/hda/hda_codec.c: various coding style fixes
http://groups.google.com/group/linux.kernel/t/06de93666c701ff7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:00 am
From: Takashi Iwai

At Sun, 28 Feb 2010 20:16:53 +0100,
Norberto Lopes wrote:
>
>
> Signed-off-by: Norberto Lopes <nlopes.ml@gmail.com>

Applied now. Thanks.

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: please pull infiniband.git
http://groups.google.com/group/linux.kernel/t/d9f49d52282a9f5f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:00 am
From: Tziporet Koren

On 3/2/2010 9:56 AM, Roland Dreier wrote:
> Linus, please pull from
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
>
> This tree is also available from kernel.org mirrors at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-linus
>
> This will get my current pile for the 2.6.34 merge window:
>
What about the pending patches for:
- XRC
- IBoE
- SRIOV support for mlx4

Thanks
Tziporet

==============================================================================
TOPIC: sound/oss/v_midi.h: Checkpatch cleanup
http://groups.google.com/group/linux.kernel/t/b800dd4f0f5d9f27?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:00 am
From: Takashi Iwai

At Sat, 27 Feb 2010 17:51:03 +0100,
Andrea Gelmini wrote:
>
> sound/oss/v_midi.h:5: ERROR: code indent should use tabs where possible
> sound/oss/v_midi.h:7: ERROR: trailing whitespace
>
> Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>

Applied all three patches for sound/* now. Thanks.

==============================================================================
TOPIC: : Networking
http://groups.google.com/group/linux.kernel/t/3b5e7c1b17c71f01?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 4:10 am
From: David Miller

From: David Miller <davem@davemloft.net>
Date: Sun, 28 Feb 2010 23:05:35 -0800 (PST)

> Please pull, thanks a lot!
>
> The following changes since commit 30ff056c42c665b9ea535d8515890857ae382540:
> Linus Torvalds (1):
> Merge branch 'x86-uv-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-next-2.6.git master

Linus, if you haven't pulled in the networking tree yet, please pull
again as I just pushed the following bug fixes into there tonight.

Thanks!

The following changes since commit 47871889c601d8199c51a4086f77eebd77c29b0b:
David S. Miller (1):
Merge branch 'master' of /home/davem/src/GIT/linux-2.6/

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/net-next-2.6.git master

Eric Dumazet (1):
net: fix protocol sk_buff field

Herton Ronaldo Krzesinski (1):
sis190: fix cable detect via link status poll

Jiri Pirko (1):
virtio_net: remove forgotten assignment

Sathya Perla (1):
be2net: fix tx completion polling

Sridhar Samudrala (1):
bridge: Fix build error when IGMP_SNOOPING is not enabled

drivers/net/benet/be_cmds.c | 26 +++++++++++-----------
drivers/net/benet/be_cmds.h | 2 +-
drivers/net/benet/be_main.c | 47 +++++++++++++++++++++----------------------
drivers/net/sis190.c | 23 ++++++++++++++++----
drivers/net/virtio_net.c | 1 -
include/linux/skbuff.h | 2 +-
net/bridge/br_private.h | 14 ++++++++----
7 files changed, 65 insertions(+), 50 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: sparc: use asm-generic/scatterlist.h
http://groups.google.com/group/linux.kernel/t/18cde759295738d0?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 4:10 am
From: Arnd Bergmann

On Tuesday 02 March 2010, FUJITA Tomonori wrote:
> If we go with such approach, then we could use something like the
> following. There are only two kinds of scatterlist definitions (use
> dma_length or not) so we can cover all the architectures.
>
> diff --git a/include/asm-generic/scatterlist.h b/include/asm-generic/scatterlist.h
> index 8b94544..1bf620d 100644
> --- a/include/asm-generic/scatterlist.h
> +++ b/include/asm-generic/scatterlist.h
> @@ -11,7 +11,9 @@ struct scatterlist {
> unsigned int offset;
> unsigned int length;
> dma_addr_t dma_address;
> +#ifdef CONFIG_NEED_SG_DMA_LENGTH
> unsigned int dma_length;
> +

twitter

Tuesday, March 2, 2010

linux.kernel - 25 new messages in 20 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts