Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: [PATCH] p54usb: Remove duplicate Medion MD40900 device id
From: Larry Finger @ 2010-06-18 15:06 UTC (permalink / raw)
  To: John W. Linville; +Cc: Leann Ogasawara, flamingice, linux-wireless, Ben Collins
In-Reply-To: <20100615194610.GB2415@tuxdriver.com>

On 06/15/2010 02:46 PM, John W. Linville wrote:
> On Tue, Jun 15, 2010 at 10:59:05AM -0700, Leann Ogasawara wrote:
>> On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
> 
>>> So, I guess you are concerned about the groupings because of the
>>> different firmwares or something like that?  Perhaps a comment that
>>> says "this could be a version 2 device" is just as handy?  Since the
>>> driver prints the name of the firmware it wants, is there any real
>>> need for grouping the IDs?
>>>
>>> OTOH, is there any actual harm from the duplicate entry?  It "seems"
>>> wrong to me too, but I guess it does no harm...?
>>
>> I don't believe there is any harm from the duplicate entry, it just
>> seemed unnecessary.
>>
>>> Leann and/or Ben, was this just tidying-up?  I'm guessing there wasn't
>>> an actual bug involved?
>>
>> Indeed, this was just a patch we'd been carrying to tidy things up.
>> There was no actual bug involved.  I'd be happy to send a v2 of the
>> patch which comments out the duplicate entry and adds a note as to why.
>> Or I'd be fine just leaving the code as is and we'll drop the patch
>> we're carrying locally in Ubuntu.
> 
> FWIW, I like the 'comment-out and add a note' option.

I'm a little late here after being offline, but I too like the comment
out option.

Larry

^ permalink raw reply

* Re: pull request: wireless-next-2.6 2010-06-17
From: David Miller @ 2010-06-18 16:01 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100617210242.GB2368@tuxdriver.com>

From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 17 Jun 2010 17:02:42 -0400

> Another week, another bunch of patches intende for 2.6.36...
> This week's batch includes the usual updates to ath5k, ath9k,
> iwlwifi, rt2x00, and other drivers.  Also included are a lot of
> cleanup/maintenance for mac80211 from Johannes and some IBSS-related
> changes from Teemu, as well as a number of other patches from a
> variety of contributors.
> 
> Please let me know if there are problems!

Pulled, thanks JOhn.

^ permalink raw reply

* Re: [PATCH 1/2] ath9k_htc: Add AP mode to supported modes
From: Pavel Roskin @ 2010-06-18 16:33 UTC (permalink / raw)
  To: Sujith; +Cc: linville, linux-wireless
In-Reply-To: <19481.60102.659111.953695@gargle.gargle.HOWL>

On Thu, 2010-06-17 at 14:58 +0530, Sujith wrote:
> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
> ---
>  drivers/net/wireless/ath/ath9k/htc_drv_init.c |    3 ++-
>  drivers/net/wireless/ath/ath9k/htc_drv_main.c |    3 +++
>  2 files changed, 5 insertions(+), 1 deletions(-)

I confirm that the AP mode is working on TP-Link TL-WN422G (0cf3:1006).
I tested both patched of the series at once.

That's great news!  TL-WN422G has an external antenna, connects over USB
and supports AP mode.  Users keep asking about that combination of
features.  Now we have an answer :-)

-- 
Regards,
Pavel Roskin

^ permalink raw reply

* Re: USB device that supports master mode?
From: Pavel Roskin @ 2010-06-18 16:39 UTC (permalink / raw)
  To: Denis 'GNUtoo' Carikli; +Cc: Robert Urban, linux-wireless
In-Reply-To: <1276871717.918.1.camel@gnutoo-laptop>

On Fri, 2010-06-18 at 16:35 +0200, Denis 'GNUtoo' Carikli wrote:
> On Wed, 2010-06-09 at 02:08 +0200, Robert Urban wrote:
> > Hello Wireless folks,
> > 
> > I'm looking for a USB device that supports master mode, preferably with a
> > connection for an external antenna.
> > 
> > Does anyone know of specific products that satisy these criteria?
> > 
> > thanks,
> > 
> > Rob Urban
> I've a rt3070 that can do access point,
> I've tried it with wireless-compat and it worked.
> But I've not used it extensively(I plan to do so altough because of the
> good range.)
> It also has a connector for the antenna,but I don't know the brand,
> there is no brand written on it.

TP-Link TL-WN422G has an external antenna, it's a USB device and it
supports master mode with the patches for ath9k_htc that were recently
posted:

http://marc.info/?t=127676699200001&r=1&w=3

The device appears to be capable of 802.11n, even though that capability
is not advertised on the box.  I haven't run any benchmarks though.

-- 
Regards,
Pavel Roskin

^ permalink raw reply

* [PATCH] ath5k: initialize ah->ah_current_channel
From: Bob Copeland @ 2010-06-18 17:15 UTC (permalink / raw)
  To: linville, sbrown; +Cc: linux-wireless, ath5k-devel, Bob Copeland, stable

ath5k assumes ah_current_channel is always a valid pointer in
several places, but a newly created interface may not have a
channel.  To avoid null pointer dereferences, set it up to point
to the first available channel until later reconfigured.

This fixes the following oops:
$ rmmod ath5k
$ insmod ath5k
$ iw phy0 set distance 11000

BUG: unable to handle kernel NULL pointer dereference at 00000006
IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
*pde = 00000000
Oops: 0000 [#1]
last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90 
scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci 
8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc

Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
Stack:
  d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
<0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
<0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
Call Trace:
  [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
  [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
  [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
  [<c10f5db9>] ? nla_parse+0x59/0xc0
  [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
  [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
  [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
  [<c11c9649>] ? genl_rcv+0x19/0x30
  [<c11c7c03>] ? netlink_unicast+0x1b3/0x220
  [<c11c893e>] ? netlink_sendmsg+0x26e/0x290
  [<c11a409e>] ? sock_sendmsg+0xbe/0xf0
  [<c1032780>] ? autoremove_wake_function+0x0/0x50
  [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
  [<c1074933>] ? do_lookup+0x53/0x1b0
  [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
  [<c11acab0>] ? verify_iovec+0x50/0x90
  [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
  [<c1048e50>] ? find_get_page+0x10/0x50
  [<c104a96f>] ? filemap_fault+0x5f/0x370
  [<c1059159>] ? __do_fault+0x319/0x370
  [<c11a55b4>] ? sys_socketcall+0x244/0x290
  [<c101962c>] ? do_page_fault+0x1ec/0x270
  [<c1019440>] ? do_page_fault+0x0/0x270
  [<c1002ae5>] ? syscall_call+0x7/0xb
Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24 
0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7 
43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP 
0068:cfa09bf4
CR2: 0000000000000006
---[ end trace 54f73d6b10ceb87b ]---

Cc: stable@kernel.org
Reported-by: Steve Brown <sbrown@cortland.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath/ath5k/attach.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index ef2dc1d..b32e28c 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -126,6 +126,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
 	ah->ah_ant_mode = AR5K_ANTMODE_DEFAULT;
 	ah->ah_noise_floor = -95;	/* until first NF calibration is run */
 	sc->ani_state.ani_mode = ATH5K_ANI_MODE_AUTO;
+	ah->ah_current_channel = &sc->channels[0];
 
 	/*
 	 * Find the mac version
-- 
1.6.3.3



^ permalink raw reply related

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 17:23 UTC (permalink / raw)
  To: Justin P. Mattock
  Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi, Yinghai Lu
In-Reply-To: <1276666434-11227-5-git-send-email-justinmattock@gmail.com>

On Tue, 15 Jun 2010 22:33:53 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:

> The below patch fixes a warning message when using gcc 4.6.0
>   CC      drivers/pci/setup-bus.o
> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>  
>  Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
> 
> ---
>  drivers/pci/setup-bus.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 19b1113..215590b 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>  	struct pci_bus *parent = bridge->subordinate;
>  	int tried_times = 0;
>  	struct resource_list_x head, *list;
> -	int retval;
>  	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>  				  IORESOURCE_PREFETCH;
>  
> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>  again:
>  	pci_bus_size_bridges(parent);
>  	__pci_bridge_assign_resources(bridge, &head);
> -	retval = pci_reenable_device(bridge);
>  	pci_set_master(bridge);
>  	pci_enable_bridges(parent);
>  

This has the same problem as your earlier bridge_enable patch; you need
to keep the call to pci_reenable_device.  I should have caught this
issue when Yinghai's patch went in: the right way to silence a warning
about not checking a return value isn't to simply assign it to
something, you really should *do* something as well, at least some
debug output would be nice, but ideally handling the error in a sane
way. 

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 17:31 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi, Yinghai Lu
In-Reply-To: <20100618102330.29eccb5b@virtuousgeek.org>

On 06/18/2010 10:23 AM, Jesse Barnes wrote:
> On Tue, 15 Jun 2010 22:33:53 -0700
> "Justin P. Mattock"<justinmattock@gmail.com>  wrote:
>
>> The below patch fixes a warning message when using gcc 4.6.0
>>    CC      drivers/pci/setup-bus.o
>> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>>
>>   Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>>   drivers/pci/setup-bus.c |    2 --
>>   1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 19b1113..215590b 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>   	struct pci_bus *parent = bridge->subordinate;
>>   	int tried_times = 0;
>>   	struct resource_list_x head, *list;
>> -	int retval;
>>   	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>>   				  IORESOURCE_PREFETCH;
>>
>> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>   again:
>>   	pci_bus_size_bridges(parent);
>>   	__pci_bridge_assign_resources(bridge,&head);
>> -	retval = pci_reenable_device(bridge);
>>   	pci_set_master(bridge);
>>   	pci_enable_bridges(parent);
>>
>
> This has the same problem as your earlier bridge_enable patch; you need
> to keep the call to pci_reenable_device.  I should have caught this
> issue when Yinghai's patch went in: the right way to silence a warning
> about not checking a return value isn't to simply assign it to
> something, you really should *do* something as well, at least some
> debug output would be nice, but ideally handling the error in a sane
> way.
>


yeah I was still looking into the scsi patch with adding a printk
then I can look at this as well.

Justin P. Mattock

^ permalink raw reply

* rt61pci AP performance issues
From: David Ellingsworth @ 2010-06-18 18:02 UTC (permalink / raw)
  To: rt2x00 Users List, wireless

I've been trying unsuccessfully for some time to use a rt61pci based
wireless card as an Access Point for my network. With kernel version
2.6.32-4 (Debian version) the AP works but has intermittent problems.
Notably, that version continuously prints the message
"ieee80211_tx_status: headroom too small" to my system log and the
driver simply stops working after a random amount of time. The first
of these errors was fixed some time ago after I reported it, but the
other still remains, even with the latest wireless-testing driver, and
there's no indication as to the cause of the issue. With regards to
this issue, it appears that performance steadily drops until it
becomes unusable. With the latest wireless-testing driver I can
reliably reproduce this issue by trying to transfer a large file from
my server to a client. Any help diagnosing and correcting this issue
would be greatly appreciated.

Regards,

David Ellingsworth

^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 18:38 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi, Yinghai Lu
In-Reply-To: <20100618102330.29eccb5b@virtuousgeek.org>

 From b07231ddb853e9388cea77a82da210e36ab79aad Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 11:32:20 -0700
Subject: [PATCH 2/2] setup-bus_test
  Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>

---
  drivers/pci/setup-bus.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 19b1113..7b57dd0 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -875,6 +875,7 @@ again:
  	pci_bus_size_bridges(parent);
  	__pci_bridge_assign_resources(bridge, &head);
  	retval = pci_reenable_device(bridge);
+	printk(KERN_DEBUG "PCI%d: re-enabling device\n", retval);
  	pci_set_master(bridge);
  	pci_enable_bridges(parent);

-- 
1.7.1.rc1.21.gf3bd6


o.k. I went through this as you had requested to the best of my 
knowledge(bit confused with this, but will try).

let me know if more should be added and/or it's totally wrong
then I'll try again until correct..

Justin P. Mattock

^ permalink raw reply related

* Re: wireless-regdb: FI/CZ updates
From: John W. Linville @ 2010-06-18 18:43 UTC (permalink / raw)
  To: Pekka Pietikainen
  Cc: Luis R. Rodriguez, Michael Green, David Quan, linux-wireless
In-Reply-To: <20100528124258.GA27491@ee.oulu.fi>

On Fri, May 28, 2010 at 03:42:58PM +0300, Pekka Pietikainen wrote:
> On Wed, May 26, 2010 at 11:30:37AM -0700, Luis R. Rodriguez wrote:
> > Pekka, please remove these changes from this patch, you want to make
> > your patches atomic, with only one purpose to help the review process
> > easier. You stashed changes to CZ & FI on one... You also switched
> > from dBm to mW and note how you actually did change the EIRP here for
> > only one for FI. Please provide a separate set of patches for that for
> > FI. If you want to switch to mW for all of the entries for FI first do
> > that, and then on a separate patch make the actual regulatory changes
> > so this is crystal clear for the review process.
> Okie
> 
> Looking at it a bit more probably makes sense to codify the current
> harmonized EU rules, and then just for each country note that they've
> actually implemented it in their local legislation (I checked FI, SE and
> CZ).  Everyone should have, but some are pretty slow at this, or
> have some special national interests...
> 
> The legislation uses mW, so that's the reason I switched them.
> 
> For review (first hit on google for the decision number
> should find the official text), I can do patches once someone
> has verified, that this is what the legalese actually says:
> 
> # EU Commission Decision 2009/381/EC
>        (2400 - 2483.5 @ 40), (N/A, 100mW)
> # 2005/513/EC and 2007/90/EC, 5250 and 5470 can be doubled if TPC is in use
>        (5150 - 5250 @ 40), (N/A, 200mW), NO-OUTDOOR
>        (5250 - 5350 @ 40), (N/A, 100mW), NO-OUTDOOR, DFS
>        (5470 - 5725 @ 40), (N/A, 500mW), DFS

Ping?

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [RFC] wireless-regdb: Add A band in IL
From: John W. Linville @ 2010-06-18 18:42 UTC (permalink / raw)
  To: Emmanuel Grumbach; +Cc: linux-wireless, Michael Green, David Quan
In-Reply-To: <1274856569-13436-1-git-send-email-emmanuel.grumbach@intel.com>

On Wed, May 26, 2010 at 09:49:29AM +0300, Emmanuel Grumbach wrote:
> A band in allowed in IL, according to official document issued by the Ministry
> of Communications: http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf.
> 
> 5150 - 5250 200mW e.i.r.p. OUTDOOR forbidden
> 5250 - 5350 200mW e.i.r.p. OUTDOOR forbidden DFS mandatory
> 
> 40Mhz is allowed in A band for every WiFi-Alliance certified equipment.
> 
> ***************************************************************
> Not to be merged for the moment
> ***************************************************************
> 
> CC: Michael Green <Michael.Green@atheros.com>
> CC: David Quan <David.Quan@atheros.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
>  db.txt |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/db.txt b/db.txt
> index e63a43e..d49c397 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -319,6 +319,8 @@ country IE:
>  
>  country IL:
>  	(2402 - 2482 @ 40), (N/A, 20)
> +	(5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
> +	(5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
>  
>  country IN:
>  	(2402 - 2482 @ 40), (N/A, 20)

Is this issue now settled?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: WLAN Regulatory Domain Germany
From: John W. Linville @ 2010-06-18 18:44 UTC (permalink / raw)
  To: Kurt Garloff; +Cc: Johannes Berg, linux-wireless, Luis R. Rodriguez
In-Reply-To: <20100525151429.GC6342@tpkurt2.garloff.de>

On Tue, May 25, 2010 at 05:14:29PM +0200, Kurt Garloff wrote:

> OK, new suggestion.
> 
> 8<------------------------------------------------------------------------                    
> 
> # Data from "Frequenznutzungsplan" (as published in April 2008), downloaded from
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38448/publicationFile/2659/Frequenznutzungsplan2008_Id17448pdf.pdf
> # For the 5GHz range also see
> # http://www.bundesnetzagentur.de/cae/servlet/contentblob/38216/publicationFile/6579/WLAN5GHzVfg7_2010_28042010pdf.pdf
> # The values have been reduced by a factor of 2 (3db) for non TPC devices
> # (in other words: devices with TPC can use twice the tx power of this table).
> # Note that the docs do not require TPC for 5150--5250; the reduction to
> # 100mW thus is not strictly required -- however the conservative 100mW
> # limit is used here as the non-interference with radar and satellite
> # apps relies on the attenuation by the building walls only in the
> # absence of DFS; the neighbour countries have 100mW limit here as well.
> 
> country DE:
> 	# entries 279004 and 280006
>        (2400 - 2483.5 @ 40), (N/A, 100 mW)
>        # entry 303005
>        (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
>        # entries 304002 and 305002
>        (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
>        # entries 308002, 309001 and 310003
>        (5470 - 5725 @ 40), (N/A, 500 mW), DFS
> 
> 8<------------------------------------------------------------------------

Is this what we want?  Are you going to submit an actual patch?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Yinghai Lu @ 2010-06-18 18:48 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Justin P. Mattock, linux-kernel, linux-wireless, linux-pci,
	linux-scsi
In-Reply-To: <20100618102330.29eccb5b@virtuousgeek.org>

On 06/18/2010 10:23 AM, Jesse Barnes wrote:
> On Tue, 15 Jun 2010 22:33:53 -0700
> "Justin P. Mattock" <justinmattock@gmail.com> wrote:
> 
>> The below patch fixes a warning message when using gcc 4.6.0
>>   CC      drivers/pci/setup-bus.o
>> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>>  
>>  Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>>
>> ---
>>  drivers/pci/setup-bus.c |    2 --
>>  1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 19b1113..215590b 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>  	struct pci_bus *parent = bridge->subordinate;
>>  	int tried_times = 0;
>>  	struct resource_list_x head, *list;
>> -	int retval;
>>  	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>>  				  IORESOURCE_PREFETCH;
>>  
>> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>  again:
>>  	pci_bus_size_bridges(parent);
>>  	__pci_bridge_assign_resources(bridge, &head);
>> -	retval = pci_reenable_device(bridge);
>>  	pci_set_master(bridge);
>>  	pci_enable_bridges(parent);
>>  

I sent following patch several weeks ago, can you put that in pci-next?

Subject: [PATCH] pciehp: Enable bridges at last for multiple try assigning

Found one PCIe Module with several bridges "cold" hotadd doesn't work.

the root cause:
1. BIOS assign small range the parent bridges.
2. First try for hotadd only can make some bridges get resource assigned.
3. Second will update parent bridge res, get right sizes for all child bridges
    and devices, but resource for child bridges are not set to HW register.
    Because first try already enable those bridges, so __pci_bridge_assign_resource
    skip the setting step.

So try to move enabling of child bridges to last and only do that one time

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 drivers/pci/setup-bus.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

Index: linux-2.6/drivers/pci/setup-bus.c
===================================================================
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -866,19 +866,16 @@ void pci_assign_unassigned_bridge_resour
 again:
 	pci_bus_size_bridges(parent);
 	__pci_bridge_assign_resources(bridge, &head);
-	retval = pci_reenable_device(bridge);
-	pci_set_master(bridge);
-	pci_enable_bridges(parent);
 
 	tried_times++;
 
 	if (!head.next)
-		return;
+		goto enable_all;
 
 	if (tried_times >= 2) {
 		/* still fail, don't need to try more */
 		free_failed_list(&head);
-		return;
+		goto enable_all;
 	}
 
 	printk(KERN_DEBUG "PCI: No. %d try to assign unassigned res\n",
@@ -911,5 +908,10 @@ again:
 	free_failed_list(&head);
 
 	goto again;
+
+enable_all:
+	retval = pci_reenable_device(bridge);
+	pci_set_master(bridge);
+	pci_enable_bridges(parent);
 }
 EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);

^ permalink raw reply

* Re: [PATCH 2/2] wireless-regdb: Enable 40MHz operation for some countries.
From: John W. Linville @ 2010-06-18 18:56 UTC (permalink / raw)
  To: Vivek Natarajan; +Cc: linux-wireless
In-Reply-To: <1276768074-4366-3-git-send-email-vnatarajan@atheros.com>

On Thu, Jun 17, 2010 at 03:17:54PM +0530, Vivek Natarajan wrote:
> Enable 40MHz operation for Argentina, Brazil, Colombia, Algeria,
> India, Malaysia, Peru and South Africa.
> 
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>

These too...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [PATCH 1/2] wireless-regdb: Update the regulatory domain for a few countries.
From: John W. Linville @ 2010-06-18 18:56 UTC (permalink / raw)
  To: Vivek Natarajan; +Cc: linux-wireless
In-Reply-To: <1276768074-4366-2-git-send-email-vnatarajan@atheros.com>

On Thu, Jun 17, 2010 at 03:17:53PM +0530, Vivek Natarajan wrote:
> Add Bangladesh(BD) with NULL1_WORLD.
> Add Kenya(KE) with APL1_WORLD.
> Change Honduras(HN) to FCC3_WORLD.
> Change Lebanon(LB) to  APL1_WORLD,
> Change Macedonia(MK) to ETSI1_WORLD.
> Change Pakistan(PK) to APL1_WORLD.
> Change Romania(RO) to ETSI1_WORLD.
> Change Russia(RU) to FCC3_WORLD.
> Change Saudi Arabia(SA) to FCC2_WORLD.
> Change UAE(AE) to ETSI1_WORLD.
> Change Venezuela(VE) to FCC1_WORLD.
> Change Vietnam(VN) to ETSI3_WORLD.
> 
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>

It would be nice to have some reference for these changes...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [PATCH] p54usb: Drop duplicate USBID 0xcde:0x0006
From: John W. Linville @ 2010-06-18 18:57 UTC (permalink / raw)
  To: Ozan Çağlayan; +Cc: linux-kernel, linux-wireless, flamingice
In-Reply-To: <1276771049-2187-1-git-send-email-ozan@pardus.org.tr>

On Thu, Jun 17, 2010 at 01:37:29PM +0300, Ozan Çağlayan wrote:
> Drop the duplicate USB ID 0xcde:0x0006 which is written at two
> different places in p54usb.c
> 
> Signed-off-by: Ozan Çağlayan <ozan@pardus.org.tr>

Someone beat you to it already...

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Compat-wireless release for 2010-06-18 is baked
From: Compat-wireless cronjob account @ 2010-06-18 19:03 UTC (permalink / raw)
  To: linux-wireless, linux-bluetooth

>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
   11542b5..75bb510  master     -> origin/master
   d584ab0..3eaa500  wl         -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
   67eac11..49bc196  history    -> origin/history
 + 8668718...d568ec36 master     -> origin/master  (forced update)
 * [new tag]         next-20100618 -> next-20100618

compat-wireless code metrics

    498472 - Total upstream lines of code being pulled
      1410 - backport code changes
      1177 - backport code additions
       233 - backport code deletions
      5748 - backport from compat module
      7158 - total backport code
    1.4360 - % of code consists of backport work
      1218 - Crap changes not yet posted
      1179 - Crap additions not yet merged
        39 - Crap deletions not yet posted
    0.2443 - % of crap code

Base tree: linux-next.git
Base tree version: next-20100618
compat-wireless release: compat-wireless-2010-06-17-1-g75bb510

^ permalink raw reply

* Re: [PATCHv3] mac80211: Add interface for driver to temporarily disable dynamic ps
From: John W. Linville @ 2010-06-18 19:12 UTC (permalink / raw)
  To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1276753353-30310-1-git-send-email-juuso.oikarinen@nokia.com>

On Thu, Jun 17, 2010 at 08:42:33AM +0300, Juuso Oikarinen wrote:
> This mechanism introduced in this patch applies (at least) for hardware
> designs using a single shared antenna for both WLAN and BT. In these designs,
> the antenna must be toggled between WLAN and BT.
> 
> In those hardware, managing WLAN co-existence with Bluetooth requires WLAN
> full power save whenever there is Bluetooth activity in order for WLAN to be
> able to periodically relinquish the antenna to be used for BT. This is because
> BT can only access the shared antenna when WLAN is idle or asleep.
> 
> Some hardware, for instance the wl1271, are able to indicate to the host
> whenever there is BT traffic. In essence, the hardware will send an indication
> to the host whenever there is, for example, SCO traffic or A2DP traffic, and
> will send another indication when the traffic is over.
> 
> The hardware gets information of Bluetooth traffic via hardware co-existence
> control lines - these lines are used to negotiate the shared antenna
> ownership. The hardware will give the antenna to BT whenever WLAN is sleeping.
> 
> This patch adds the interface to mac80211 to facilitate temporarily disabling
> of dynamic power save as per request of the WLAN driver. This interface will
> immediately force WLAN to full powersave, hence allowing BT coexistence as
> described above.
> 
> In these kind of shared antenna desings, when WLAN powersave is fully disabled,
> Bluetooth will not work simultaneously with WLAN at all. This patch does not
> address that problem. This interface will not change PSM state, so if PSM is
> disabled it will remain so. Solving this problem requires knowledge about BT
> state, and is best done in user-space.
> 
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> v3: separate ieee80211_dyn_ps_enable/ieee80211_dyn_ps_enable functions

  CC [M]  net/mac80211/mlme.o
net/mac80211/mlme.c: In function ‘ieee80211_recalc_ps’:
net/mac80211/mlme.c:598: error: ‘struct ieee80211_conf’ has no member named ‘dynamic_ps_forced_timeout’
make[1]: *** [net/mac80211/mlme.o] Error 1

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: James Bottomley @ 2010-06-18 19:37 UTC (permalink / raw)
  To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <4C1A4A69.7060801@gmail.com>

On Thu, 2010-06-17 at 09:16 -0700, Justin P. Mattock wrote:
> > Erm, well, as I said, error code and the fact that the thread failed to
> > start, so more
> >
> > printk(KERN_WARNING "scsi%d: error handler thread failed to spawn, error
> > = %d\n", host->host_no, PTR_ERR(shost->ehandler));
> >
> > James
> >
> 
> o.k. I looked at this a bit more and finally got the thing to build 
> through without a warning, using what you had sent, but keep in mind I 
> still need to add error  = %d\n", host->host_no, to the printk
> 
> here's what I have so far:
> 
> 
>   drivers/scsi/hosts.c |    3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 6660fa9..c1ff708 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -419,8 +419,9 @@ struct Scsi_Host *scsi_host_alloc(struct 
> scsi_host_template *sht, int privsize)
> 
>   	shost->ehandler = kthread_run(scsi_error_handler, shost,
>   			"scsi_eh_%d", shost->host_no);
> +	rval = PTR_ERR(shost->ehandler);
>   	if (IS_ERR(shost->ehandler)) {
> -		rval = PTR_ERR(shost->ehandler);
> +		printk(KERN_WARNING "scsi%d: error handler thread failed to spawn\n", 
> rval);

So this isn't really an improvement over the suggestion.  What you
wanted was shost->host_no, as you deduced, but the %d becomes %ld to
quiet the type warning.

James





^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 19:49 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Justin P. Mattock, linux-kernel, linux-wireless, linux-pci,
	linux-scsi
In-Reply-To: <4C1BBF7D.8090904@kernel.org>

On Fri, 18 Jun 2010 11:48:29 -0700
Yinghai Lu <yinghai@kernel.org> wrote:

> On 06/18/2010 10:23 AM, Jesse Barnes wrote:
> > On Tue, 15 Jun 2010 22:33:53 -0700
> > "Justin P. Mattock" <justinmattock@gmail.com> wrote:
> > 
> >> The below patch fixes a warning message when using gcc 4.6.0
> >>   CC      drivers/pci/setup-bus.o
> >> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
> >> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
> >>  
> >>  Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
> >>
> >> ---
> >>  drivers/pci/setup-bus.c |    2 --
> >>  1 files changed, 0 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> >> index 19b1113..215590b 100644
> >> --- a/drivers/pci/setup-bus.c
> >> +++ b/drivers/pci/setup-bus.c
> >> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> >>  	struct pci_bus *parent = bridge->subordinate;
> >>  	int tried_times = 0;
> >>  	struct resource_list_x head, *list;
> >> -	int retval;
> >>  	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> >>  				  IORESOURCE_PREFETCH;
> >>  
> >> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
> >>  again:
> >>  	pci_bus_size_bridges(parent);
> >>  	__pci_bridge_assign_resources(bridge, &head);
> >> -	retval = pci_reenable_device(bridge);
> >>  	pci_set_master(bridge);
> >>  	pci_enable_bridges(parent);
> >>  
> 
> I sent following patch several weeks ago, can you put that in pci-next?
> 
> Subject: [PATCH] pciehp: Enable bridges at last for multiple try assigning
> 
> Found one PCIe Module with several bridges "cold" hotadd doesn't work.
> 
> the root cause:
> 1. BIOS assign small range the parent bridges.
> 2. First try for hotadd only can make some bridges get resource assigned.
> 3. Second will update parent bridge res, get right sizes for all child bridges
>     and devices, but resource for child bridges are not set to HW register.
>     Because first try already enable those bridges, so __pci_bridge_assign_resource
>     skip the setting step.
> 
> So try to move enabling of child bridges to last and only do that one time
> 
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>

Yeah I had a hard time following the changelog, but just looked it
over.  Looks safe, but Justin will still need to check the return value
on pci_reenable_device.

Justin, we don't want a message on every reenable, just on ones that
fail.  So can you protect your printk with if (retval) instead?  You'll
need to refresh it based on my linux-next branch in a few minutes, as
I'm pushing Yinghai's patch now.

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply

* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-18 19:55 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276889827.2850.331.camel@mulgrave.site>

On 06/18/2010 12:37 PM, James Bottomley wrote:
> On Thu, 2010-06-17 at 09:16 -0700, Justin P. Mattock wrote:
>>> Erm, well, as I said, error code and the fact that the thread failed to
>>> start, so more
>>>
>>> printk(KERN_WARNING "scsi%d: error handler thread failed to spawn, error
>>> = %d\n", host->host_no, PTR_ERR(shost->ehandler));
>>>
>>> James
>>>
>>
>> o.k. I looked at this a bit more and finally got the thing to build
>> through without a warning, using what you had sent, but keep in mind I
>> still need to add error  = %d\n", host->host_no, to the printk
>>
>> here's what I have so far:
>>
>>
>>    drivers/scsi/hosts.c |    3 ++-
>>    1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
>> index 6660fa9..c1ff708 100644
>> --- a/drivers/scsi/hosts.c
>> +++ b/drivers/scsi/hosts.c
>> @@ -419,8 +419,9 @@ struct Scsi_Host *scsi_host_alloc(struct
>> scsi_host_template *sht, int privsize)
>>
>>    	shost->ehandler = kthread_run(scsi_error_handler, shost,
>>    			"scsi_eh_%d", shost->host_no);
>> +	rval = PTR_ERR(shost->ehandler);
>>    	if (IS_ERR(shost->ehandler)) {
>> -		rval = PTR_ERR(shost->ehandler);
>> +		printk(KERN_WARNING "scsi%d: error handler thread failed to spawn\n",
>> rval);
>
> So this isn't really an improvement over the suggestion.  What you
> wanted was shost->host_no, as you deduced, but the %d becomes %ld to
> quiet the type warning.
>
> James

ahh.. was reading the manual but couldn't make sense of the % then 
letter to use.

let me add these in, then if good I'll send it out for review etc..

Justin P. Mattock

^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 19:59 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100618124956.40c869a0@virtuousgeek.org>

On 06/18/2010 12:49 PM, Jesse Barnes wrote:
> On Fri, 18 Jun 2010 11:48:29 -0700
> Yinghai Lu<yinghai@kernel.org>  wrote:
>
>> On 06/18/2010 10:23 AM, Jesse Barnes wrote:
>>> On Tue, 15 Jun 2010 22:33:53 -0700
>>> "Justin P. Mattock"<justinmattock@gmail.com>  wrote:
>>>
>>>> The below patch fixes a warning message when using gcc 4.6.0
>>>>    CC      drivers/pci/setup-bus.o
>>>> drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
>>>> drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
>>>>
>>>>   Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>>>
>>>> ---
>>>>   drivers/pci/setup-bus.c |    2 --
>>>>   1 files changed, 0 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>>>> index 19b1113..215590b 100644
>>>> --- a/drivers/pci/setup-bus.c
>>>> +++ b/drivers/pci/setup-bus.c
>>>> @@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>>>   	struct pci_bus *parent = bridge->subordinate;
>>>>   	int tried_times = 0;
>>>>   	struct resource_list_x head, *list;
>>>> -	int retval;
>>>>   	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>>>>   				  IORESOURCE_PREFETCH;
>>>>
>>>> @@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
>>>>   again:
>>>>   	pci_bus_size_bridges(parent);
>>>>   	__pci_bridge_assign_resources(bridge,&head);
>>>> -	retval = pci_reenable_device(bridge);
>>>>   	pci_set_master(bridge);
>>>>   	pci_enable_bridges(parent);
>>>>
>>
>> I sent following patch several weeks ago, can you put that in pci-next?
>>
>> Subject: [PATCH] pciehp: Enable bridges at last for multiple try assigning
>>
>> Found one PCIe Module with several bridges "cold" hotadd doesn't work.
>>
>> the root cause:
>> 1. BIOS assign small range the parent bridges.
>> 2. First try for hotadd only can make some bridges get resource assigned.
>> 3. Second will update parent bridge res, get right sizes for all child bridges
>>      and devices, but resource for child bridges are not set to HW register.
>>      Because first try already enable those bridges, so __pci_bridge_assign_resource
>>      skip the setting step.
>>
>> So try to move enabling of child bridges to last and only do that one time
>>
>> Signed-off-by: Yinghai Lu<yinghai@kernel.org>
>
> Yeah I had a hard time following the changelog, but just looked it
> over.  Looks safe, but Justin will still need to check the return value
> on pci_reenable_device.
>
> Justin, we don't want a message on every reenable, just on ones that
> fail.  So can you protect your printk with if (retval) instead?  You'll
> need to refresh it based on my linux-next branch in a few minutes, as
> I'm pushing Yinghai's patch now.
>


just added this in(as a test), and the retval warning still shows up.
with the last post I just added a printk was that legit, and if so what 
else might be added to it to make it complete and proper?

Justin P. Mattock

^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Jesse Barnes @ 2010-06-18 20:05 UTC (permalink / raw)
  To: Justin P. Mattock
  Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <4C1BD024.1030707@gmail.com>

On Fri, 18 Jun 2010 12:59:32 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:
> just added this in(as a test), and the retval warning still shows up.
> with the last post I just added a printk was that legit, and if so what 
> else might be added to it to make it complete and proper?

What's the full warning?  Seems like printing the value should have
been enough to shut up gcc...

-- 
Jesse Barnes, Intel Open Source Technology Center

^ permalink raw reply

* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-18 20:17 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276889827.2850.331.camel@mulgrave.site>

Thanks for the help, and info on this..I just tested and sent out the 
patch let me know if it's legit or not..

Justin P. Mattock

^ permalink raw reply

* Re: [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-18 20:26 UTC (permalink / raw)
  To: Jesse Barnes
  Cc: Yinghai Lu, linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100618130538.0fc562ee@virtuousgeek.org>

On 06/18/2010 01:05 PM, Jesse Barnes wrote:
> On Fri, 18 Jun 2010 12:59:32 -0700
> "Justin P. Mattock"<justinmattock@gmail.com>  wrote:
>> just added this in(as a test), and the retval warning still shows up.
>> with the last post I just added a printk was that legit, and if so what
>> else might be added to it to make it complete and proper?
>
> What's the full warning?  Seems like printing the value should have
> been enough to shut up gcc...
>

this is the warning messg after applying yinghai's patch:

   CC      drivers/pci/setup-bus.o
drivers/pci/setup-bus.c: In function 
'pci_assign_unassigned_bridge_resources':
drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used


if I add a printk then gcc is content.. patch below, but not the best at 
creating printk's(the whole % thing messes me up) but here goes:

 From 48e15b87072c6b4286d943c55bfe2ae26d358795 Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 13:23:27 -0700
Subject: [PATCH 4/4] bus.c_add_print
  Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>

---
  drivers/pci/setup-bus.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 66cb8f4..806b766 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -919,6 +919,7 @@ again:

  enable_all:
  	retval = pci_reenable_device(bridge);
+	printk(KERN_DEBUG "PCI%d: re-enabling device\n", retval);
  	pci_set_master(bridge);
  	pci_enable_bridges(parent);
  }
-- 
1.7.1.rc1.21.gf3bd6

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox