* [PATCH Resend] bt8xxgpio: Check gpiochip_remove() result
From: Javier Martinez Canillas @ 2009-10-12 6:20 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <1255326344.23361.4.camel@laptop>
Forgot about checkpatch.pl, resending the patch. Sorry for the inconvenience.
Signed-off-by: Javier Martinez Canillas <martinez.javier@gmail.com>
---
drivers/gpio/bt8xxgpio.c | 33 +++++++++++++++++++--------------
1 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/bt8xxgpio.c b/drivers/gpio/bt8xxgpio.c
index 2559f22..b4aa126 100644
--- a/drivers/gpio/bt8xxgpio.c
+++ b/drivers/gpio/bt8xxgpio.c
@@ -242,20 +242,25 @@ err_freebg:
static void bt8xxgpio_remove(struct pci_dev *pdev)
{
struct bt8xxgpio *bg = pci_get_drvdata(pdev);
-
- gpiochip_remove(&bg->gpio);
-
- bgwrite(0, BT848_INT_MASK);
- bgwrite(~0x0, BT848_INT_STAT);
- bgwrite(0x0, BT848_GPIO_OUT_EN);
-
- iounmap(bg->mmio);
- release_mem_region(pci_resource_start(pdev, 0),
- pci_resource_len(pdev, 0));
- pci_disable_device(pdev);
-
- pci_set_drvdata(pdev, NULL);
- kfree(bg);
+ int ret;
+
+ ret = gpiochip_remove(&bg->gpio);
+
+ if (!ret) {
+ bgwrite(0, BT848_INT_MASK);
+ bgwrite(~0x0, BT848_INT_STAT);
+ bgwrite(0x0, BT848_GPIO_OUT_EN);
+
+ iounmap(bg->mmio);
+ release_mem_region(pci_resource_start(pdev, 0),
+ pci_resource_len(pdev, 0));
+ pci_disable_device(pdev);
+
+ pci_set_drvdata(pdev, NULL);
+ kfree(bg);
+ } else
+ dev_err(&pdev->dev, "Failed to remove the GPIO controller: \
+ %d\n", ret);
}
#ifdef CONFIG_PM
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] blk-settings: fix function parameter kernel-doc notation
From: Jens Axboe @ 2009-10-12 6:20 UTC (permalink / raw)
To: Randy Dunlap; +Cc: LKML
In-Reply-To: <4AD28E10.3010502@oracle.com>
On Sun, Oct 11 2009, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Fix kernel-doc notation in blk-settings.c::blk_queue_max_discard_sectors().
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> block/blk-settings.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks, applied.
--
Jens Axboe
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Bryan Kadzban @ 2009-10-12 6:21 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <20091010211352.GC1927@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Greg KH wrote:
> On Sat, Oct 10, 2009 at 10:34:16AM -0700, Bryan Kadzban wrote:
>> Greg KH wrote:
>>> On Sat, Oct 10, 2009 at 07:47:32AM -0500, Matt Domsch wrote:
>>>> On Fri, Oct 09, 2009 at 10:23:08PM -0700, Greg KH wrote:
>>>>> On Fri, Oct 09, 2009 at 11:40:57PM -0500, Matt Domsch wrote:
>>>>>> The fundamental roadblock to this is that enumeration !=
>>>>>> naming, except that it is for network devices, and we keep
>>>>>> changing the enumeration order.
>>>>> No, the hardware changes the enumeration order, it places
>>>>> _no_ guarantees on what order stuff will be found in. So
>>>>> this is not the kernel changing, just to be clear.
>>>> Over time the kernel has changed its enumeration mechanisms,
>>>> and introduced parallelism into the process (which is a good
>>>> thing), which, from a user perspective, makes names
>>>> nondeterministic. Yes, fixing this up by hard-coding MAC
>>>> addresses after install has been the traditional mechanism to
>>>> address this. I think there's a better way.
>>> Ok, but that way can be done in userspace, without the need for
>>> this char device, right?
>> For the record -- when I tried to send a patch that did exactly
>> this (provided an option to use by-path persistence for network
>> drivers), it was rejected because "that doesn't work for USB".
>>
>> True, it doesn't. But by-mac (what we have today) doesn't work for
>> replacing motherboards in a random home system (that can't override
>> the MAC address in the BIOS), either.
>
> If you replace a motherboard, you honestly expect no configuration to
> be needed to be changed? If so, then don't use the MAC naming scheme
> for your systems.
What else is there? biosdevname doesn't work with this BIOS. It looks
like at least path_id has been updated to work with NICs now, so that
might work, with a bit of custom rule hacking.
Or at least, it won't work any more poorly than for disks, which seem to
work pretty well... :-)
>>> But this code is not a requirement to "solve" the fact that
>>> network devices can show up in different order, that problem can
>>> be solved as long as the user picks a single way to name the
>>> devices, using tools that are already present today in distros.
>> This code is not a requirement, no. But -- as you say -- it does
>> provide a halfway-decent way to assign multiple names to a NIC.
>> And that provides admins the choice to use a couple different
>> persistence schemes, depending on how they expect their hardware to
>> work.
>
> But the names need to then be resolved back to a "real" kernel name
> in order to do anything with that network connection, as the char
> devices are not real ones. So that adds an additional layer of
> complexity on all of the system configuration tools.
Yes, that is true -- and no, this change isn't perfect. But it lets me
have multiple "names" per interface, and have "names" that are longer
than IFNAMSIZ, though, which is why I like it.
(Now, if open() would return effectively a netlink socket bound to that
ifindex already, such that the program didn't need to fill in the
various ifindex fields for e.g. rtnetlink... but it's probably really
hard to do that, so this isn't a serious suggestion.)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [Autotest] [PATCH] Fix a bug in function create in kvm_vm
From: Lucas Meneghel Rodrigues @ 2009-10-11 23:53 UTC (permalink / raw)
To: Yolkfull Chow; +Cc: kvm, autotest
In-Reply-To: <20091010084825.GE2487@aFu.nay.redhat.com>
On Sat, 2009-10-10 at 16:48 +0800, Yolkfull Chow wrote:
> On Sat, Oct 10, 2009 at 04:24:45PM +0800, Yolkfull Chow wrote:
> > On Mon, Oct 05, 2009 at 04:03:22PM -0300, Lucas Meneghel Rodrigues wrote:
> > > Hi Yolkfull! I've checked your patch, but it turns out that the comma
> > > is valid syntax for the logging module. By any chance you actually had
> > > an error with it?
> >
> > Hi Lucas,
> > I just checked, yes it's valid syntax for this module. Before this I met
> > a traceback during running autotest and it indicated this line
> > around,thus I doubt about this by mistake. Sorry for confusing. ;-)
> >
> > But I found for the variables in logging.debug(),sometimes it use comma
> > to format while sometimes '%' which will drop code readability.
>
> Another reason is if someone who still using kvm_log want to backport
> codes from this tree, not only need he replace all 'logging' with
> 'kvm_log' but also need change these comma syntax. ;-)
Yes, we prefer using comma on logging statements allways, but sometimes
we make mistakes and use the standard string format with %.
When porting code, try to keep in mind that and try to use allways the
comma, but don't worry too much about it... just general guidelines :)
Lucas
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Bryan Kadzban @ 2009-10-12 6:21 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <20091010211352.GC1927@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Greg KH wrote:
> On Sat, Oct 10, 2009 at 10:34:16AM -0700, Bryan Kadzban wrote:
>> Greg KH wrote:
>>> On Sat, Oct 10, 2009 at 07:47:32AM -0500, Matt Domsch wrote:
>>>> On Fri, Oct 09, 2009 at 10:23:08PM -0700, Greg KH wrote:
>>>>> On Fri, Oct 09, 2009 at 11:40:57PM -0500, Matt Domsch wrote:
>>>>>> The fundamental roadblock to this is that enumeration !=
>>>>>> naming, except that it is for network devices, and we keep
>>>>>> changing the enumeration order.
>>>>> No, the hardware changes the enumeration order, it places
>>>>> _no_ guarantees on what order stuff will be found in. So
>>>>> this is not the kernel changing, just to be clear.
>>>> Over time the kernel has changed its enumeration mechanisms,
>>>> and introduced parallelism into the process (which is a good
>>>> thing), which, from a user perspective, makes names
>>>> nondeterministic. Yes, fixing this up by hard-coding MAC
>>>> addresses after install has been the traditional mechanism to
>>>> address this. I think there's a better way.
>>> Ok, but that way can be done in userspace, without the need for
>>> this char device, right?
>> For the record -- when I tried to send a patch that did exactly
>> this (provided an option to use by-path persistence for network
>> drivers), it was rejected because "that doesn't work for USB".
>>
>> True, it doesn't. But by-mac (what we have today) doesn't work for
>> replacing motherboards in a random home system (that can't override
>> the MAC address in the BIOS), either.
>
> If you replace a motherboard, you honestly expect no configuration to
> be needed to be changed? If so, then don't use the MAC naming scheme
> for your systems.
What else is there? biosdevname doesn't work with this BIOS. It looks
like at least path_id has been updated to work with NICs now, so that
might work, with a bit of custom rule hacking.
Or at least, it won't work any more poorly than for disks, which seem to
work pretty well... :-)
>>> But this code is not a requirement to "solve" the fact that
>>> network devices can show up in different order, that problem can
>>> be solved as long as the user picks a single way to name the
>>> devices, using tools that are already present today in distros.
>> This code is not a requirement, no. But -- as you say -- it does
>> provide a halfway-decent way to assign multiple names to a NIC.
>> And that provides admins the choice to use a couple different
>> persistence schemes, depending on how they expect their hardware to
>> work.
>
> But the names need to then be resolved back to a "real" kernel name
> in order to do anything with that network connection, as the char
> devices are not real ones. So that adds an additional layer of
> complexity on all of the system configuration tools.
Yes, that is true -- and no, this change isn't perfect. But it lets me
have multiple "names" per interface, and have "names" that are longer
than IFNAMSIZ, though, which is why I like it.
(Now, if open() would return effectively a netlink socket bound to that
ifindex already, such that the program didn't need to fill in the
various ifindex fields for e.g. rtnetlink... but it's probably really
hard to do that, so this isn't a serious suggestion.)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: David Miller @ 2009-10-12 6:22 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255328031-17189-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 23:13:51 -0700
> Use phys_addr_t data type for pci resource address
> instead of unsigned long. This fixes mapping of
> pci resources where resource addresses can be larger
> than word size (e.g. PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Lazy, you didn't update the commit log message to match the
change you made to the patch.
I think I'll just ignore your patches for a while until
you start to be a little bit less careless.
Thanks.
^ permalink raw reply
* [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-12 6:19 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
It's nice to search for an author by merely clicking on their name in
gitweb. This is usually faster than selecting the name, copying the
selection, pasting it into the search box, selecting between
author/committer and then hitting enter.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Cc'ed Jakub as he seems to be resident gitweb expert.
I thought this might be a nice addition.
The problem is I can't get it to work with UTF-8 characters. I'm not sure
if it's my system or not, so I'm just posting here to see if others
experience the same problem and if there's interest.
gitweb/gitweb.perl | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..349e734 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1604,7 +1604,10 @@ sub format_author_html {
my $author = chop_and_escape_str($co->{'author_name'}, @_);
return "<$tag class=\"author\">" .
git_get_avatar($co->{'author_email'}, -pad_after => 1) .
- $author . "</$tag>";
+ $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$co->{'author_name'},
+ searchtype=>"author"), class=>"list"}, $author) .
+ "</$tag>";
}
# format git diff header line, i.e. "diff --(git|combined|cc) ..."
@@ -3373,10 +3376,13 @@ sub git_print_authorship {
my $co = shift;
my %opts = @_;
my $tag = $opts{-tag} || 'div';
+ my $author = $co->{'author_name'};
my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
print "<$tag class=\"author_date\">" .
- esc_html($co->{'author_name'}) .
+ $cgi->a({-href => href(action=>"search", searchtext=>$author,
+ searchtype=>"author"), class=>"list"},
+ esc_html($author)) .
" [$ad{'rfc2822'}";
print_local_time(%ad) if ($opts{-localtime});
print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
@@ -3395,8 +3401,12 @@ sub git_print_authorship_rows {
@people = ('author', 'committer') unless @people;
foreach my $who (@people) {
my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
- print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
- "<td rowspan=\"2\">" .
+ print "<tr><td>$who</td><td>" .
+ $cgi->a({-href => href(action=>"search",
+ searchtext=>$co->{"${who}_name"},
+ searchtype=>$who), class=>"list"},
+ esc_html($co->{$who})) .
+ "</td><td rowspan=\"2\">" .
git_get_avatar($co->{"${who}_email"}, -size => 'double') .
"</td></tr>\n" .
"<tr>" .
--
1.6.5.1.g53fd
^ permalink raw reply related
* Re: [PATCH 2/3]: mtdoops: Use panic_write if panic_on_oops is set
From: Simon Kagstrom @ 2009-10-12 6:23 UTC (permalink / raw)
To: dedekind1; +Cc: Artem.Bityutskiy, linux-mtd, Aaro Koskinen
In-Reply-To: <1255240820.3359.33.camel@localhost>
On Sun, 11 Oct 2009 09:00:20 +0300
Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Thu, 2009-10-08 at 08:28 +0300, Artem Bityutskiy wrote:
>
> > > - if (mtd->panic_write && in_interrupt())
> > > + if (mtd->panic_write && (in_interrupt() || panic_on_oops))
> > > /* Interrupt context, we're going to panic so try and log */
> > > mtdoops_write(cxt, 1);
>
> Oh, panic_on_oops is not exported. So we should either export it or make
> mtdoops to be always compiled-in.
Yep, in the earlier patch series (this one!) I made it always
compiled-in, but for new one I kept the module support and also sent
a patch to LKML which exports panic_on_oops. I saw you did the same
thing now, thanks!
// Simon
^ permalink raw reply
* Re: [PATCH] mm: make VM_MAX_READAHEAD configurable
From: Wu Fengguang @ 2009-10-12 6:23 UTC (permalink / raw)
To: Christian Ehrhardt
Cc: Martin Schwidefsky, Jens Axboe, Peter Zijlstra,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton
In-Reply-To: <4AD2C43D.1080804@linux.vnet.ibm.com>
On Mon, Oct 12, 2009 at 01:53:01PM +0800, Christian Ehrhardt wrote:
> Wu Fengguang wrote:
> > Hi Martin,
> >
> > On Fri, Oct 09, 2009 at 09:49:50PM +0800, Martin Schwidefsky wrote:
> >
> >> On Fri, 9 Oct 2009 14:29:52 +0200
> >> Jens Axboe <jens.axboe@oracle.com> wrote:
> >>
> >>
> >>> On Fri, Oct 09 2009, Peter Zijlstra wrote:
> >>>
> >>>> On Fri, 2009-10-09 at 13:19 +0200, Ehrhardt Christian wrote:
> >>>>
> >>>>> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> >>>>>
> >>>>> On one hand the define VM_MAX_READAHEAD in include/linux/mm.h is just a default
> >>>>> and can be configured per block device queue.
> >>>>> On the other hand a lot of admins do not use it, therefore it is reasonable to
> >>>>> set a wise default.
> >>>>>
> >>>>> This path allows to configure the value via Kconfig mechanisms and therefore
> >>>>> allow the assignment of different defaults dependent on other Kconfig symbols.
> >>>>>
> >>>>> Using this, the patch increases the default max readahead for s390 improving
> >>>>> sequential throughput in a lot of scenarios with almost no drawbacks (only
> >>>>> theoretical workloads with a lot concurrent sequential read patterns on a very
> >>>>> low memory system suffer due to page cache trashing as expected).
> >>>>>
> > [snip]
> >
> >> The patch from Christian fixes a performance regression in the latest
> >> distributions for s390. So we would opt for a larger value, 512KB seems
> >> to be a good one. I have no idea what that will do to the embedded
> >> space which is why Christian choose to make it configurable. Clearly
> >> the better solution would be some sort of system control that can be
> >> modified at runtime.
> >>
> >
> > May I ask for more details about your performance regression and why
> > it is related to readahead size? (we didn't change VM_MAX_READAHEAD..)
> >
> Sure, the performance regression appeared when comparing Novell SLES10
> vs. SLES11.
> While you are right Wu that the upstream default never changed so far,
> SLES10 had a
> patch applied that set 512.
I see. I'm curious why SLES11 removed that patch. Did it experienced
some regressions with the larger readahead size?
> As mentioned before I didn't expect to get a generic 128->512 patch
> accepted,therefore
> the configurable solution. But after Peter and Jens replied so quickly
> stating that
> changing the default in kernel would be the wrong way to go I already
> looked out for
> userspace alternatives. At least for my issues I could fix it with
> device specific udev rules
> too.
OK.
> And as Andrew mentioned the diversity of devices cause any default to be
> wrong for one
> or another installation. To solve that the udev approach can also differ
> between different
> device types (might be easier on s390 than on other architectures
> because I need to take
> care of two disk types atm - and both shold get 512).
I guess it's not a general solution for all. There are so many
devices in the world, and we have not yet considered the
memory/workload combinations.
> The testcase for anyone who wants to experiment with it is almost too
> easy, the biggest
> impact can be seen with single thread iozone - I get ~40% better
> throughput when
> increasing the readahead size to 512 (even bigger RA sizes don't help
> much in my
> environment, probably due to fast devices).
That's impressive number - I guess we need a larger default RA size.
But before that let's learn something from SLES10's experiences :)
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] mm: make VM_MAX_READAHEAD configurable
From: Wu Fengguang @ 2009-10-12 6:23 UTC (permalink / raw)
To: Christian Ehrhardt
Cc: Martin Schwidefsky, Jens Axboe, Peter Zijlstra,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton
In-Reply-To: <4AD2C43D.1080804@linux.vnet.ibm.com>
On Mon, Oct 12, 2009 at 01:53:01PM +0800, Christian Ehrhardt wrote:
> Wu Fengguang wrote:
> > Hi Martin,
> >
> > On Fri, Oct 09, 2009 at 09:49:50PM +0800, Martin Schwidefsky wrote:
> >
> >> On Fri, 9 Oct 2009 14:29:52 +0200
> >> Jens Axboe <jens.axboe@oracle.com> wrote:
> >>
> >>
> >>> On Fri, Oct 09 2009, Peter Zijlstra wrote:
> >>>
> >>>> On Fri, 2009-10-09 at 13:19 +0200, Ehrhardt Christian wrote:
> >>>>
> >>>>> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> >>>>>
> >>>>> On one hand the define VM_MAX_READAHEAD in include/linux/mm.h is just a default
> >>>>> and can be configured per block device queue.
> >>>>> On the other hand a lot of admins do not use it, therefore it is reasonable to
> >>>>> set a wise default.
> >>>>>
> >>>>> This path allows to configure the value via Kconfig mechanisms and therefore
> >>>>> allow the assignment of different defaults dependent on other Kconfig symbols.
> >>>>>
> >>>>> Using this, the patch increases the default max readahead for s390 improving
> >>>>> sequential throughput in a lot of scenarios with almost no drawbacks (only
> >>>>> theoretical workloads with a lot concurrent sequential read patterns on a very
> >>>>> low memory system suffer due to page cache trashing as expected).
> >>>>>
> > [snip]
> >
> >> The patch from Christian fixes a performance regression in the latest
> >> distributions for s390. So we would opt for a larger value, 512KB seems
> >> to be a good one. I have no idea what that will do to the embedded
> >> space which is why Christian choose to make it configurable. Clearly
> >> the better solution would be some sort of system control that can be
> >> modified at runtime.
> >>
> >
> > May I ask for more details about your performance regression and why
> > it is related to readahead size? (we didn't change VM_MAX_READAHEAD..)
> >
> Sure, the performance regression appeared when comparing Novell SLES10
> vs. SLES11.
> While you are right Wu that the upstream default never changed so far,
> SLES10 had a
> patch applied that set 512.
I see. I'm curious why SLES11 removed that patch. Did it experienced
some regressions with the larger readahead size?
> As mentioned before I didn't expect to get a generic 128->512 patch
> accepted,therefore
> the configurable solution. But after Peter and Jens replied so quickly
> stating that
> changing the default in kernel would be the wrong way to go I already
> looked out for
> userspace alternatives. At least for my issues I could fix it with
> device specific udev rules
> too.
OK.
> And as Andrew mentioned the diversity of devices cause any default to be
> wrong for one
> or another installation. To solve that the udev approach can also differ
> between different
> device types (might be easier on s390 than on other architectures
> because I need to take
> care of two disk types atm - and both shold get 512).
I guess it's not a general solution for all. There are so many
devices in the world, and we have not yet considered the
memory/workload combinations.
> The testcase for anyone who wants to experiment with it is almost too
> easy, the biggest
> impact can be seen with single thread iozone - I get ~40% better
> throughput when
> increasing the readahead size to 512 (even bigger RA sizes don't help
> much in my
> environment, probably due to fast devices).
That's impressive number - I guess we need a larger default RA size.
But before that let's learn something from SLES10's experiences :)
Thanks,
Fengguang
^ permalink raw reply
* Re: [net-next PATCH 0/8] qlge: Cleanup and additions for qlge.
From: David Miller @ 2009-10-12 6:26 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1255203310-18114-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:02 -0700
>
> Cleanup and a couple of small performance tweeks for qlge.
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: Audo capture not working with HP 9000 laptop and 2.6.32 kernel
From: Takashi Iwai @ 2009-10-12 6:30 UTC (permalink / raw)
To: Corey Boyle; +Cc: alsa-devel
In-Reply-To: <41e5da3e0910110453w1e48da13x6c0a9ce5b17b9b2c@mail.gmail.com>
At Sun, 11 Oct 2009 20:53:15 +0900,
Corey Boyle wrote:
>
> Hi
>
> I have an HP 9000 series laptop with an Intel HD sound card and Realtek
> ALC298 codec. I am having a problem with audio capture ever since upgrading
> to the 2.6.32 kernel series from 2.6.31. I have git bisected to this
> commit: 33d78674586aeb6a623b1e612e6f92dd83015ed3 "ALSA: hda - Use auto model
> for HP laptops with ALC268 codec". After this commit I am not able to
> capture audio and using alsamixer I am not able to choose the input source.
> I was using "Front Mic" as the input source when this was working in
> 2.6.31. I have uploaded my configuration using alsa-info before and after
> the commit.
>
> Before change
> http://www.alsa-project.org/db/?f=4f5d3eb02d4d62fa044a4eb0a3aae2614064b208
>
> After change
> http://www.alsa-project.org/db/?f=a9583da102419a9233cc469259c85ab81645d555
>
> Could someone please provide some help in getting this working, presumably
> without rolling back the previously mentioned commit? I am not familiar
> with how the alsa code works but am willing to help out if given some
> guidance.
This should have been fixed on 2.6.32-rc4. Give it a try.
The input source element is gone now for your devices, and the driver
chooses the capture source automatically per mic-jack plug.
Takashi
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.232203.41690616.davem@davemloft.net>
Huh, okay I was impatient. I will make one more attempt to pass the test.
Thanks.
David Miller wrote:
> I think I'll just ignore your patches for a while until
> you start to be a little bit less careless.
>
> Thanks.
>
^ permalink raw reply
* [U-Boot] [PATCH v3 3/3] ppc/p1_p2_RDB: DDR Relocation support for NAND/SD/eSPI Boot
From: Dudhat Dipen-B09055 @ 2009-10-12 6:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <8F62BE2A-0087-4B1D-B885-77D04C197FFC@kernel.crashing.org>
Hi Kumar,
I have tried using "fsl_ddr_set_memctl_regs()".
But this can't get fit into 4K NAND_SPL Loader.
Regards,
Dipen
>
> On Oct 9, 2009, at 12:42 PM, Dipen Dudhat wrote:
>
>> +void initsdram(void)
>> +{
>> +
>> + volatile ccsr_ddr_t *ddr= (ccsr_ddr_t
> *)CONFIG_SYS_MPC85xx_DDR_ADDR;
>> + int d_init, dbw;
>> + volatile ccsr_gpio_t *pgpio = (void *)
>> (CONFIG_SYS_MPC85xx_GPIO_ADDR);
>> + unsigned int ddr_size;
>> + sys_info_t sysinfo;
>> + phys_size_t dram_size = 0;
>> +
>> + set_next_law(0,LAW_SIZE_1G , LAW_TRGT_IF_DDR_1);
>> +
>> + out_be32(&ddr->cs0_bnds, CONFIG_SYS_DDR_CS0_BNDS);
>> + out_be32(&ddr->cs0_config, CONFIG_SYS_DDR_CS0_CONFIG);
>> + out_be32(&ddr->cs0_config_2, CONFIG_SYS_DDR_CS0_CONFIG_2);
>> +
>> + out_be32(&ddr->timing_cfg_3, CONFIG_SYS_DDR_TIMING_3_667);
>> + out_be32(&ddr->timing_cfg_0, CONFIG_SYS_DDR_TIMING_0_667);
>> + out_be32(&ddr->timing_cfg_1, CONFIG_SYS_DDR_TIMING_1_667);
>> + out_be32(&ddr->timing_cfg_2, CONFIG_SYS_DDR_TIMING_2_667);
>> + out_be32(&ddr->sdram_mode, CONFIG_SYS_DDR_MODE_1_667);
>> + out_be32(&ddr->sdram_mode_2, CONFIG_SYS_DDR_MODE_2_667);
>> + out_be32(&ddr->sdram_interval, CONFIG_SYS_DDR_INTERVAL_667);
>> + out_be32(&ddr->sdram_clk_cntl, CONFIG_SYS_DDR_CLK_CTRL_667);
>> + out_be32(&ddr->sdram_cfg, CONFIG_SYS_DDR_CONTROL);
>> + out_be32(&ddr->sdram_cfg_2, CONFIG_SYS_DDR_CONTROL_2);
>
> did fsl_ddr_set_memctl_regs() not work?
>
> This function will take more space as we have only 4K space here.
> And this function contains 'printf' statements which is not valid.
>
> So I think this is the simplest approach, as fsl_ddr_set_memctl_regs()
> is doing the same thing.
> What do you suggest??
We can dummy out the printf. I'd prefer if we can try and use it. It
unifies the register setting in one place which is key.
- k
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Sverre Rabbelier @ 2009-10-12 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx9pmhae.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Oct 12, 2009 at 05:18, Junio C Hamano <gitster@pobox.com> wrote:
> [Stalled]
>
> * sr/gfi-options (2009-09-06) 6 commits.
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: test the new feature command
> - fast-import: add feature command
> - fast-import: put marks reading in it's own function
> - fast-import: put option parsing code in separate functions
>
> Ejected from 'next' as fast-import folks still seem to be discussing with
> how to proceed.
Thanks, I hope to have this re-rolled before 1.6.6 goes into RC.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Vietor Liu @ 2009-10-12 6:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
When the screen height equal 600 px(e.g. Asus EeePC 1024x600), The
_main window_ should be hide the _Push button_ and _Status bar_.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] [snd-usb-audio] Add match for JMTek USB sound card
From: Takashi Iwai @ 2009-10-12 6:32 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: alsa-devel, linux-kernel, linux-sound
In-Reply-To: <1255173329-20485-1-git-send-email-lkundrak@v3.sk>
At Sat, 10 Oct 2009 13:15:29 +0200,
Lubomir Rintel wrote:
>
> Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
The change look OK (suppose it was tested :)
Could you give your sign-off to merge to the upstream?
thanks,
Takashi
> ---
> sound/usb/usbquirks.h | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
> index f6f201e..e98ff4c 100644
> --- a/sound/usb/usbquirks.h
> +++ b/sound/usb/usbquirks.h
> @@ -80,6 +80,19 @@
> .bInterfaceClass = USB_CLASS_AUDIO,
> },
>
> +/* JMTek, LLC. SSS USB Headphone Set */
> +{
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> + USB_DEVICE_ID_MATCH_DEV_CLASS |
> + USB_DEVICE_ID_MATCH_INT_CLASS |
> + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> + .idVendor = 0x0c76,
> + .idProduct = 0x1605,
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bInterfaceClass = USB_CLASS_AUDIO,
> + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> +},
> +
> /*
> * Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
> * class matches do not take effect without an explicit ID match.
> --
> 1.6.5.rc2
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: [alsa-devel] [PATCH] [snd-usb-audio] Add match for JMTek USB sound card
From: Takashi Iwai @ 2009-10-12 6:32 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: alsa-devel, linux-sound, linux-kernel
In-Reply-To: <1255173329-20485-1-git-send-email-lkundrak@v3.sk>
At Sat, 10 Oct 2009 13:15:29 +0200,
Lubomir Rintel wrote:
>
> Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
The change look OK (suppose it was tested :)
Could you give your sign-off to merge to the upstream?
thanks,
Takashi
> ---
> sound/usb/usbquirks.h | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
> index f6f201e..e98ff4c 100644
> --- a/sound/usb/usbquirks.h
> +++ b/sound/usb/usbquirks.h
> @@ -80,6 +80,19 @@
> .bInterfaceClass = USB_CLASS_AUDIO,
> },
>
> +/* JMTek, LLC. SSS USB Headphone Set */
> +{
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> + USB_DEVICE_ID_MATCH_DEV_CLASS |
> + USB_DEVICE_ID_MATCH_INT_CLASS |
> + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> + .idVendor = 0x0c76,
> + .idProduct = 0x1605,
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bInterfaceClass = USB_CLASS_AUDIO,
> + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> +},
> +
> /*
> * Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
> * class matches do not take effect without an explicit ID match.
> --
> 1.6.5.rc2
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: [alsa-devel] [PATCH] [snd-usb-audio] Add match for JMTek USB sound card
From: Takashi Iwai @ 2009-10-12 6:32 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: alsa-devel, linux-sound, linux-kernel
In-Reply-To: <1255173329-20485-1-git-send-email-lkundrak@v3.sk>
At Sat, 10 Oct 2009 13:15:29 +0200,
Lubomir Rintel wrote:
>
> Entry for JMTek LLC., SSS USB Headphone Set in the quirk table.
The change look OK (suppose it was tested :)
Could you give your sign-off to merge to the upstream?
thanks,
Takashi
> ---
> sound/usb/usbquirks.h | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/sound/usb/usbquirks.h b/sound/usb/usbquirks.h
> index f6f201e..e98ff4c 100644
> --- a/sound/usb/usbquirks.h
> +++ b/sound/usb/usbquirks.h
> @@ -80,6 +80,19 @@
> .bInterfaceClass = USB_CLASS_AUDIO,
> },
>
> +/* JMTek, LLC. SSS USB Headphone Set */
> +{
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE |
> + USB_DEVICE_ID_MATCH_DEV_CLASS |
> + USB_DEVICE_ID_MATCH_INT_CLASS |
> + USB_DEVICE_ID_MATCH_INT_SUBCLASS,
> + .idVendor = 0x0c76,
> + .idProduct = 0x1605,
> + .bDeviceClass = USB_CLASS_PER_INTERFACE,
> + .bInterfaceClass = USB_CLASS_AUDIO,
> + .bInterfaceSubClass = USB_SUBCLASS_AUDIO_CONTROL
> +},
> +
> /*
> * Logitech QuickCam: bDeviceClass is vendor-specific, so generic interface
> * class matches do not take effect without an explicit ID match.
> --
> 1.6.5.rc2
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: Bt87x unknown card
From: Takashi Iwai @ 2009-10-12 6:35 UTC (permalink / raw)
To: Adriano; +Cc: alsa-devel
In-Reply-To: <5f89296f0910080640x2a757e69sa344a3afe8e0fb69@mail.gmail.com>
At Thu, 8 Oct 2009 15:40:18 +0200,
Adriano wrote:
>
> Hi I've this Pinnacle PCTV card: 11bd:0012 with this multimedia audio
> controller:
>
> 02:02.1 Multimedia controller [0480]: Brooktree Corporation Bt878
> Audio Capture [109e:0878] (rev 11)
> Subsystem: Pinnacle Systems Inc. PCTV pro (TV + FM stereo
> receiver, audio section) [11bd:0012]
> Flags: bus master, medium devsel, latency 32, IRQ 23
> Memory at f7eff000 (32-bit, prefetchable) [size=4K]
> Capabilities: <access denied>
> Kernel driver in use: Bt87x
>
> I have no audio with alsa, when I loaded snd-bt87x, I received this
> error in dmesg:
>
> [ 1951.383480] unknown card 0x878-0x11bd:0x12
> [ 1951.383484] please mail id, board name, and, if it works, the
> correct digital_rate option to <alsa-devel@alsa-project.org>
> [ 1951.383518] Bt87x 0000:02:02.1: PCI INT A -> GSI 23 (level, low) -> IRQ 23
> [ 1951.383741] bt87x0: Using board 0, analog, digital (rate 32000 Hz)
>
> Can you tell me the problem and any solution?
Does the device work properly as is now, especially about the digital
rate? If yes, I can add the quirk entry to shut the message up.
thanks,
Takashi
^ permalink raw reply
* [PATCH] [ARM] kirkwood: combine support for openrd base/client support
From: Dieter Kiermaier @ 2009-10-12 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20091009152407.GE6085@chipmunk>
Hi Alexander,
> Hi,
>
> * Dieter Kiermaier <dk-arm-linux@gmx.de> [2009-10-09 16:00:44+0200]:
> >
> > [snipped]
> >
> > Additionally it would be nice, if you could integrate the i2c / pcie init in your patch?
> > Please see Simons patch at:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/001950.html
> >
> Well on my Client board I get:
> ----
> northdown:~# dmesg | grep -i PCI
> pci 0000:00:00.0: reg 10 64bit mmio pref: [0xf1000000-0xf10fffff]
> pci 0000:00:00.0: reg 18 32bit mmio: [0x000000-0x1fffffff]
> pci 0000:00:00.0: supports D1 D2
> PCI: bus0: Fast back to back transfers disabled
>
> northdown:~# lspci -vvv
> 00:00.0 Memory controller: Marvell Technology Group Ltd. Device 6281 (rev 02)
> Subsystem: Marvell Technology Group Ltd. Device 11ab
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 9
> Region 0: Memory at <ignored> (64-bit, prefetchable)
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [60] Express (v1) Root Port (Slot-), MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us
> ExtTag- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 unlimited
> ClockPM+ Suprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
> RootCap: CRSVisible-
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> Capabilities: [100] Advanced Error Reporting <?>
> ----
>
> I guess it is working fine, however as there is no PCI(e) slot to use,
> I'm going to disable the call for the OpenRD Client as it's pointless;
> unless someone objects?
Hm, I guess on your client board there is the VGA controller connected to the PCIe port?
So I would left the pcie init call active!
Dieter
>
> Cheers
>
^ permalink raw reply
* Re: [patch] perf build questions
From: Ingo Molnar @ 2009-10-12 6:35 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, Peter Zijlstra, Paul Mackerras
In-Reply-To: <20091005131729.78444bfb.randy.dunlap@oracle.com>
* Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Also, I see build errors/warnings (-Werror). Others aren't seeing these?
> Just due to my gcc version?
Thanks for the fix. Which GCC version is this btw?
Ingo
^ permalink raw reply
* Re: [RFC/PATCH] git: add --no-replace option to disable replacing
From: Johannes Sixt @ 2009-10-12 6:32 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Jakub Narebski, bill lam, Andreas Schwab
In-Reply-To: <20091011153227.8487.81803.chriscool@tuxfamily.org>
Christian Couder schrieb:
> So there is no way to disable it for some commands, which is annoying
> when we want to get information about a commit that has been replaced.
>
> For example:
>
> $ git cat-file -p N
>
> would output information about the replacement commit if commit N is
> replaced.
>
> With the "--no-replace" option that this patch adds it is possible to
> get information about the original commit using:
>
> $ git --no-replace cat-file -p N
I think it makes sense. But given the exotic nature of this option, I'd
prefer a more specific name, e.g., --no-replace-objects.
-- Hannes
^ permalink raw reply
* Re: [PATCHv2] Rename -Wall to Wsparse-all, so it doesn't get turned on unintentionally
From: Josh Triplett @ 2009-10-12 6:25 UTC (permalink / raw)
To: Christopher Li; +Cc: linux-sparse
In-Reply-To: <70318cbf0910112246w3cdb386fjc12f0be4ff135220@mail.gmail.com>
On Sun, Oct 11, 2009 at 10:46:25PM -0700, Christopher Li wrote:
> On Sun, Oct 11, 2009 at 3:47 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > v2: Update cgcc and remove unnecessary (and now ignored) -Wall from a
> > test case.
>
> Applied. BTW, what do you think about moving the logic from cgcc into
> sparse directly?
Definitely a good idea.
The logic in cgcc seems to fall in two main categories:
architecture-specific code and code to launch the C compiler. The
former should definitely live in sparse itself, because otherwise sparse
doesn't have all the proper built-in definitions when launched directly;
I'd like to *avoid* the GCC approach of only supporting one architecture
(or architecture family) at a time, though, and instead let the caller
specify any architecture sparse supports. As for launching the
compiler, it would prove fairly straightforward for sparse to strip any
sparse-specific warning options from its command line and then launch
$CC; in fact, if sparse did so right before exiting, it could just call
exec and avoid the need to fork.
- Josh Triplett
^ permalink raw reply
* [RFC] Re-order of PXA-based platforms in Kconfig and Makefile
From: Uwe Kleine-König @ 2009-10-12 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f17812d70910111838n28570cd6r6eb5d6e63eb4b692@mail.gmail.com>
Hello,
On Mon, Oct 12, 2009 at 09:38:02AM +0800, Eric Miao wrote:
> + bool "Enable supprot for CSB701 baseboard"
s/supprot/support/
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.