twitter: linux.kernel - 26 new messages in 18 topics

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

Today's topics:

* linux-next: Tree for March 2 (watchdog) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9c4fcb17427b7c42?hl=en
* : input: add support for VirtualBox touchscreen emulation to the Lifebook
driver - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/36b703b3286dcd72?hl=en
* rfkill bug fixed in rfkill_set_sw_state - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b582a228f6a34070?hl=en
* slab: add memory hotplug support - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en
* drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/ce177a548e087e55?hl=en
* DMAENGINE: COH 901 318 cleanups - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2c9ff4fdb6df76fc?hl=en
* Memory management woes - order 1 allocation failures - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5fdc2e7e4a505944?hl=en
* staging/dt3155: use C99 syntax for struct initializer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9cec2d082c7dda5a?hl=en
* ahci: Introduce ahci_set_em_messages() - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/f52e7d83445abba6?hl=en
* gpio: add support for Janz VMOD-TTL Digital IO module - 3 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5450006d3264a022?hl=en
* add support for Janz MODULbus devices - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7c52c26fdbcb69cf?hl=en
* 2.6.33-rt3 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/05da5fcaf3f3a453?hl=en
* mmc: at91_mci: use DMA buffer for read - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ff951e3ca0c508c5?hl=en
* staging/dt3155: sparse cleanup of allocator code - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ad056ad04c6300fd?hl=en
* 2.6.33 problems - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3577fd3e959583de?hl=en
* memcg: dirty pages accounting and limiting infrastructure - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
* staging/dt3155: remove unused global "registers" - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1ca193c9b0fcc910?hl=en
* 2.6.33-git6 problem (compal-laptop) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/976017b47c27a185?hl=en

==============================================================================
TOPIC: linux-next: Tree for March 2 (watchdog)
http://groups.google.com/group/linux.kernel/t/9c4fcb17427b7c42?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:50 pm
From: Wim Van Sebroeck

Hi Randy,

Overlooked that one. Fixed now.

Thanks,
Wim.

> On 03/01/10 23:09, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20100301:
>
>
> linux-next-20100302/drivers/watchdog/wdt.c: In function 'wdt_ioctl':
> linux-next-20100302/drivers/watchdog/wdt.c:370: error: assignment of read-only variable 'ident'
> linux-next-20100302/drivers/watchdog/wdt.c:373: error: assignment of read-only variable 'ident'
> linux-next-20100302/drivers/watchdog/wdt.c:375: error: assignment of read-only variable 'ident'
> make[3]: *** [drivers/watchdog/wdt.o] Error 1
>
>
>
> --
> ~Randy
--
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: : input: add support for VirtualBox touchscreen emulation to the
Lifebook driver
http://groups.google.com/group/linux.kernel/t/36b703b3286dcd72?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 12:50 pm
From: Michael Thayer

Hello Dmitry,

Le jeudi 25 février 2010 à 02:17 -0800, Dmitry Torokhov a écrit :
> On Wed, Feb 24, 2010 at 12:46:29PM +0100, Michael Thayer wrote:
> > Le mercredi 24 février 2010 à 02:02 -0800, Dmitry Torokhov a écrit :
> > > On Tue, Feb 23, 2010 at 09:55:33PM +0100, Michael Thayer wrote:
> > > > I'm not sure, if we ended up doing a completely new device, how different it
> > > > would end up being. Emulating a touchscreen or a tablet makes sense for us as
> > > > these are both something known, which will work with existing systems without
> > > > too much tweaking
> > > > [snip]
> > > But the virtual mouse is not a touchscreen or a tablet, it behaves
> > > differently.
> > What would you suggest emulating that exists in the real world?
>
> There are not many real devices that have teh same characteristics as
> virtual mouse generating absolute coordinates. Umm, the closest would be
> a wacom tablet when used with its own mouse.
We decided in the end to emulate a USB tablet, as some other virtualisers do.
It works well out of the box with recent Linux distributions, and while older
ones recognise it as a touchpad (in fact they use it through /dev/input/mice),
it still provides a reasonable user experience until the user has installed our
guest drivers.

Thank you again for your comments and assistance.

Regards,

Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael.thayer@sun.com

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Haering

--
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 1:30 pm
From: Dmitry Torokhov

On Tue, Mar 02, 2010 at 09:44:48PM +0100, Michael Thayer wrote:
> Hello Dmitry,
>
> Le jeudi 25 février 2010 à 02:17 -0800, Dmitry Torokhov a écrit :
> > On Wed, Feb 24, 2010 at 12:46:29PM +0100, Michael Thayer wrote:
> > > Le mercredi 24 février 2010 à 02:02 -0800, Dmitry Torokhov a écrit :
> > > > On Tue, Feb 23, 2010 at 09:55:33PM +0100, Michael Thayer wrote:
> > > > > I'm not sure, if we ended up doing a completely new device, how different it
> > > > > would end up being. Emulating a touchscreen or a tablet makes sense for us as
> > > > > these are both something known, which will work with existing systems without
> > > > > too much tweaking
> > > > > [snip]
> > > > But the virtual mouse is not a touchscreen or a tablet, it behaves
> > > > differently.
> > > What would you suggest emulating that exists in the real world?
> >
> > There are not many real devices that have teh same characteristics as
> > virtual mouse generating absolute coordinates. Umm, the closest would be
> > a wacom tablet when used with its own mouse.
> We decided in the end to emulate a USB tablet, as some other virtualisers do.
> It works well out of the box with recent Linux distributions, and while older
> ones recognise it as a touchpad (in fact they use it through /dev/input/mice),

Yes, mousedev will provide workable approximation of standard mouse for
a device that provides absolute events. BTW, the fact that data from a
device is available from /dev/input/mice does not mean that device was
recognized as a mouse, a touchpad or something else. It just means that
kernel is able to approximate device as a standard PS/2 Expolorer mouse.

> it still provides a reasonable user experience until the user has installed our
> guest drivers.

It is your call but I would much rather if you worked on fixeng evdev to
work with your virtual device rather than having to install a new X
driver and going through the hoops trying to detect which one should be
used on a particular box. At least on Linux...

Thanks.

--
Dmitry
--
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/

== 3 of 3 ==
Date: Tues, Mar 2 2010 2:10 pm
From: Michael Thayer

Le mardi 02 mars 2010 à 13:28 -0800, Dmitry Torokhov a écrit :
> On Tue, Mar 02, 2010 at 09:44:48PM +0100, Michael Thayer wrote:
> > it still provides a reasonable user experience until the user has installed our
> > guest drivers.
>
> It is your call but I would much rather if you worked on fixeng evdev to
> work with your virtual device rather than having to install a new X
> driver and going through the hoops trying to detect which one should be
> used on a particular box. At least on Linux...
That wouldn't really help us much here, as we are talking about distributions
shipping X.Org Server 1.4 and earlier, and those distributions are no longer
going to get that sort of update (in those cases in which they are still
getting updates at all). Legacy support if you like.

Thanks again,

Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael.thayer@sun.com

==============================================================================
TOPIC: rfkill bug fixed in rfkill_set_sw_state
http://groups.google.com/group/linux.kernel/t/b582a228f6a34070?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:00 pm
From: Andrew Morton

Suitable cc's (from scripts/get_maintainer.pl) added.

On Fri, 26 Feb 2010 13:55:31 +0900
_________ <jh80.chung@samsung.com> wrote:

> Don___t work expected operation in __rfkill_set_sw_state.
> when rfkill initialized. Rfkill___s blocked & unblocked is operating on the
> contrary.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>
> ---
> net/rfkill/core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index c224cb2..dcc2d38 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -488,7 +488,7 @@ static void __rfkill_set_sw_state(struct rfkill
> *rfkill, bool blocked)
> if (rfkill->state & RFKILL_BLOCK_SW_SETCALL)
> bit = RFKILL_BLOCK_SW_PREV;
>
> - if (blocked)
> + if (!blocked)
> rfkill->state |= bit;
> else
> rfkill->state &= ~bit;

Are you sure? What problems were you observing with the existing code?
Please fully describe your hardware and the driver's behaviour.

The current code _looks_ OK to me. If bool `blocked' is true, we set
the RFKILL_BLOCK_SW bit?

==============================================================================
TOPIC: slab: add memory hotplug support
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 1:10 pm
From: David Rientjes

On Tue, 2 Mar 2010, Christoph Lameter wrote:

>
> Not sure how this would sync with slab use during node bootstrap and
> shutdown. Kame-san?
>

All the nodelist allocation and initialization is done during
MEM_GOING_ONLINE, so there should be no use of them until that
notification cycle is done and it has graduated to MEM_ONLINE: if there
are, there're even bigger problems because zonelist haven't even been
built for that pgdat yet. I can only speculate, but since Andi's
patchset did all this during MEM_ONLINE, where the bit is already set in
node_states[N_HIGH_MEMORY] and is passable to kmalloc_node(), this is
probably why additional hacks had to be added elsewhere.

Other than that, concurrent kmem_cache_create() is protected by
cache_chain_mutex.
--
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 1:20 pm
From: David Rientjes

On Tue, 2 Mar 2010, Andi Kleen wrote:

> The patch looks far more complicated than my simple fix.
>
> Is more complicated now better?
>

If you still believe these are "fixes," then perhaps you don't fully
understand the issue: slab completely lacked memory hotplug support when a
node is either being onlined or offlined that do not have hotadded or
hotremoved cpus. It's as simple as that.

To be fair, my patch may appear more complex because it implements full
memory hotplug support so that the nodelists are properly drained and
freed when the same memory regions you onlined for memory hot-add are now
offlined. Notice, also, how it touches no other slab code as implementing
new support for something shouldn't. There is no need for additional
hacks to be added in other slab code if you properly allocate and
initialize the nodelists for the memory being added before it is available
for use by the kernel.

If you'd test my patch out on your setup, that would be very helpful. I
can address any additional issues that you may undercover if you post the
oops while doing either memory online or offline.
--
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: drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
http://groups.google.com/group/linux.kernel/t/ce177a548e087e55?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:10 pm
From: Surbhi Palande

BugLink: https://bugs.launchpad.net/bugs/515246

Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed
when it is open. This leads to a "no connectors reported" error at startup.
Blacklisting them, to always return a connected status for the default
lvds connector.

Signed-off-by: Surbhi Palande <surbhi.palande@canonical.com>
---
Due to lack of hardware, I have not tested this patch on my own. Further
testing shall be helpful.

drivers/gpu/drm/i915/intel_lvds.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index c2e8a45..b94a5e5 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -643,6 +643,20 @@ static const struct dmi_system_id bad_lid_status[] = {
DMI_MATCH(DMI_BOARD_NAME, "M5x0N"),
},
},
+ {
+ .ident = "Sony VGN-BX196VP",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_BOARD_NAME, "VGN-BX196VP"),
+ },
+ },
+ {
+ .ident = "Dell Inspiron 700m",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
+ DMI_MATCH(DMI_BOARD_NAME, "Inspiron 700m"),
+ },
+ },
{ }
};

--
1.6.3.3

==============================================================================
TOPIC: DMAENGINE: COH 901 318 cleanups
http://groups.google.com/group/linux.kernel/t/2c9ff4fdb6df76fc?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 1:10 pm
From: Dan Williams

On Tue, Mar 2, 2010 at 1:12 PM, Linus Walleij
<linus.walleij@stericsson.com> wrote:
> � � � �if (cohc->nbr_active_done)
> + � � � /*
> + � � � �* If another interrupt fired while the tasklet was scheduling,
> + � � � �* we don't get called twice, so we have this number of active
> + � � � �* counter that keep track of the number of IRQs expected to
> + � � � �* be handled for this channel. If there happen to be more than
> + � � � �* one IRQ to be ack:ed, we simply schedule this tasklet again.
> + � � � �*/
> � � � � � � � �cohc->nbr_active_done--;

Checkpatch made a justifiable wimper about this. It looks like you
wanted to delete that if() according to the previous unified patch?
--
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 1:30 pm
From: Dan Williams

On Tue, Mar 2, 2010 at 2:06 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Mar 2, 2010 at 1:12 PM, Linus Walleij
> <linus.walleij@stericsson.com> wrote:
>> � � � �if (cohc->nbr_active_done)
>> + � � � /*
>> + � � � �* If another interrupt fired while the tasklet was scheduling,
>> + � � � �* we don't get called twice, so we have this number of active
>> + � � � �* counter that keep track of the number of IRQs expected to
>> + � � � �* be handled for this channel. If there happen to be more than
>> + � � � �* one IRQ to be ack:ed, we simply schedule this tasklet again.
>> + � � � �*/
>> � � � � � � � �cohc->nbr_active_done--;
>
> Checkpatch made a justifiable wimper about this. �It looks like you
> wanted to delete that if() according to the previous unified patch?
>

Looks like it gets deleted later on in patch #3. I took a stab at
fixing it up[1], or you can just send me a new series if that does not
look right to you.

--
Dan

[1]: http://git.kernel.org/?p=linux/kernel/git/djbw/async_tx.git;a=shortlog;h=refs/heads/coh
--
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: Memory management woes - order 1 allocation failures
http://groups.google.com/group/linux.kernel/t/5fdc2e7e4a505944?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:20 pm
From: Mel Gorman

On Tue, Mar 02, 2010 at 11:29:42AM -0800, Greg KH wrote:
> On Tue, Mar 02, 2010 at 07:11:10PM +0000, Mel Gorman wrote:
> > On Tue, Mar 02, 2010 at 06:34:51PM +0000, Alan Cox wrote:
> > > > For reasons that are not particularly clear to me, tty_buffer_alloc() is
> > > > called far more frequently in 2.6.33 than in 2.6.24. I instrumented the
> > > > function to print out the size of the buffers allocated, booted under
> > > > qemu and would just "cat /bin/ls" to see what buffers were allocated.
> > > > 2.6.33 allocates loads, including high-order allocations. 2.6.24
> > > > appeared to allocate once and keep silent.
> > >
> > > The pty layer is using them now and didn't before. That will massively
> > > distort your numhers.
> > >
> >
> > That makes perfect sense. It explains why only one allocation showed up
> > because it must belong to the tty attached to the serial console.
> >
> > Thanks Alan.
> >
> > > > While there have been snags recently with respect to high-order
> > > > allocation failures in recent kernels, this might be one of the cases
> > > > where it's due to subsystems requesting high-order allocations more.
> > >
> > > The pty code certainly triggered more such allocations. I've sent Greg
> > > patches to make the tty buffering layer allocate sensible sizes as it
> > > doesn't need multiple page allocations in the first place.
> > >
> >
> > Greg, what's the story with these patches?
>
> They are in -next and will go to Linus later on today for .34.
>

So, Greg pointed me at the patch in question in linux-next
[c9cf55b: tty: Keep the default buffering to sub-page units]
It's attached for convenience.

However, this patch on its own does not appear to be enough. When rebased to
.33, it's still possible for the TTY layer to require order-1 allocations so
I doubt it would fix Frans's on its own. The problem is that TTY_BUFFER_PAGE
is taking struct tty_buffer into account but not the additional padding
added by tty_buffer_find().

As it's not clear why "Round the buffer size out" is required, I took a
simple approach and adjusted TTY_BUFFER_PAGE rather than being clever in
tty_buffer.c. This keeps the allocation sizes below a page but could it be done
better or did I miss another patch in linux-next that makes this unnecessary?

==== CUT HERE ===
tty: Take a 256 byte padding into account when buffering below sub-page units

The TTY layer takes some care to ensure that only sub-page allocations
are made with interrupts disabled. It does this by setting a goal of
"TTY_BUFFER_PAGE" to allocate. Unfortunately, while TTY_BUFFER_PAGE takes the
size of tty_buffer into account, it fails to account that tty_buffer_find()
rounds the buffer size out to the next 256 byte boundary before adding on
the size of the tty_buffer.

This patch adjusts the TTY_BUFFER_PAGE calculation to take into account the
size of the tty_buffer and the padding. Once applied, tty_buffer_alloc()
should not require high-order allocations.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
include/linux/tty.h | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/tty.h b/include/linux/tty.h
index d96e588..8fe018b 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -70,12 +70,13 @@ struct tty_buffer {

/*
* We default to dicing tty buffer allocations to this many characters
- * in order to avoid multiple page allocations. We assume tty_buffer itself
- * is under 256 bytes. See tty_buffer_find for the allocation logic this
- * must match
+ * in order to avoid multiple page allocations. We know the size of
+ * tty_buffer itself but it must also be taken into account that the
+ * the buffer is 256 byte aligned. See tty_buffer_find for the allocation
+ * logic this must match
*/

-#define TTY_BUFFER_PAGE ((PAGE_SIZE - 256) / 2)
+#define TTY_BUFFER_PAGE (((PAGE_SIZE - sizeof(struct tty_buffer)) / 2) & ~0xFF)

struct tty_bufhead {

==============================================================================
TOPIC: staging/dt3155: use C99 syntax for struct initializer
http://groups.google.com/group/linux.kernel/t/9cec2d082c7dda5a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:20 pm
From: H Hartley Sweeten

Use C99 syntax for the struct file_operations initialization.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Cc: Scott Smedley <ss@aao.gov.au>

---

diff --git a/drivers/staging/dt3155/dt3155_drv.c b/drivers/staging/dt3155/dt3155_drv.c
index a67c622..0183005 100644
--- a/drivers/staging/dt3155/dt3155_drv.c
+++ b/drivers/staging/dt3155/dt3155_drv.c
@@ -850,12 +850,12 @@ static unsigned int dt3155_poll (struct file * filp, poll_table *wait)
* register_chrdev
*****************************************************/
static struct file_operations dt3155_fops = {
- read: dt3155_read,
- ioctl: dt3155_ioctl,
- mmap: dt3155_mmap,
- poll: dt3155_poll,
- open: dt3155_open,
- release: dt3155_close
+ .read = dt3155_read,
+ .ioctl = dt3155_ioctl,
+ .mmap = dt3155_mmap,
+ .poll = dt3155_poll,
+ .open = dt3155_open,
+ .release = dt3155_close,
};

--
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: ahci: Introduce ahci_set_em_messages()
http://groups.google.com/group/linux.kernel/t/f52e7d83445abba6?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 1:20 pm
From: Sergei Shtylyov

Hello.

Anton Vorontsov wrote:

> Factor out some ahci_em_messages handling code from ahci_init_one().
> We would like to reuse it for non-PCI devices.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/ata/ahci.c | 41 ++++++++++++++++++++++++-----------------
> 1 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 18443e9..6694b17 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -3040,6 +3040,29 @@ static inline void ahci_gtf_filter_workaround(struct ata_host *host)
> {}
>

twitter

Tuesday, March 2, 2010

linux.kernel - 26 new messages in 18 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts