Grant Likely | 1 Jul 01:03 2010

Re: [PATCH] spi: davinci: Added support for chip select using gpio

On Mon, Jun 28, 2010 at 12:47 AM, Raffaele Recalcati
<lamiaposta71 <at>> wrote:
> From: Raffaele Recalcati <raffaele.recalcati <at>>
>    It is not everytime possible, due to hardware constraints,
>    to use the hw chip select available on spi port.
>    So I add this possibility using a gpio as chip select.
>    If controller_data variable is not null it is
>    the gpio to be used as chip select.
>    The default case is compatible with evmdm365.
>    This patch has been developed against the
>    git tree and has been tested on bmx board (similar to dm365 evm but with
>    gpio as spi chip select).
> Signed-off-by: Raffaele Recalcati <raffaele.recalcati <at>>
> Signed-off-by: Davide Bonfanti <davide.bonfanti <at>>

The davinci SPI driver is getting completely replaced (as soon as I
receive the respun patches), and I assume this patch will no longer
apply after the fact, so I'm not going to pick this patch up.  You
should coordinate with Brian Niebuhr to get this feature into his new


> ---
>  arch/arm/mach-davinci/dm365.c |   10 ++++++----
>  drivers/spi/davinci_spi.c     |   27 ++++++++++++++++++---------
(Continue reading)

H. Peter Anvin | 1 Jul 01:05 2010

Re: [PATCH] x86, Calgary: Increase max PHB number

On 06/30/2010 02:49 PM, Darrick J. Wong wrote:
> Newer systems (x3950M2) can have 48 PHBs per chassis and 4 chassis, so bump the
> limits up and provide an explanation of the requirements for each class.  Since
> we can't have more than 256 PCI buses in these systems, we don't need the array
> check.

The 384-entry patch is already upstream.  Can you send a patch relative
to current -linus?


Linus Torvalds | 1 Jul 01:07 2010

Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim

On Wed, Jun 30, 2010 at 12:05 AM, Chris Wilson <chris <at>> wrote:
> Reviewing the patch again, we no longer set the default gfpmask on the
> inode to contain NORETRY and instead add the NORETRY at the one spot in
> the code where we are trying to do a large allocation and our shrinker
> would be prevented from running (due to contention on struct_mutex).
> I do not know how this causes memory corruption across hibernate and would
> appreciate any insights.

Hmm. More likely is the __GFP_MOVABLE flag, I think.

That commit changes the page cache allocation to use

+                                          mapping_gfp_mask (mapping) |
+                                          __GFP_COLD |
+                                          gfpmask);

if I read it right. And the default mapping_gfp_mask() is
GFP_HIGHUSER_MOVABLE, so I think you get all of
set by default.

The old code didn't just play games with ~__GFP_NORETRY and change
that at runtime (which was buggy - no locking, no protection, no
nothing), it also initialized the gfp mask. And that code also got

-       /* Basically we want to disable the OOM killer and handle ENOMEM
-        * ourselves by sacrificing pages from cached buffers.
(Continue reading)

Linus Torvalds | 1 Jul 01:10 2010

Re: [RFC PATCH 1/1] PCI: skip release and reallocation of io port resources

On Wed, Jun 30, 2010 at 2:15 PM, Ram Pai <linuxram <at>> wrote:
>       PCI: skip release and reallocation of io port resources

Gaah. This still looks like just total ad-hoc hackery. The logic for
it all seems very fragile, just a random case made up from the one
failing issue. There's no underlying logic or design to it.

I still think that we should just make people explicitly ask for a
blank slate if the bios allocations don't work out. Rather than trying
to fix it up automatically, which has been a total rats nest of random

Dmitry Eremin-Solenikov | 1 Jul 01:12 2010

Re: [PATCH 06/33] Removing dead SHARPSL_LOCOMO

Christoph Egger wrote:

> SHARPSL_LOCOMO doesn't exist in Kconfig, therefore removing all
> references for it from the source code.

Hmmm. Shouldn't this be instead just SHARP_LOCOMO?

> Signed-off-by: Christoph Egger <siccegge <at>> ---


With best wishes

David Howells | 1 Jul 01:15 2010

Re: [PATCH 0/3] Extended file stat functions [ver #2]

Andreas Dilger <adilger@...> wrote:

> For the cost of those extra bytes it would definitely save a lot of extra
> complexity in every application packing and unpacking the struct.  At a
> minimum put a 32-bit padding that is zero-filled for now.

Blech.  I'd prefer to just expand the fields to 64-bits.

Note that you can't just arbitrarily pass a raw 64-bit UID, say, back to
vfs_getattr() and expect it to be coped with.  Those stat syscalls that return
32-bit (or even 16-bit) would have to do something with it, and glibc would
have to do something with it.

I think we'd need extra request bits to ask for the longer UID/GID - at which
point the extra result data can be appended and extra capacity in the basic
part of the struct is not required.

> > so perhaps something like:
> > 
> > 	struct xstat_u128 { unsigned long long lsw, msw; };
> > 
> > however, I suspect the kernel will require a bit of reengineering to handle
> > a pgoff_t and loff_t of 128-bits.
> Well, not any different from having 32-bit platforms work with two 32-bit
> values for 64-bit offsets today, except that we would be doing this with two
> 64-bit values.

gcc for 32-bit platforms can handle 64-bit numbers.  gcc doesn't handle 128-bit
(Continue reading)

Anthony Liguori | 1 Jul 01:24 2010

Re: [PATCHv2] vhost-net: add dhclient work-around from userspace

On 06/30/2010 05:31 PM, Michael S. Tsirkin wrote:
> On Wed, Jun 30, 2010 at 05:08:11PM -0500, Anthony Liguori wrote:
>> On 06/29/2010 08:04 AM, Michael S. Tsirkin wrote:
>>> On Tue, Jun 29, 2010 at 12:36:47AM -0700, David Miller wrote:
>>>> From: "Michael S. Tsirkin"<mst <at>>
>>>> Date: Mon, 28 Jun 2010 13:08:07 +0300
>>>>> Userspace virtio server has the following hack
>>>>> so guests rely on it, and we have to replicate it, too:
>>>>> Use port number to detect incoming IPv4 DHCP response packets,
>>>>> and fill in the checksum for these.
>>>>> The issue we are solving is that on linux guests, some apps
>>>>> that use recvmsg with AF_PACKET sockets, don't know how to
>>>>> handle CHECKSUM_PARTIAL;
>>>>> The interface to return the relevant information was added
>>>>> in 8dc4194474159660d7f37c495e3fc3f10d0db8cc,
>>>>> and older userspace does not use it.
>>>>> One important user of recvmsg with AF_PACKET is dhclient,
>>>>> so we add a work-around just for DHCP.
>>>>> Don't bother applying the hack to IPv6 as userspace virtio does not
>>>>> have a work-around for that - let's hope guests will do the right
>>>>> thing wrt IPv6.
(Continue reading)

H. Peter Anvin | 1 Jul 01:27 2010

Re: [PATCH 0/3] Extended file stat functions [ver #2]

On 06/30/2010 04:15 PM, David Howells wrote:
> gcc for 32-bit platforms can handle 64-bit numbers.  gcc doesn't handle 128-bit
> numbers.

gcc for 64-bit platforms does handle 128-bit numbers, but I don't think
it does on 32-bit platforms.

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at>
More majordomo info at

David Howells | 1 Jul 01:36 2010

[PATCH] Add a pair of system calls to make extended file stats available [ver #3]

Add a pair of system calls to make extended file stats available, including
file creation time, inode version and data version where available through the
underlying filesystem.

[This depends on the previously posted pair of patches to (a) constify a number
 of syscall string and buffer arguments and (b) rearrange AFS's use of
 i_version and i_generation].

The following structures are defined for their use:

	struct xstat_parameters {
		unsigned long long	request_mask;

	struct xstat_dev {
		unsigned int		major, minor;

	struct xstat_time {
		unsigned long long	tv_sec, tv_nsec;

	struct xstat {
		unsigned int		st_mode;
		unsigned int		st_nlink;
		unsigned int		st_uid;
		unsigned int		st_gid;
		struct xstat_dev	st_rdev;
		struct xstat_dev	st_dev;
		struct xstat_time	st_atime;
(Continue reading)

Randy Dunlap | 1 Jul 01:40 2010

Re: [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management

On Tue, 29 Jun 2010 22:55:48 -0700 Zach Pfeffer wrote:

> This patch contains the documentation for the API, termed the Virtual
> Contiguous Memory Manager. Its use would allow all of the IOMMU to VM,
> VM to device and device to IOMMU interoperation code to be refactored
> into platform independent code.
> Comments, suggestions and criticisms are welcome and wanted.
> Signed-off-by: Zach Pfeffer <zpfeffer <at>>
> ---
>  Documentation/vcm.txt |  583 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 583 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/vcm.txt
> diff --git a/Documentation/vcm.txt b/Documentation/vcm.txt
> new file mode 100644
> index 0000000..d29c757
> --- /dev/null
> +++ b/Documentation/vcm.txt
>  <at>  <at>  -0,0 +1,583  <at>  <at> 
> +What is this document about?
> +============================
> +
> +This document covers how to use the Virtual Contiguous Memory Manager
> +(VCMM), how the first implmentation works with a specific low-level
> +Input/Output Memory Management Unit (IOMMU) and the way the VCMM is used
> +from user-space. It also contains a section that describes why something
> +like the VCMM is needed in the kernel.
> +
(Continue reading)