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

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

Today's topics:

==============================================================================
TOPIC: Christmas Offer!!!
http://groups.google.com/group/linux.kernel/t/41f1e90a5576cfac?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:20 am
From: THE NATIONAL

You've been award 390,000.00GBP in The National Christmas Offer contact with Name:Address:Age:Sex:Telephone for claims.

--
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: WINNER OF CASH PROMO
http://groups.google.com/group/linux.kernel/t/85bf5619455dc773?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:20 am
From: "DR. PHIL EDWARD"

£750,934.00 you have won. Provide Name: Address: Age: Sex: Occupation: Tel: Country:.This is to notify you. Congratulations!!!
--
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: DMA cache consistency bug introduced in 2.6.28
http://groups.google.com/group/linux.kernel/t/7ab0ecc4119ae78c?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Dec 23 2009 9:20 am
From: "Pallipadi, Venkatesh"

>-----Original Message-----
>From: Linus Torvalds [mailto:torvalds@linux-foundation.org]
>Sent: Wednesday, December 23, 2009 8:50 AM
>To: Andi Kleen
>Cc: Mark Hounschell; Pallipadi, Venkatesh; dmarkh@cfl.rr.com;
>Alain Knaff; Linux Kernel Mailing List;
>fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar
>Subject: Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28
>
>
>
>On Wed, 23 Dec 2009, Andi Kleen wrote:
>>
>> I suspect it's a system where the APIC timer stops in deeper idle
>> states and it supports them. In this case CPU #0 does timer
>broadcasts
>> when needed to wake the other CPUs up from deep C, but for
>that it has
>> to run with HPET. At least the other ones can still enjoy the LAPIC
>> timer.
>
>Ahh, ok, that makes sense. I was assuming the broadcast timer
>would act in
>that capacity, but..

This is what I was thining yday and asked Mark to try idle=halt.
This /proc/interrupts is with idle=halt when there should not be any
C-states and broadcasts involved.
>>> HPET_MSI-edge hpet2
>>> NMI: 0 0 0 0
>>> Non-maskable interrupts
>>> LOC: 268 513395 513138 522088 Local timer
>>> interrupts

Not sure how this is related to floppy problem. But, we surely
have something wrong with percpu HPET usage here.

Thanks,
Venki
--
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: Wed, Dec 23 2009 9:50 am
From: Mark Hounschell

On 12/23/2009 11:38 AM, Andi Kleen wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> It's not using the lapic for CPU0.
>>
>> Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty
>> expensive to reprogram (compared to the local apic). And having different
>> timers for different CPU's is just odd.
>>
>> The fact that the timer subsystem can do this and it all (mostly) works at
>> all is nice and impressive, but doesn't make it any less crazy ;)
>
> I suspect it's a system where the APIC timer stops in deeper idle
> states and it supports them. In this case CPU #0 does timer broadcasts
> when needed to wake the other CPUs up from deep C, but for that it has
> to run with HPET. At least the other ones can still enjoy the LAPIC
> timer.
>
> This might suggest that Mark's floppy controller doesn't like
> deep C? Mark, did you try booting with processor.max_cstate=1
> and HPET enabled?

I just did and /proc/interrupts looks the same and the floppy still does
not format.

I'll try the patch Linus provided now.

Mark

== 3 of 3 ==
Date: Wed, Dec 23 2009 10:10 am
From: Linus Torvalds

On Wed, 23 Dec 2009, Mark Hounschell wrote:
>
> I'll try the patch Linus provided now.

I doubt it matters - because if it did, it would matter for everybody, and
the HPET thing shouldn't make any difference at all.

[ Or rather, it should matter for everybody trying to format a specific
format (without interleave it won't matter, and not all formats have any
interleave - I think it was mainly used on 5.25" floppies and special
formats). ]

Besides, maybe I was just mis-reading the code.

But getting some testing for the patch certainly won't hurt, so I'm not
going to argue against it any more ;)

Linus
--
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: AlacrityVM guest drivers for 2.6.33
http://groups.google.com/group/linux.kernel/t/265f7bf4a9a1d92d?hl=en
==============================================================================

== 1 of 6 ==
Date: Wed, Dec 23 2009 9:20 am
From: Gregory Haskins

On 12/23/09 12:10 PM, Andi Kleen wrote:
>> And its moot, anyway, as I have already retracted my one outstanding
>> pull request based on Linus' observation. So at this time, I am not
>> advocating _anything_ for upstream inclusion. And I am contemplating
>> _never_ doing so again. It's not worth _this_.
>
> That certainly sounds like the wrong reaction. Out of tree drivers
> are typically a pain to use.

Well, to Linus' point, it shouldn't go in until a critical mass of users
have expressed desire to see it in tree, which seems reasonable to me.
For the admittedly small group that are using it today, modern tools
like the opensuse-build-service ease the deployment as a KMP, so that
can suffice for now. Its actually what most of the alacrityvm community
uses today anyway (as opposed to using a merged tree in the guest)

>
> And upstream submission is not always like this!

I would think the process would come to a grinding halt if it were ;)

Thanks Andi,
-Greg

== 2 of 6 ==
Date: Wed, Dec 23 2009 9:20 am
From: Andi Kleen

> And its moot, anyway, as I have already retracted my one outstanding
> pull request based on Linus' observation. So at this time, I am not
> advocating _anything_ for upstream inclusion. And I am contemplating
> _never_ doing so again. It's not worth _this_.

That certainly sounds like the wrong reaction. Out of tree drivers
are typically a pain to use.

And upstream submission is not always like this!

-Andi
--
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 6 ==
Date: Wed, Dec 23 2009 9:30 am
From: Andi Kleen

> > >It seems like there's definitely still potential for improvement
> > >with messages<4K. But for the large messages they indeed
> > >look rather good.
>
> You are misreading the graph. At <4K it is tracking bare metal (the
> green and yellow lines are bare metal, the red and blue bars are virtio).
> At >4k we start to drop off (esp. on RX).

I see. True.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.
--
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/

== 4 of 6 ==
Date: Wed, Dec 23 2009 9:40 am
From: Linus Torvalds

On Wed, 23 Dec 2009, Gregory Haskins wrote:
> >
> > And upstream submission is not always like this!
>
> I would think the process would come to a grinding halt if it were ;)

Well, in all honesty, if it had been non-virtualized drivers I would just
have pulled. The pull request all looked sane, the diffstat looked clean
and non-intrusive, and I had no problems with any of that.

But the virtualization people always argue about the fifty-eleven
different ways of doing things, and unlike real drivers - where the actual
hardware places constraints on what the heck is going on - virtualization
people seem to revel in making new interfaces weekly, and tend to be only
incidentally limited by hardware (ie hardware interfaces may limit some
_details_, but seldom any higher-level arguments).

So when I see another virtualization interface, I want the virtualization
people to just argue it out amongst themselves. Thanks to the virtue of me
personally not caring one whit about virtualization, I can stand back and
just watch the fireworks.

Which is not to say that I enjoy it (I like the occasional flame-fest, but
in order to like them I need to _care_ enough to get fired up about
them!).

So I just don't want the in-fighting to take place in my tree, so I'd
rather see the fighting die out _before_ I actually pull.

You people are all crazy.

== 5 of 6 ==
Date: Wed, Dec 23 2009 9:40 am
From: Gregory Haskins

On 12/23/09 1:15 AM, Kyle Moffett wrote:
> On Tue, Dec 22, 2009 at 12:36, Gregory Haskins
> <gregory.haskins@gmail.com> wrote:
>> On 12/22/09 2:57 AM, Ingo Molnar wrote:
>>> * Gregory Haskins <gregory.haskins@gmail.com> wrote:
>>>> Actually, these patches have nothing to do with the KVM folks. [...]
>>>
>>> That claim is curious to me - the AlacrityVM host
>>
>> It's quite simple, really. These drivers support accessing vbus, and
>> vbus is hypervisor agnostic. In fact, vbus isn't necessarily even
>> hypervisor related. It may be used anywhere where a Linux kernel is the
>> "io backend", which includes hypervisors like AlacrityVM, but also
>> userspace apps, and interconnected physical systems as well.
>>
>> The vbus-core on the backend, and the drivers on the frontend operate
>> completely independent of the underlying hypervisor. A glue piece
>> called a "connector" ties them together, and any "hypervisor" specific
>> details are encapsulated in the connector module. In this case, the
>> connector surfaces to the guest side as a pci-bridge, so even that is
>> not hypervisor specific per se. It will work with any pci-bridge that
>> exposes a compatible ABI, which conceivably could be actual hardware.
>
> This is actually something that is of particular interest to me. I
> have a few prototype boards right now with programmable PCI-E
> host/device links on them; one of my long-term plans is to finagle
> vbus into providing multiple "virtual" devices across that single
> PCI-E interface.
>
> Specifically, I want to be able to provide virtual NIC(s), serial
> ports and serial consoles, virtual block storage, and possibly other
> kinds of interfaces. My big problem with existing virtio right now
> (although I would be happy to be proven wrong) is that it seems to
> need some sort of out-of-band communication channel for setting up
> devices, not to mention it seems to need one PCI device per virtual
> device.
>
> So I would love to be able to port something like vbus to my nify PCI
> hardware and write some backend drivers... then my PCI-E connected
> systems would dynamically provide a list of highly-efficient "virtual"
> devices to each other, with only one 4-lane PCI-E bus.

Hi Kyle,

We indeed have others that are doing something similar. I have CC'd Ira
who may be able to provide you more details. I would also point you at
the canonical example for what you would need to write to tie your
systems together. Its the "null connector", which you can find here:

http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=kernel/vbus/connectors/null.c;h=b6d16cb68b7e49e07528278bc9f5b73e1dac0c2f;hb=HEAD

Do not hesitate to ask any questions, though you may want to take the
conversation to the alacrityvm-devel list as to not annoy the current CC
list any further than I already have ;)

Kind Regards,
-Greg

== 6 of 6 ==
Date: Wed, Dec 23 2009 9:40 am
From: Andi Kleen

On Wed, Dec 23, 2009 at 12:17:48PM -0500, Gregory Haskins wrote:
> On 12/23/09 12:10 PM, Andi Kleen wrote:
> >> And its moot, anyway, as I have already retracted my one outstanding
> >> pull request based on Linus' observation. So at this time, I am not
> >> advocating _anything_ for upstream inclusion. And I am contemplating
> >> _never_ doing so again. It's not worth _this_.
> >
> > That certainly sounds like the wrong reaction. Out of tree drivers
> > are typically a pain to use.
>
> Well, to Linus' point, it shouldn't go in until a critical mass of users
> have expressed desire to see it in tree, which seems reasonable to me.
> For the admittedly small group that are using it today, modern tools
> like the opensuse-build-service ease the deployment as a KMP, so that
> can suffice for now. Its actually what most of the alacrityvm community
> uses today anyway (as opposed to using a merged tree in the guest)

It would be probably also good to have some more exhaustive data
showing any performance improvements.

Your numbers are very hard to compare to Chris' numbers and not
as comprehensive (e.g. no latencies)

-Andi

==============================================================================
TOPIC: NULL pointer in usb_serial_probe() introduced by the recent kfifo
changes
http://groups.google.com/group/linux.kernel/t/416fe3d3ef6ee79e?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 23 2009 9:20 am
From: Greg KH

On Wed, Dec 23, 2009 at 09:10:48AM +0100, Stefani Seibold wrote:
> Am Dienstag, den 22.12.2009, 21:37 -0800 schrieb Greg KH:
> > On Wed, Dec 23, 2009 at 02:51:31AM +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > Something like the patch below is necessary to fix a new NULL pointer deref
> > > in usb_serial_probe() that appeared after the recent kfifo changes (in short,
> > > the kfifo changes modified the semantics of kfifo_alloc() that
> > > usb_serial_probe() reiled on).
> >
> > What semantic changed? I thought that the kfifo patches came with
> > patches that also fixed up any changed that were needed. What went
> > wrong here?
> >
>
> This one is a new user of the kfifo API, so it forget to port it to the
> new kfifo API.
>
> Please make the write_fifo in place. Here is my patch to fix the
> regression and full ported version.

Thanks, I'll queue this up and send it to Linus later today.

greg k-h
--
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: Wed, Dec 23 2009 9:50 am
From: Greg KH

On Wed, Dec 23, 2009 at 09:17:31AM -0800, Greg KH wrote:
> On Wed, Dec 23, 2009 at 09:10:48AM +0100, Stefani Seibold wrote:
> > Am Dienstag, den 22.12.2009, 21:37 -0800 schrieb Greg KH:
> > > On Wed, Dec 23, 2009 at 02:51:31AM +0100, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > Something like the patch below is necessary to fix a new NULL pointer deref
> > > > in usb_serial_probe() that appeared after the recent kfifo changes (in short,
> > > > the kfifo changes modified the semantics of kfifo_alloc() that
> > > > usb_serial_probe() reiled on).
> > >
> > > What semantic changed? I thought that the kfifo patches came with
> > > patches that also fixed up any changed that were needed. What went
> > > wrong here?
> > >
> >
> > This one is a new user of the kfifo API, so it forget to port it to the
> > new kfifo API.
> >
> > Please make the write_fifo in place. Here is my patch to fix the
> > regression and full ported version.
>
> Thanks, I'll queue this up and send it to Linus later today.

Heh, nevermind, Linus took it already :)

thanks,

==============================================================================
TOPIC: Tmem [PATCH 0/5] (Take 3): Transcendent memory
http://groups.google.com/group/linux.kernel/t/5d50b93424a4a645?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:30 am
From: Dan Magenheimer

> As I mentioned, I really like the idea behind tmem. All I am proposing
> is that we should probably explore some alternatives to achive this using
> some existing infrastructure in kernel.

Hi Nitin --

Sorry if I sounded overly negative... too busy around the holidays.

I'm definitely OK with exploring alternatives. I just think that
existing kernel mechanisms are very firmly rooted in the notion
that either the kernel owns the memory/cache or an asynchronous
device owns it. Tmem falls somewhere in between and is very
carefully designed to maximize memory flexibility *outside* of
the kernel -- across all guests in a virtualized environment --
with minimal impact to the kernel, while still providing the
kernel with the ability to use -- but not own, directly address,
or control -- additional memory when conditions allow. And
these conditions are not only completely invisible to the kernel,
but change frequently and asynchronously from the kernel,
unlike most external devices for which the kernel can "reserve"
space and use it asynchronously later.

Maybe ramzswap and FS-cache could be augmented to have similar
advantages in a virtualized environment, but I suspect they'd
end up with something very similar to tmem. Since the objective
of both is to optimize memory that IS owned (used, directly
addressable, and controlled) by the kernel, they are entirely
complementary with tmem.

> Is synchronous working a *requirement* for tmem to work correctly?

Yes. Asynchronous behavior would introduce lots of race
conditions between the hypervisor and kernel which would
greatly increase complexity and reduce performance. And
tmem then essentially becomes an I/O device, which defeats
its purpose, especially compared to a fast SSD.

> Swapping to hypervisor is mainly useful to overcome
> 'static partitioning' problem you mentioned in article:
> http://oss.oracle.com/projects/tmem/
> ...such 'para-swap' can shrink/expand outside of VM constraints.

Frontswap is very different than "hypervisor swapping" as what's
done by VMware as a side-effect of transparent page-sharing. With
frontswap, the kernel still decides which pages are swapped out.
If frontswap says there is space, the swap goes "fast" to tmem;
if not, the kernel writes it to its own swapdisk. So there's
no "double paging" or random page selection/swapping. On
the downside, kernels must have real swap configured and,
to avoid DoS issues, frontswap is limited by the same constraint
as ballooning (ie. can NOT expand outside of VM constraints).

Thanks,
Dan

P.S. If you want to look at implementing FS-cache or ramzswap
on top of tmem, I'd be happy to help, but I'll bet your concern:

> we might later encounter some hidder/dangerous problems :)

will prove to be correct.

> -----Original Message-----
> From: Nitin Gupta [mailto:ngupta@vflare.org]
> Sent: Tuesday, December 22, 2009 11:28 PM
> To: Dan Magenheimer
> Cc: Nick Piggin; Andrew Morton; jeremy@goop.org;
> xen-devel@lists.xensource.com; tmem-devel@oss.oracle.com;
> Rusty Russell;
> Rik van Riel; Dave Mccracken; Sunil Mushran; Avi Kivity; Schwidefsky;
> Balbir Singh; Marcelo Tosatti; Alan Cox; Chris Mason; Pavel Machek;
> linux-mm; linux-kernel
> Subject: Re: Tmem [PATCH 0/5] (Take 3): Transcendent memory
>
>
> Hi Dan,
>
> (mail to Rusty [at] rcsinet15.oracle.com was failing, so I removed
> this address from CC list).
>
> On Tue, Dec 22, 2009 at 5:16 AM, Dan Magenheimer
> <dan.magenheimer@oracle.com> wrote:
> >> From: Nitin Gupta [mailto:ngupta@vflare.org]
>
> >
> >> I think 'frontswap' part seriously overlaps the functionality
> >> provided by 'ramzswap'
> >
> > Could be, but I suspect there's a subtle difference.
> > A key part of the tmem frontswap api is that any
> > "put" at any time can be rejected. There's no way
> > for the kernel to know a priori whether the put
> > will be rejected or not, and the kernel must be able
> > to react by writing the page to a "true" swap device
> > and must keep track of which pages were put
> > to tmem frontswap and which were written to disk.
> > As a result, tmem frontswap cannot be configured or
> > used as a true swap "device".
> >
> > This is critical to acheive the flexibility you
> > commented above that you like. Only the hypervisor
> > knows if a free page is available "now" because
> > it is flexibly managing tmem requests from multiple
> > guest kernels.
> >
>
> ramzswap devices can easily track which pages it sent
> to hypervisor, which pages are in backing swap (physical) disk
> and which are in (compressed) memory. Its simply a matter
> of adding some more flags. Latter two are already done in this
> driver.
>
> So, to gain flexibility of frontswap, we can have hypervisor
> send the driver a callback whenever it wants to discard swap
> pages under its domain. If you want to avoid even this callback,
> then kernel will have to keep a copy within guest, which I think
> defeats the whole purpose of swapping to hypervisor. Such
> "ephemeral" pools should be used only for clean fs cache and
> not for swap.
>
> Swapping to hypervisor is mainly useful to overcome
> 'static partitioning' problem you mentioned in article:
> http://oss.oracle.com/projects/tmem/
> ...such 'para-swap' can shrink/expand outside of VM constraints.
>
>
> >
> >>> Cleancache is
> >> > "ephemeral" so whether a page is kept in cleancache
> >> (between the "put" and
> >> > the "get") is dependent on a number of factors that are
> invisible to
> >> > the kernel.
> >>
> >> Just an idea: as an alternate approach, we can create an
> >> 'in-memory compressed
> >> storage' backend for FS-Cache. This way, all filesystems
> >> modified to use
> >> fs-cache can benefit from this backend. To make it
> >> virtualization friendly like
> >> tmem, we can again provide (per-cache?) option to allocate
> >> from hypervisor i.e.
> >> tmem_{put,get}_page() or use [compress]+alloc natively.
> >
> > I looked at FS-Cache and cachefiles and thought I understood
> > that it is not restricted to clean pages only, thus
> > not a good match for tmem cleancache.
> >
> > Again, if I'm wrong (or if it is easy to tell FS-Cache that
> > pages may "disappear" underneath it), let me know.
> >
>
> fs-cache backend can keep 'dirty' pages within guest and forward
> clean pages to hypervisor. These clean pages can be added to
> ephemeral pools which can be reclaimed at any time by hypervisor.
> BTW, I have not yet started work on any such fs-cache backend, so
> we might later encounter some hidder/dangerous problems :)
>
>
> > BTW, pages put to tmem (both frontswap and cleancache) can
> > be optionally compressed.
> >
>
> If ramzswap is extended for this virtualization case, then enforcing
> compression might not be good. We can then throw out pages to hvisor
> even before compression stage. All such changes to ramzswap are IMHO
> pretty straight forward to do.
>
>
> >> For guest<-->hypervisor interface, maybe we can use virtio
> so that all
> >> hypervisors can benefit? Not quite sure about this one.
> >
> > I'm not very familiar with virtio, but the existence of "I/O"
> > in the name concerns me because tmem is entirely synchronous.
> >
>
> Is synchronous working a *requirement* for tmem to work correctly?
>
>
> > Also, tmem is well-layered so very little work needs to be
> > done on the Linux side for other hypervisors to benefit.
> > Of course these other hypervisors would need to implement
> > the hypervisor-side of tmem as well, but there is a well-defined
> > API to guide other hypervisor-side implementations... and the
> > opensource tmem code in Xen has a clear split between the
> > hypervisor-dependent and hypervisor-independent code, which
> > should simplify implementation for other opensource hypervisors.
> >
>
> As I mentioned, I really like the idea behind tmem. All I am proposing
> is that we should probably explore some alternatives to
> achive this using
> some existing infrastructure in kernel. I also don't have
> experience working
> on virtio[1] or virtual-bus[2] but I have the feeling that once guest
> to hvisor channels are created, both ramzswap extension and
> fs-cache backend
> can share the same code.
>
> [1] virtio: http://portal.acm.org/citation.cfm?id=1400097.1400108
> [2] virtual-bus:
http://developer.novell.com/wiki/index.php/Virtual-bus

Thanks,
Nitin
--
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: kfifo: fix Error/broken kernel-doc notation
http://groups.google.com/group/linux.kernel/t/6eb9c049b0bd4039?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:30 am
From: Randy Dunlap

From: Randy Dunlap <randy.dunlap@oracle.com>

Fix kernel-doc errors and warnings in new header file kfifo.h.
Don't use kernel-doc "/**" for internal functions whose comments
are not in kernel-doc format.

kernel-doc section header names (like "Note:") must be unique
per function. Looks like I need to document that.

Error(include/linux/kfifo.h:76): duplicate section name 'Note'
Warning(include/linux/kfifo.h:88): Excess function parameter 'size' description in 'INIT_KFIFO'
Error(include/linux/kfifo.h:101): duplicate section name 'Note'
Warning(include/linux/kfifo.h:257): No description found for parameter 'fifo'
(many of this last type, from internal functions)

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stefani Seibold <stefani@seibold.net>
---
include/linux/kfifo.h | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)

--- linux-2.6.33-rc1-git3.orig/include/linux/kfifo.h
+++ linux-2.6.33-rc1-git3/include/linux/kfifo.h
@@ -69,8 +69,8 @@ struct kfifo {
* @name: name of the declared kfifo datatype
* @size: size of the fifo buffer
*
- * Note: the macro can be used inside struct or union declaration
- * Note: the macro creates two objects:
+ * Note1: the macro can be used inside struct or union declaration
+ * Note2: the macro creates two objects:
* A kfifo object with the given name and a buffer for the kfifo
* object named name##kfifo_buffer
*/
@@ -83,7 +83,6 @@ union { \
/**
* INIT_KFIFO - Initialize a kfifo declared by DECLARED_KFIFO
* @name: name of the declared kfifo datatype
- * @size: size of the fifo buffer
*/
#define INIT_KFIFO(name) \
name = __kfifo_initializer(sizeof(name##kfifo_buffer) - \
@@ -94,8 +93,8 @@ union { \
* @name: name of the declared kfifo datatype
* @size: size of the fifo buffer
*
- * Note: the macro can be used for global and local kfifo data type variables
- * Note: the macro creates two objects:
+ * Note1: the macro can be used for global and local kfifo data type variables
+ * Note2: the macro creates two objects:
* A kfifo object with the given name and a buffer for the kfifo
* object named name##kfifo_buffer
*/
@@ -249,7 +248,7 @@ extern __must_check unsigned int kfifo_f
extern __must_check unsigned int kfifo_to_user(struct kfifo *fifo,
void __user *to, unsigned int n);

-/**
+/*
* __kfifo_add_out internal helper function for updating the out offset
*/
static inline void __kfifo_add_out(struct kfifo *fifo,
@@ -259,7 +258,7 @@ static inline void __kfifo_add_out(struc
fifo->out += off;
}

-/**
+/*
* __kfifo_add_in internal helper function for updating the in offset
*/
static inline void __kfifo_add_in(struct kfifo *fifo,
@@ -269,7 +268,7 @@ static inline void __kfifo_add_in(struct
fifo->in += off;
}

-/**
+/*
* __kfifo_off internal helper function for calculating the index of a
* given offeset
*/
@@ -278,7 +277,7 @@ static inline unsigned int __kfifo_off(s
return off & (fifo->size - 1);
}

-/**
+/*
* __kfifo_peek_n internal helper function for determinate the length of
* the next record in the fifo
*/
@@ -299,7 +298,7 @@ static inline unsigned int __kfifo_peek_
#undef __KFIFO_GET
}

-/**
+/*
* __kfifo_poke_n internal helper function for storing the length of
* the next record into the fifo
*/
@@ -319,7 +318,7 @@ static inline void __kfifo_poke_n(struct
#undef __KFIFO_PUT
}

-/**
+/*
* __kfifo_in_... internal functions for put date into the fifo
* do not call it directly, use kfifo_in_rec() instead
*/
@@ -367,7 +366,7 @@ static inline __must_check unsigned int
return __kfifo_in_rec(fifo, from, n, recsize);
}

-/**
+/*
* __kfifo_out_... internal functions for get date from the fifo
* do not call it directly, use kfifo_out_rec() instead
*/
@@ -425,7 +424,7 @@ static inline __must_check unsigned int
return __kfifo_out_rec(fifo, to, n, recsize, total);
}

-/**
+/*
* __kfifo_from_user_... internal functions for transfer from user space into
* the fifo. do not call it directly, use kfifo_from_user_rec() instead
*/
@@ -474,7 +473,7 @@ static inline __must_check unsigned int
return __kfifo_from_user_rec(fifo, from, n, recsize);
}

-/**
+/*
* __kfifo_to_user_... internal functions for transfer fifo data into user space
* do not call it directly, use kfifo_to_user_rec() instead
*/
@@ -533,7 +532,7 @@ static inline __must_check unsigned int
return __kfifo_to_user_rec(fifo, to, n, recsize, total);
}

-/**
+/*
* __kfifo_peek_... internal functions for peek into the next fifo record
* do not call it directly, use kfifo_peek_rec() instead
*/
@@ -557,7 +556,7 @@ static inline __must_check unsigned int
return __kfifo_peek_n(fifo, recsize);
}

-/**
+/*
* __kfifo_skip_... internal functions for skip the next fifo record
* do not call it directly, use kfifo_skip_rec() instead
*/
--
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: hamradio: avoid null deref
http://groups.google.com/group/linux.kernel/t/5a211de8b1ba40e6?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:50 am
From: Jarek Poplawski

Dan Carpenter wrote, On 12/23/2009 02:25 PM:

> If dev == NULL we shouldn't dereference it.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> --- orig/drivers/net/hamradio/bpqether.c 2009-12-22 23:58:56.000000000 +0200
> +++ devel/drivers/net/hamradio/bpqether.c 2009-12-22 23:59:46.000000000 +0200
> @@ -283,7 +283,6 @@ static netdev_tx_t bpq_xmit(struct sk_bu
> bpq = netdev_priv(dev);
>
> if ((dev = bpq_get_ether_dev(dev)) == NULL) {
> - dev->stats.tx_dropped++;

Why not use a separate variable for another dev? This stat
should be helpful for debugging.

Jarek P.

> kfree_skb(skb);
> return NETDEV_TX_OK;
> }

==============================================================================
TOPIC: utrace/ptrace
http://groups.google.com/group/linux.kernel/t/26bbdd5695b9d20c?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 9:50 am
From: Oleg Nesterov

On 12/22, Andrew Morton wrote:
>
> On Fri, 18 Dec 2009 02:11:16 +0100
> Oleg Nesterov <oleg@redhat.com> wrote:
>
> > It allows for multiple separate tracing engines to work
> > in parallel without interfering with each other. Higher-level tracing
> > facilities can be implemented as loadable kernel modules using this layer.
>
> That's a bit brief. Do you have a nicer sales brochure? What are
> these "separate tracing engines" and what is their merge status and why
> would we want any of them, for what purpose? etc.
>
> IOW: give us a reason!

First of all, utrace makes other things possible. gdbstub, nondestructive
core dump, uprobes, kmview, hopefully more. I didn't look at these projects
closely, perhaps other people can tell more. As for their merge status,
until utrace itself is merged it is very hard to develop them out of tree.

To me, even seccomp is the good example why utrace is useful. seccomp
is simple, but it needs hooks in arch/ hot pathes. Contrary, utrace-based
implementation is more flexible, simple, and it is completely "hidden"
behind utrace.

In my opinion, ptrace-utrace is another example. Once CONFIG_UTRACE
goes away, we can remove almost all ptrace-related code from core
kernel (and kill task_struct->ptrace/etc members).

ftrace/etc is excellent in many ways, but even if we need the simple
"passive" tracing it is not enough sometimes. And we have nothing else
except ptrace currently. But ptrace is so horrible and unfixeable, and
it has so many limitations. In fact, even the simple things like stop/
continue this thread/process are not trivial using ptrace, gdb/strace
have to do a lot of hacks to overcome ptrace's limitations, and some
of these hacks falls into "mostly works, but that is all" category.

Of course, I can't promise we will have the new gdb which explores
utrace facilities soon, but I think at leat utrace gives a chance.

Well. I had a lot of technical discussions with Roland about utrace,
but I never asked him why he created this thing ;) To me, utrace
looks like vfs. Currently we have the single and very poor "filesystem",
ptrace. Until we add the appropriate layer, we can't expect the
further improvements is this area.

Oleg.

==============================================================================
TOPIC: ucc_geth broken in 2.6.32 by 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4
http://groups.google.com/group/linux.kernel/t/07c62b3665518011?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 23 2009 9:50 am
From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)

We use the ucc_geth for 6 ports (4 100Mbit and 2 Gbit ports) on an
mpc8360e. Up to 2.6.31 this worked fine. 2.6.32 on the other hand
crashes very quickly after boot.

I managed to see the same crash when I was selectively trying to add newer
ucc_geth patches to the 2.6.31 kernel a couple of months ago, and the same
patch that caused a crash then seems suspect. If I revert the patch the
system runs completely stable. Amusingly, the excact error message the
patch claims to fix is in fact the error it causes to happen in my case.

So preferably 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4 could be reverted
unless someone can fix it. I can't even make sense of why it is supposed
to improve anything, it certainly seems like a very unsafe change
to make. Removing locking and disabling of interrupts before poking at
phy settings and such doesn't seem like a minor change and doesn't seem
that safe either.

Now I must add that I run with the xenomai/adeos-ipipe patches as well,
which do change interrupt handling a little, but so far this has worked
fine with the previous code and only the current code is broken for us.
I could try to build without the patch, although I would loose some major
functionality on the box doing so, and I would not be surprised if it
still fails since I believe I tried that already with 2.6.31+selected
git patches before without xenomai patched in and it still failed,
but I am only about 99% sure of that.

With the patch I get:
NETDEV WATCHDOG: eth2 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at c02729a8 [verbose debug info unavailable]
NIP: c02729a8 LR: c02729a8 CTR: c01b6088
REGS: c0451c40 TRAP: 0700 Not tainted (2.6.32-trunk-8360e)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 42042024 XER: 20000000
TASK = c041f3e8[0] 'swapper' THREAD: c0450000
GPR00: c02729a8 c0451cf0 c041f3e8 00000045 00002ae9 ffffffff c01b6afc c0422c48
GPR08: c042fde8 00000002 00000003 00010000 22042024 1001af90 1fffd000 00000000
GPR16: 00000000 c038c6d8 00000001 00200200 00000000 c0465eec c0465cec c0465aec
GPR24: c0450000 c04658ec c0423c2c df0e01c0 c0480000 df0e0000 c0423c2c 00000000
NIP [c02729a8] dev_watchdog+0x280/0x290
LR [c02729a8] dev_watchdog+0x280/0x290
Call Trace:
[c0451cf0] [c02729a8] dev_watchdog+0x280/0x290 (unreliable)
[c0451d50] [c00377c4] run_timer_softirq+0x164/0x224
[c0451da0] [c0032a38] __do_softirq+0xb8/0x13c
[c0451df0] [c00065cc] do_softirq+0xa0/0xac
[c0451e00] [c003280c] irq_exit+0x7c/0x9c
[c0451e10] [c00640c4] __ipipe_sync_stage+0x248/0x24c
[c0451e50] [c0064374] ipipe_suspend_domain+0xa0/0xf4
[c0451e70] [c00644a4] __ipipe_walk_pipeline+0xdc/0x120
[c0451e90] [c000af28] __ipipe_handle_irq+0x164/0x168
[c0451ec0] [c000b03c] __ipipe_grab_irq+0x3c/0xa4
[c0451ed0] [c0014814] __ipipe_ret_from_except+0x0/0xc
--- Exception: 501 at cpu_idle+0xe0/0xf0
LR = cpu_idle+0xe0/0xf0
[c0451f90] [c000970c] cpu_idle+0x68/0xf0 (unreliable)
[c0451fb0] [c0003f30] rest_init+0x5c/0x6c
[c0451fc0] [c03f07ac] start_kernel+0x27c/0x2e0
[c0451ff0] [00003438] 0x3438
Instruction dump:
7d2903a6 4bfffea8 38810008 7fa3eb78 38a00040 4bfe9c81 7fe6fb78 7fa4eb78
7c651b78 3c60c03c 38631774 480b7d2d <0fe00000> 38000001 901c2fb0 4bffff94
warning: `zebra' uses 32-bit capabilities (legacy support in use)
PHY: 0:03 - Link is Up - 1000/Full
PHY: 0:09 - Link is Up - 100/Full
PHY: 0:02 - Link is Up - 100/Full
PHY: 0:0f - Link is Up - 100/Full
PHY: 0:17 - Link is Up - 100/Full

When reverted I get a stable running system with no errors.

Which port happens to fail first varies, but one always does and then
the system almost always crashes soon after.

--
Len Sorensen
--
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: Wed, Dec 23 2009 10:10 am
From: Anton Vorontsov

On Wed, Dec 23, 2009 at 12:40:19PM -0500, Lennart Sorensen wrote:
> We use the ucc_geth for 6 ports (4 100Mbit and 2 Gbit ports) on an
> mpc8360e. Up to 2.6.31 this worked fine. 2.6.32 on the other hand
> crashes very quickly after boot.

Hm. Just curious, what CPU revision you use? So that I could try
to reproduce the issue... I have MPC8360E-MDS boards, rev 2.0 and
rev rev 2.1 CPUs, Marvell PHYs. I also have MPC8360E-RDK (rev 2.1).
And I didn't see any issues with this patch.

> I managed to see the same crash when I was selectively trying to add newer
> ucc_geth patches to the 2.6.31 kernel a couple of months ago, and the same
> patch that caused a crash then seems suspect. If I revert the patch the
> system runs completely stable. Amusingly, the excact error message the
> patch claims to fix is in fact the error it causes to happen in my case.
>
> So preferably 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4 could be reverted

I don't see any point in reverting, because it will surely break my boards.
So, we need to fix this, not just hide.

> unless someone can fix it.

Well, I'm ready to help you with debugging.

> Now I must add that I run with the xenomai/adeos-ipipe patches as well,
> which do change interrupt handling a little,

It could be that it takes too long to stop the UCC, and xenomai
makes the timings worse, so the watchdog triggers.

Can you try the following patch?

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index afaf088..2f73e3f 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1563,6 +1563,8 @@ static int ugeth_disable(struct ucc_geth_private *ugeth, enum comm_dir mode)

static void ugeth_quiesce(struct ucc_geth_private *ugeth)
{
+ netif_device_detach(ugeth->ndev);
+
/* Wait for and prevent any further xmits. */
netif_tx_disable(ugeth->ndev);

@@ -1577,7 +1579,7 @@ static void ugeth_activate(struct ucc_geth_private *ugeth)
{
napi_enable(&ugeth->napi);
enable_irq(ugeth->ug_info->uf_info.irq);
- netif_tx_wake_all_queues(ugeth->ndev);
+ netif_device_attach(ugeth->ndev);
}

/* Called every time the controller might need to be made
--
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: sound fixes
http://groups.google.com/group/linux.kernel/t/b38e065daaeb8de8?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Dec 23 2009 10:00 am
From: Takashi Iwai

Linus,

please pull another sound fixes for v2.6.33-rc2 from:

git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for-linus

All fixes below are mostly trivial and individual.

Thanks!

Takashi

===

Anisse Astier (1):
ALSA: hda - Add STAC9205 PCI_QUIRK for Dell Vostro 1700

Eric Millbrandt (1):
ASoC: Do not write to invalid registers on the wm9712.

Florian Fainelli (1):
ALSA: sound/core/pcm_timer.c: use lib/gcd.c

Guennadi Liakhovetski (1):
ASoC: add missing parameter to mx27vis_hifi_hw_free()

Rafael Avila de Espindola (1):
ALSA: hda - Add support for the new 27 inch IMacs

Takashi Iwai (3):
ALSA: hda - Fix NULL dereference with enable_beep=0 option
ALSA: hda - Add MSI blacklist
ALSA: hda - Set mixer name after codec patch

Uwe Kleine-König (1):
ASoC: sh: FSI:: don't check platform_get_irq's return value against zero

diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index e93afff..e72cee9 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -403,4 +403,5 @@ STAC9872
Cirrus Logic CS4206/4207
========================
mbp55 MacBook Pro 5,5
+ imac27 IMac 27 Inch
auto BIOS setup (default)
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index c15682a..475455c 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -5,6 +5,7 @@ config SND_TIMER
config SND_PCM
tristate
select SND_TIMER
+ select GCD

config SND_HWDEP
tristate
diff --git a/sound/core/pcm_timer.c b/sound/core/pcm_timer.c
index ca8068b..b01d948 100644
--- a/sound/core/pcm_timer.c
+++ b/sound/core/pcm_timer.c
@@ -20,6 +20,7 @@
*/

#include <linux/time.h>
+#include <linux/gcd.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/timer.h>
@@ -28,22 +29,6 @@
* Timer functions
*/

-/* Greatest common divisor */
-static unsigned long gcd(unsigned long a, unsigned long b)
-{
- unsigned long r;
- if (a < b) {
- r = a;
- a = b;
- b = r;
- }
- while ((r = a % b) != 0) {
- a = b;
- b = r;
- }
- return b;
-}
-
void snd_pcm_timer_resolution_change(struct snd_pcm_substream *substream)
{
unsigned long rate, mult, fsize, l, post;
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 9cfdb77..950ee5c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1086,11 +1086,6 @@ int snd_hda_codec_configure(struct hda_codec *codec)
if (err < 0)
return err;
}
- /* audio codec should override the mixer name */
- if (codec->afg || !*codec->bus->card->mixername)
- snprintf(codec->bus->card->mixername,
- sizeof(codec->bus->card->mixername),
- "%s %s", codec->vendor_name, codec->chip_name);

if (is_generic_config(codec)) {
err = snd_hda_parse_generic_codec(codec);
@@ -1109,6 +1104,11 @@ int snd_hda_codec_configure(struct hda_codec *codec)
patched:
if (!err && codec->patch_ops.unsol_event)
err = init_unsol_queue(codec->bus);
+ /* audio codec should override the mixer name */
+ if (!err && (codec->afg || !*codec->bus->card->mixername))
+ snprintf(codec->bus->card->mixername,
+ sizeof(codec->bus->card->mixername),
+ "%s %s", codec->vendor_name, codec->chip_name);
return err;
}
EXPORT_SYMBOL_HDA(snd_hda_codec_configure);
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 9b56f93..ff8ad46 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2322,6 +2322,7 @@ static void __devinit check_probe_mask(struct azx *chip, int dev)
* white/black-list for enable_msi
*/
static struct snd_pci_quirk msi_black_list[] __devinitdata = {
+ SND_PCI_QUIRK(0x1043, 0x81f2, "ASUS", 0), /* Athlon64 X2 + nvidia */
{}
};

diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index 4b200da..fe0423c 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -66,6 +66,7 @@ struct cs_spec {
/* available models */
enum {
CS420X_MBP55,
+ CS420X_IMAC27,
CS420X_AUTO,
CS420X_MODELS
};
@@ -827,7 +828,8 @@ static void cs_automute(struct hda_codec *codec)
AC_VERB_SET_PIN_WIDGET_CONTROL,
hp_present ? 0 : PIN_OUT);
}
- if (spec->board_config == CS420X_MBP55) {
+ if (spec->board_config == CS420X_MBP55 ||
+ spec->board_config == CS420X_IMAC27) {
unsigned int gpio = hp_present ? 0x02 : 0x08;
snd_hda_codec_write(codec, 0x01, 0,
AC_VERB_SET_GPIO_DATA, gpio);
@@ -1069,12 +1071,14 @@ static int cs_parse_auto_config(struct hda_codec *codec)

static const char *cs420x_models[CS420X_MODELS] = {
[CS420X_MBP55] = "mbp55",
+ [CS420X_IMAC27] = "imac27",
[CS420X_AUTO] = "auto",
};

static struct snd_pci_quirk cs420x_cfg_tbl[] = {
SND_PCI_QUIRK(0x10de, 0xcb79, "MacBookPro 5,5", CS420X_MBP55),
+ SND_PCI_QUIRK(0x8086, 0x7270, "IMac 27 Inch", CS420X_IMAC27),
{} /* terminator */
};

@@ -1097,8 +1101,23 @@ static struct cs_pincfg mbp55_pincfgs[] = {
{} /* terminator */
};

+static struct cs_pincfg imac27_pincfgs[] = {
+ { 0x09, 0x012b4050 },
+ { 0x0a, 0x90100140 },
+ { 0x0b, 0x90100142 },
+ { 0x0c, 0x018b3020 },
+ { 0x0d, 0x90a00110 },
+ { 0x0e, 0x400000f0 },
+ { 0x0f, 0x01cbe030 },
+ { 0x10, 0x014be060 },
+ { 0x12, 0x01ab9070 },
+ { 0x15, 0x400000f0 },
+ {} /* terminator */
+};
+
static struct cs_pincfg *cs_pincfgs[CS420X_MODELS] = {
[CS420X_MBP55] = mbp55_pincfgs,
+ [CS420X_IMAC27] = imac27_pincfgs,
};

static void fix_pincfg(struct hda_codec *codec, int model)
@@ -1128,6 +1147,7 @@ static int patch_cs420x(struct hda_codec *codec)
fix_pincfg(codec, spec->board_config);

switch (spec->board_config) {
+ case CS420X_IMAC27:
case CS420X_MBP55:
/* GPIO1 = headphones */
/* GPIO3 = speakers */
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 3d59f83..eeda7be 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -2104,6 +2104,7 @@ static unsigned int ref9205_pin_configs[12] = {
10280204
1028021F
10280228 (Dell Vostro 1500)
+ 10280229 (Dell Vostro 1700)
*/
static unsigned int dell_9205_m42_pin_configs[12] = {
0x0321101F, 0x03A11020, 0x400003FA, 0x90170310,
@@ -2189,6 +2190,8 @@ static struct snd_pci_quirk stac9205_cfg_tbl[] = {
"Dell Inspiron", STAC_9205_DELL_M44),
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0228,
"Dell Vostro 1500", STAC_9205_DELL_M42),
+ SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0229,
+ "Dell Vostro 1700", STAC_9205_DELL_M42),
/* Gateway */
SND_PCI_QUIRK(0x107b, 0x0560, "Gateway T6834c", STAC_9205_EAPD),
SND_PCI_QUIRK(0x107b, 0x0565, "Gateway T1616", STAC_9205_EAPD),
@@ -3779,15 +3782,16 @@ static int stac92xx_parse_auto_config(struct hda_codec *codec, hda_nid_t dig_out
err = snd_hda_attach_beep_device(codec, nid);
if (err < 0)
return err;
- /* IDT/STAC codecs have linear beep tone parameter */
- codec->beep->linear_tone = 1;
- /* if no beep switch is available, make its own one */
- caps = query_amp_caps(codec, nid, HDA_OUTPUT);
- if (codec->beep &&
- !((caps & AC_AMPCAP_MUTE) >> AC_AMPCAP_MUTE_SHIFT)) {
- err = stac92xx_beep_switch_ctl(codec);
- if (err < 0)
- return err;
+ if (codec->beep) {
+ /* IDT/STAC codecs have linear beep tone parameter */
+ codec->beep->linear_tone = 1;
+ /* if no beep switch is available, make its own one */
+ caps = query_amp_caps(codec, nid, HDA_OUTPUT);
+ if (!(caps & AC_AMPCAP_MUTE)) {
+ err = stac92xx_beep_switch_ctl(codec);
+ if (err < 0)
+ return err;
+ }
}
}

twitter

Wednesday, December 23, 2009

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

0 Comments:

Post a Comment

About Me

Previous Posts