* pull request: wireless-2.6 2010-06-16
From: John W. Linville @ 2010-06-16 18:28 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another passel of of fixes intended for 2.6.35. Included are
some build warning fixes, a PCI identifier, a fix for premature
IRQs during hostap initialization, a fix for a warning caused by
failing to cancel a scan watchdog in iwlwifi, a fix for a null
pointer dereference in iwlwifi, and a fix for a race condition in
the same driver. Also included is the MAINTAINERS change for the
orphaning of the older Intel wireless drivers. All but the last few
warning fixes have spent some time in linux-next already.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit fed396a585d8e1870b326f2e8e1888a72957abb8:
Herbert Xu (1):
bridge: Fix OOM crash in deliver_clone
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Christoph Fritz (1):
mac80211: fix warn, enum may be used uninitialized
Joerg Albert (1):
p54pci: add Symbol AP-300 minipci adapters pciid
John W. Linville (1):
iwlwifi: cancel scan watchdog in iwl_bg_abort_scan
Justin P. Mattock (2):
wireless:hostap_main.c warning: variable 'iface' set but not used
wireless:hostap_ap.c Fix warning: variable 'fc' set but not used
Prarit Bhargava (1):
libertas_tf: Fix warning in lbtf_rx for stats struct
Reinette Chatre (1):
iwlwifi: serialize station management actions
Shanyu Zhao (1):
iwlagn: verify flow id in compressed BA packet
Tim Gardner (1):
hostap: Protect against initialization interrupt
Zhu Yi (1):
wireless: orphan ipw2x00 drivers
MAINTAINERS | 10 ++--------
drivers/net/wireless/hostap/hostap_ap.c | 3 +--
drivers/net/wireless/hostap/hostap_cs.c | 15 +++++++++++++--
drivers/net/wireless/hostap/hostap_hw.c | 13 +++++++++++++
drivers/net/wireless/hostap/hostap_main.c | 2 --
drivers/net/wireless/hostap/hostap_wlan.h | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 5 +++++
drivers/net/wireless/iwlwifi/iwl-agn.c | 8 ++++++--
drivers/net/wireless/iwlwifi/iwl-scan.c | 1 +
drivers/net/wireless/iwlwifi/iwl-sta.c | 4 ++++
drivers/net/wireless/iwlwifi/iwl3945-base.c | 9 +++++++--
drivers/net/wireless/libertas_tf/main.c | 2 +-
drivers/net/wireless/p54/p54pci.c | 2 ++
net/mac80211/work.c | 2 +-
14 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 83be538..837a754 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2966,20 +2966,14 @@ F: drivers/net/ixgb/
F: drivers/net/ixgbe/
INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
-M: Reinette Chatre <reinette.chatre@intel.com>
-M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-W: http://ipw2100.sourceforge.net
-S: Odd Fixes
+S: Orphan
F: Documentation/networking/README.ipw2100
F: drivers/net/wireless/ipw2x00/ipw2100.*
INTEL PRO/WIRELESS 2915ABG NETWORK CONNECTION SUPPORT
-M: Reinette Chatre <reinette.chatre@intel.com>
-M: Intel Linux Wireless <ilw@linux.intel.com>
L: linux-wireless@vger.kernel.org
-W: http://ipw2200.sourceforge.net
-S: Odd Fixes
+S: Orphan
F: Documentation/networking/README.ipw2200
F: drivers/net/wireless/ipw2x00/ipw2200.*
diff --git a/drivers/net/wireless/hostap/hostap_ap.c b/drivers/net/wireless/hostap/hostap_ap.c
index 231dbd7..9cadaa2 100644
--- a/drivers/net/wireless/hostap/hostap_ap.c
+++ b/drivers/net/wireless/hostap/hostap_ap.c
@@ -688,7 +688,7 @@ static void hostap_ap_tx_cb_assoc(struct sk_buff *skb, int ok, void *data)
struct ap_data *ap = data;
struct net_device *dev = ap->local->dev;
struct ieee80211_hdr *hdr;
- u16 fc, status;
+ u16 status;
__le16 *pos;
struct sta_info *sta = NULL;
char *txt = NULL;
@@ -699,7 +699,6 @@ static void hostap_ap_tx_cb_assoc(struct sk_buff *skb, int ok, void *data)
}
hdr = (struct ieee80211_hdr *) skb->data;
- fc = le16_to_cpu(hdr->frame_control);
if ((!ieee80211_is_assoc_resp(hdr->frame_control) &&
!ieee80211_is_reassoc_resp(hdr->frame_control)) ||
skb->len < IEEE80211_MGMT_HDR_LEN + 4) {
diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
index db72461..29b31a6 100644
--- a/drivers/net/wireless/hostap/hostap_cs.c
+++ b/drivers/net/wireless/hostap/hostap_cs.c
@@ -594,6 +594,7 @@ static int prism2_config(struct pcmcia_device *link)
local_info_t *local;
int ret = 1;
struct hostap_cs_priv *hw_priv;
+ unsigned long flags;
PDEBUG(DEBUG_FLOW, "prism2_config()\n");
@@ -625,9 +626,15 @@ static int prism2_config(struct pcmcia_device *link)
local->hw_priv = hw_priv;
hw_priv->link = link;
+ /*
+ * Make sure the IRQ handler cannot proceed until at least
+ * dev->base_addr is initialized.
+ */
+ spin_lock_irqsave(&local->irq_init_lock, flags);
+
ret = pcmcia_request_irq(link, prism2_interrupt);
if (ret)
- goto failed;
+ goto failed_unlock;
/*
* This actually configures the PCMCIA socket -- setting up
@@ -636,11 +643,13 @@ static int prism2_config(struct pcmcia_device *link)
*/
ret = pcmcia_request_configuration(link, &link->conf);
if (ret)
- goto failed;
+ goto failed_unlock;
dev->irq = link->irq;
dev->base_addr = link->io.BasePort1;
+ spin_unlock_irqrestore(&local->irq_init_lock, flags);
+
/* Finally, report what we've done */
printk(KERN_INFO "%s: index 0x%02x: ",
dev_info, link->conf.ConfigIndex);
@@ -667,6 +676,8 @@ static int prism2_config(struct pcmcia_device *link)
return ret;
+ failed_unlock:
+ spin_unlock_irqrestore(&local->irq_init_lock, flags);
failed:
kfree(hw_priv);
prism2_release((u_long)link);
diff --git a/drivers/net/wireless/hostap/hostap_hw.c b/drivers/net/wireless/hostap/hostap_hw.c
index ff9b5c8..2f999fc 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -2621,6 +2621,18 @@ static irqreturn_t prism2_interrupt(int irq, void *dev_id)
iface = netdev_priv(dev);
local = iface->local;
+ /* Detect early interrupt before driver is fully configued */
+ spin_lock(&local->irq_init_lock);
+ if (!dev->base_addr) {
+ if (net_ratelimit()) {
+ printk(KERN_DEBUG "%s: Interrupt, but dev not configured\n",
+ dev->name);
+ }
+ spin_unlock(&local->irq_init_lock);
+ return IRQ_HANDLED;
+ }
+ spin_unlock(&local->irq_init_lock);
+
prism2_io_debug_add(dev, PRISM2_IO_DEBUG_CMD_INTERRUPT, 0, 0);
if (local->func->card_present && !local->func->card_present(local)) {
@@ -3138,6 +3150,7 @@ prism2_init_local_data(struct prism2_helper_functions *funcs, int card_idx,
spin_lock_init(&local->cmdlock);
spin_lock_init(&local->baplock);
spin_lock_init(&local->lock);
+ spin_lock_init(&local->irq_init_lock);
mutex_init(&local->rid_bap_mtx);
if (card_idx < 0 || card_idx >= MAX_PARM_DEVICES)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index eb57d1e..eaee84b 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -741,9 +741,7 @@ void hostap_set_multicast_list_queue(struct work_struct *work)
local_info_t *local =
container_of(work, local_info_t, set_multicast_list_queue);
struct net_device *dev = local->dev;
- struct hostap_interface *iface;
- iface = netdev_priv(dev);
if (hostap_set_word(dev, HFA384X_RID_PROMISCUOUSMODE,
local->is_promisc)) {
printk(KERN_INFO "%s: %sabling promiscuous mode failed\n",
diff --git a/drivers/net/wireless/hostap/hostap_wlan.h b/drivers/net/wireless/hostap/hostap_wlan.h
index 3d23891..1ba33be 100644
--- a/drivers/net/wireless/hostap/hostap_wlan.h
+++ b/drivers/net/wireless/hostap/hostap_wlan.h
@@ -654,7 +654,7 @@ struct local_info {
rwlock_t iface_lock; /* hostap_interfaces read lock; use write lock
* when removing entries from the list.
* TX and RX paths can use read lock. */
- spinlock_t cmdlock, baplock, lock;
+ spinlock_t cmdlock, baplock, lock, irq_init_lock;
struct mutex rid_bap_mtx;
u16 infofid; /* MAC buffer id for info frame */
/* txfid, intransmitfid, next_txtid, and next_alloc are protected by
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
index a732f10..7d614c4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c
@@ -1299,6 +1299,11 @@ void iwlagn_rx_reply_compressed_ba(struct iwl_priv *priv,
sta_id = ba_resp->sta_id;
tid = ba_resp->tid;
agg = &priv->stations[sta_id].tid[tid].agg;
+ if (unlikely(agg->txq_id != scd_flow)) {
+ IWL_ERR(priv, "BA scd_flow %d does not match txq_id %d\n",
+ scd_flow, agg->txq_id);
+ return;
+ }
/* Find index just before block-ack window */
index = iwl_queue_dec_wrap(ba_resp_scd_ssn & 0xff, txq->q.n_bd);
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 7726e67..24aff65 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -3391,10 +3391,12 @@ static int iwlagn_mac_sta_add(struct ieee80211_hw *hw,
int ret;
u8 sta_id;
- sta_priv->common.sta_id = IWL_INVALID_STATION;
-
IWL_DEBUG_INFO(priv, "received request to add station %pM\n",
sta->addr);
+ mutex_lock(&priv->mutex);
+ IWL_DEBUG_INFO(priv, "proceeding to add station %pM\n",
+ sta->addr);
+ sta_priv->common.sta_id = IWL_INVALID_STATION;
atomic_set(&sta_priv->pending_frames, 0);
if (vif->type == NL80211_IFTYPE_AP)
@@ -3406,6 +3408,7 @@ static int iwlagn_mac_sta_add(struct ieee80211_hw *hw,
IWL_ERR(priv, "Unable to add station %pM (%d)\n",
sta->addr, ret);
/* Should we return success if return code is EEXIST ? */
+ mutex_unlock(&priv->mutex);
return ret;
}
@@ -3415,6 +3418,7 @@ static int iwlagn_mac_sta_add(struct ieee80211_hw *hw,
IWL_DEBUG_INFO(priv, "Initializing rate scaling for station %pM\n",
sta->addr);
iwl_rs_rate_init(priv, sta, sta_id);
+ mutex_unlock(&priv->mutex);
return 0;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index 5d3f51f..386c5f9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -491,6 +491,7 @@ void iwl_bg_abort_scan(struct work_struct *work)
mutex_lock(&priv->mutex);
+ cancel_delayed_work_sync(&priv->scan_check);
set_bit(STATUS_SCAN_ABORTING, &priv->status);
iwl_send_scan_abort(priv);
diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.c b/drivers/net/wireless/iwlwifi/iwl-sta.c
index 83a2636..c27c13f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-sta.c
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
@@ -1373,10 +1373,14 @@ int iwl_mac_sta_remove(struct ieee80211_hw *hw,
IWL_DEBUG_INFO(priv, "received request to remove station %pM\n",
sta->addr);
+ mutex_lock(&priv->mutex);
+ IWL_DEBUG_INFO(priv, "proceeding to remove station %pM\n",
+ sta->addr);
ret = iwl_remove_station(priv, sta_common->sta_id, sta->addr);
if (ret)
IWL_ERR(priv, "Error removing station %pM\n",
sta->addr);
+ mutex_unlock(&priv->mutex);
return ret;
}
EXPORT_SYMBOL(iwl_mac_sta_remove);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 6c353ca..a27872d 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -3437,10 +3437,13 @@ static int iwl3945_mac_sta_add(struct ieee80211_hw *hw,
bool is_ap = vif->type == NL80211_IFTYPE_STATION;
u8 sta_id;
- sta_priv->common.sta_id = IWL_INVALID_STATION;
-
IWL_DEBUG_INFO(priv, "received request to add station %pM\n",
sta->addr);
+ mutex_lock(&priv->mutex);
+ IWL_DEBUG_INFO(priv, "proceeding to add station %pM\n",
+ sta->addr);
+ sta_priv->common.sta_id = IWL_INVALID_STATION;
+
ret = iwl_add_station_common(priv, sta->addr, is_ap, &sta->ht_cap,
&sta_id);
@@ -3448,6 +3451,7 @@ static int iwl3945_mac_sta_add(struct ieee80211_hw *hw,
IWL_ERR(priv, "Unable to add station %pM (%d)\n",
sta->addr, ret);
/* Should we return success if return code is EEXIST ? */
+ mutex_unlock(&priv->mutex);
return ret;
}
@@ -3457,6 +3461,7 @@ static int iwl3945_mac_sta_add(struct ieee80211_hw *hw,
IWL_DEBUG_INFO(priv, "Initializing rate scaling for station %pM\n",
sta->addr);
iwl3945_rs_rate_init(priv, sta, sta_id);
+ mutex_unlock(&priv->mutex);
return 0;
}
diff --git a/drivers/net/wireless/libertas_tf/main.c b/drivers/net/wireless/libertas_tf/main.c
index 6a04c21..817fffc 100644
--- a/drivers/net/wireless/libertas_tf/main.c
+++ b/drivers/net/wireless/libertas_tf/main.c
@@ -549,7 +549,7 @@ int lbtf_rx(struct lbtf_private *priv, struct sk_buff *skb)
prxpd = (struct rxpd *) skb->data;
- stats.flag = 0;
+ memset(&stats, 0, sizeof(stats));
if (!(prxpd->status & cpu_to_le16(MRVDRV_RXPD_STATUS_OK)))
stats.flag |= RX_FLAG_FAILED_FCS_CRC;
stats.freq = priv->cur_freq;
diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
index 07c4528..a5ea89c 100644
--- a/drivers/net/wireless/p54/p54pci.c
+++ b/drivers/net/wireless/p54/p54pci.c
@@ -41,6 +41,8 @@ static DEFINE_PCI_DEVICE_TABLE(p54p_table) = {
{ PCI_DEVICE(0x1260, 0x3877) },
/* Intersil PRISM Javelin/Xbow Wireless LAN adapter */
{ PCI_DEVICE(0x1260, 0x3886) },
+ /* Intersil PRISM Xbow Wireless LAN adapter (Symbol AP-300) */
+ { PCI_DEVICE(0x1260, 0xffff) },
{ },
};
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index be3d4a6..b025dc7 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -715,7 +715,7 @@ static void ieee80211_work_rx_queued_mgmt(struct ieee80211_local *local,
struct ieee80211_rx_status *rx_status;
struct ieee80211_mgmt *mgmt;
struct ieee80211_work *wk;
- enum work_action rma;
+ enum work_action rma = WORK_ACT_NONE;
u16 fc;
rx_status = (struct ieee80211_rx_status *) skb->cb;
--
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 related
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Luis R. Rodriguez @ 2010-06-16 18:16 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Luis Rodriguez, Kristoffer Ericson, stable@kernel.org,
greg@kroah.com, linux-wireless@vger.kernel.org, Peter Stuge,
John W. Linville
In-Reply-To: <4C1914C1.602@gmail.com>
On Wed, Jun 16, 2010 at 11:15:29AM -0700, Justin P. Mattock wrote:
> On 06/16/2010 10:53 AM, Luis R. Rodriguez wrote:
> > On Wed, Jun 16, 2010 at 09:01:36AM -0700, Justin P. Mattock wrote:
> >> On 06/16/2010 08:49 AM, Luis R. Rodriguez wrote:
> >>> On Wed, Jun 16, 2010 at 6:33 AM, Justin P. Mattock
> >>> <justinmattock@gmail.com> wrote:
> >>>> On 06/16/2010 01:12 AM, Kristoffer Ericson wrote:
> >>>>>
> >>>>> On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
> >>>>>>
> >>>>>> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
> >>>>>>
> >>>>>> The newer single chip hardware family of chipsets have not been
> >>>>>> experiencing issues with power saving set by default with recent
> >>>>>> fixes merged (even into stable). The remaining issues are only
> >>>>>> reported with AR5416 and since enabling PS by default can increase
> >>>>>> power savings considerably best to take advantage of that feature
> >>>>>> as this has been tested properly.
> >>>>>
> >>>>> I havent had any issues lately. But that said Ive moved on to
> >>>>> 2.6.33, 2.6.34 which seems to work fine. Believe you set
> >>>>> to disabled by default on those?
> >>>>>
> >>>>> /Kristoffer
> >>>>>
> >>>>
> >>>> just tried to add this patch to the latest HEAD, but realized
> >>>> ath_set_hw_capab is missing(or I cant seem to grep it)
> >>>> if you have a patch for the latest tree let me know I can see if I'm hitting
> >>>> anything like before.
> >>>
> >>> The patch would already be merged since 2.6.33.y, this patch is a
> >>> backport for 2.6.32.y. I just hadn't had time to backport it yet,
> >>> until today.
> >>>
> >>> Luis
> >>>
> >>
> >> so its already in there then..
> >
> > Right
> >
> >> if that's the case then the system runs
> >> good with powersave on then..
> >
> > Did you read the patch by chance? It only enables power save for
> > non-AR5416 hardware. What do you have?
> >
> > Luis
> >
>
> mine is the AR5008
Ok I should say, all AR5008 and AR9001 family chipsets have
power save disabled still. Only AR9002 and up have it enabled
now. The patch was doing the same for 2.6.32.
Luis
^ permalink raw reply
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Justin P. Mattock @ 2010-06-16 18:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Kristoffer Ericson, stable@kernel.org,
greg@kroah.com, linux-wireless@vger.kernel.org, Peter Stuge,
John W. Linville
In-Reply-To: <20100616175318.GA26198@tux>
On 06/16/2010 10:53 AM, Luis R. Rodriguez wrote:
> On Wed, Jun 16, 2010 at 09:01:36AM -0700, Justin P. Mattock wrote:
>> On 06/16/2010 08:49 AM, Luis R. Rodriguez wrote:
>>> On Wed, Jun 16, 2010 at 6:33 AM, Justin P. Mattock
>>> <justinmattock@gmail.com> wrote:
>>>> On 06/16/2010 01:12 AM, Kristoffer Ericson wrote:
>>>>>
>>>>> On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
>>>>>>
>>>>>> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>>>>>>
>>>>>> The newer single chip hardware family of chipsets have not been
>>>>>> experiencing issues with power saving set by default with recent
>>>>>> fixes merged (even into stable). The remaining issues are only
>>>>>> reported with AR5416 and since enabling PS by default can increase
>>>>>> power savings considerably best to take advantage of that feature
>>>>>> as this has been tested properly.
>>>>>
>>>>> I havent had any issues lately. But that said Ive moved on to
>>>>> 2.6.33, 2.6.34 which seems to work fine. Believe you set
>>>>> to disabled by default on those?
>>>>>
>>>>> /Kristoffer
>>>>>
>>>>
>>>> just tried to add this patch to the latest HEAD, but realized
>>>> ath_set_hw_capab is missing(or I cant seem to grep it)
>>>> if you have a patch for the latest tree let me know I can see if I'm hitting
>>>> anything like before.
>>>
>>> The patch would already be merged since 2.6.33.y, this patch is a
>>> backport for 2.6.32.y. I just hadn't had time to backport it yet,
>>> until today.
>>>
>>> Luis
>>>
>>
>> so its already in there then..
>
> Right
>
>> if that's the case then the system runs
>> good with powersave on then..
>
> Did you read the patch by chance? It only enables power save for
> non-AR5416 hardware. What do you have?
>
> Luis
>
mine is the AR5008
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-16 18:14 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276709590.2847.176.camel@mulgrave.site>
On 06/16/2010 10:33 AM, James Bottomley wrote:
> On Wed, 2010-06-16 at 09:00 -0700, Justin P. Mattock wrote:
>> On 06/16/2010 08:34 AM, James Bottomley wrote:
>>> On Tue, 2010-06-15 at 22:33 -0700, Justin P. Mattock wrote:
>>>> The below patch fixes a warning message generated by gcc 4.6.0
>>>> CC drivers/scsi/hosts.o
>>>> drivers/scsi/hosts.c: In function 'scsi_host_alloc':
>>>> drivers/scsi/hosts.c:328:6: warning: variable 'rval' set but not used
>>>>
>>>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>>>
>>>> ---
>>>> drivers/scsi/hosts.c | 2 --
>>>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
>>>> index 6660fa9..00fd6a4 100644
>>>> --- a/drivers/scsi/hosts.c
>>>> +++ b/drivers/scsi/hosts.c
>>>> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
>>>> {
>>>> struct Scsi_Host *shost;
>>>> gfp_t gfp_mask = GFP_KERNEL;
>>>> - int rval;
>>>>
>>>> if (sht->unchecked_isa_dma&& privsize)
>>>> gfp_mask |= __GFP_DMA;
>>>> @@ -420,7 +419,6 @@ 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);
>>>> if (IS_ERR(shost->ehandler)) {
>>>> - rval = PTR_ERR(shost->ehandler);
>>>> goto fail_kfree;
>>>> }
>>>
>>> For future reference, this is less stylistically acceptable C: you've
>>> reduced the if clause to a single statement, so the braces need
>>> removing.
>>>
>>> However, I don't think we should be ignoring the fact that the eh thread
>>> failed to spawn, so I think some type of printed warning (giving the
>>> error code) would be a much more appropriate replacement.
>>>
>>> James
>>>
>>>
>>>
>>
>>
>> o.k. I'll give a try at that.. as a test I did this(below) seemed to
>> compile clean, but not sure if this is what you're asking for though:
>>
>>
>> From 8a4d6e793e0f92d180a6f48c53bbf00d2751ad01 Mon Sep 17 00:00:00 2001
>> From: Justin P. Mattock<justinmattock@gmail.com>
>> Date: Wed, 16 Jun 2010 08:58:13 -0700
>> Subject: [PATCH] test
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/scsi/hosts.c | 3 +--
>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
>> index 6660fa9..8d98a46 100644
>> --- a/drivers/scsi/hosts.c
>> +++ b/drivers/scsi/hosts.c
>> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct
>> scsi_host_template *sht, int privsize)
>> {
>> struct Scsi_Host *shost;
>> gfp_t gfp_mask = GFP_KERNEL;
>> - int rval;
>>
>> if (sht->unchecked_isa_dma&& privsize)
>> gfp_mask |= __GFP_DMA;
>> @@ -420,7 +419,7 @@ 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);
>> if (IS_ERR(shost->ehandler)) {
>> - rval = PTR_ERR(shost->ehandler);
>> + printk(KERN_WARNING "test.....\n")
>
> 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
>
>
>
>
yeah I figured the printk needed more. I was more concerned with making
sure this is what you are asking for(which looks like it is).
So I added your printk but ended up getting an undeclared error:
CC drivers/scsi/hosts.o
drivers/scsi/hosts.c: In function 'scsi_host_alloc':
drivers/scsi/hosts.c:422:85: error: 'host' undeclared (first use in this
function)
drivers/scsi/hosts.c:422:85: note: each undeclared identifier is
reported only once for each function it appears in
make[2]: *** [drivers/scsi/hosts.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2
I do see a
shost->host_no
but using this seems to not satisfy the compiler:
drivers/scsi/hosts.c: In function 'scsi_host_alloc':
drivers/scsi/hosts.c:422:3: warning: format '%d' expects type 'int', but
argument 3 has type 'long int'
I guess it's safe to say my newbieness is getting my a** kicked with
code(all part of the learning experience..)
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Luis R. Rodriguez @ 2010-06-16 17:53 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Luis Rodriguez, Kristoffer Ericson, stable@kernel.org,
greg@kroah.com, linux-wireless@vger.kernel.org, Peter Stuge,
John W. Linville
In-Reply-To: <4C18F560.1010408@gmail.com>
On Wed, Jun 16, 2010 at 09:01:36AM -0700, Justin P. Mattock wrote:
> On 06/16/2010 08:49 AM, Luis R. Rodriguez wrote:
> > On Wed, Jun 16, 2010 at 6:33 AM, Justin P. Mattock
> > <justinmattock@gmail.com> wrote:
> >> On 06/16/2010 01:12 AM, Kristoffer Ericson wrote:
> >>>
> >>> On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
> >>>>
> >>>> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
> >>>>
> >>>> The newer single chip hardware family of chipsets have not been
> >>>> experiencing issues with power saving set by default with recent
> >>>> fixes merged (even into stable). The remaining issues are only
> >>>> reported with AR5416 and since enabling PS by default can increase
> >>>> power savings considerably best to take advantage of that feature
> >>>> as this has been tested properly.
> >>>
> >>> I havent had any issues lately. But that said Ive moved on to
> >>> 2.6.33, 2.6.34 which seems to work fine. Believe you set
> >>> to disabled by default on those?
> >>>
> >>> /Kristoffer
> >>>
> >>
> >> just tried to add this patch to the latest HEAD, but realized
> >> ath_set_hw_capab is missing(or I cant seem to grep it)
> >> if you have a patch for the latest tree let me know I can see if I'm hitting
> >> anything like before.
> >
> > The patch would already be merged since 2.6.33.y, this patch is a
> > backport for 2.6.32.y. I just hadn't had time to backport it yet,
> > until today.
> >
> > Luis
> >
>
> so its already in there then..
Right
> if that's the case then the system runs
> good with powersave on then..
Did you read the patch by chance? It only enables power save for
non-AR5416 hardware. What do you have?
Luis
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: James Bottomley @ 2010-06-16 17:33 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <4C18F524.4000902@gmail.com>
On Wed, 2010-06-16 at 09:00 -0700, Justin P. Mattock wrote:
> On 06/16/2010 08:34 AM, James Bottomley wrote:
> > On Tue, 2010-06-15 at 22:33 -0700, Justin P. Mattock wrote:
> >> The below patch fixes a warning message generated by gcc 4.6.0
> >> CC drivers/scsi/hosts.o
> >> drivers/scsi/hosts.c: In function 'scsi_host_alloc':
> >> drivers/scsi/hosts.c:328:6: warning: variable 'rval' set but not used
> >>
> >> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
> >>
> >> ---
> >> drivers/scsi/hosts.c | 2 --
> >> 1 files changed, 0 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> >> index 6660fa9..00fd6a4 100644
> >> --- a/drivers/scsi/hosts.c
> >> +++ b/drivers/scsi/hosts.c
> >> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
> >> {
> >> struct Scsi_Host *shost;
> >> gfp_t gfp_mask = GFP_KERNEL;
> >> - int rval;
> >>
> >> if (sht->unchecked_isa_dma&& privsize)
> >> gfp_mask |= __GFP_DMA;
> >> @@ -420,7 +419,6 @@ 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);
> >> if (IS_ERR(shost->ehandler)) {
> >> - rval = PTR_ERR(shost->ehandler);
> >> goto fail_kfree;
> >> }
> >
> > For future reference, this is less stylistically acceptable C: you've
> > reduced the if clause to a single statement, so the braces need
> > removing.
> >
> > However, I don't think we should be ignoring the fact that the eh thread
> > failed to spawn, so I think some type of printed warning (giving the
> > error code) would be a much more appropriate replacement.
> >
> > James
> >
> >
> >
>
>
> o.k. I'll give a try at that.. as a test I did this(below) seemed to
> compile clean, but not sure if this is what you're asking for though:
>
>
> From 8a4d6e793e0f92d180a6f48c53bbf00d2751ad01 Mon Sep 17 00:00:00 2001
> From: Justin P. Mattock <justinmattock@gmail.com>
> Date: Wed, 16 Jun 2010 08:58:13 -0700
> Subject: [PATCH] test
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/scsi/hosts.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 6660fa9..8d98a46 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct
> scsi_host_template *sht, int privsize)
> {
> struct Scsi_Host *shost;
> gfp_t gfp_mask = GFP_KERNEL;
> - int rval;
>
> if (sht->unchecked_isa_dma && privsize)
> gfp_mask |= __GFP_DMA;
> @@ -420,7 +419,7 @@ 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);
> if (IS_ERR(shost->ehandler)) {
> - rval = PTR_ERR(shost->ehandler);
> + printk(KERN_WARNING "test.....\n")
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
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Rolf Eike Beer @ 2010-06-16 17:25 UTC (permalink / raw)
To: Justin P. Mattock
Cc: James Bottomley, linux-kernel, linux-wireless, linux-pci,
linux-scsi
In-Reply-To: <4C18F524.4000902@gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1478 bytes --]
Justin P. Mattock wrote:
> On 06/16/2010 08:34 AM, James Bottomley wrote:
> > However, I don't think we should be ignoring the fact that the eh thread
> > failed to spawn, so I think some type of printed warning (giving the
> > error code) would be a much more appropriate replacement.
> o.k. I'll give a try at that.. as a test I did this(below) seemed to
> compile clean, but not sure if this is what you're asking for though:
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 6660fa9..8d98a46 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct
> scsi_host_template *sht, int privsize)
> {
> struct Scsi_Host *shost;
> gfp_t gfp_mask = GFP_KERNEL;
> - int rval;
>
> if (sht->unchecked_isa_dma && privsize)
> gfp_mask |= __GFP_DMA;
> @@ -420,7 +419,7 @@ 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);
> if (IS_ERR(shost->ehandler)) {
> - rval = PTR_ERR(shost->ehandler);
> + printk(KERN_WARNING "test.....\n");
> goto fail_kfree;
> }
If you want to print anything here I think the error code would be a good
thing to include as that could give a hint _what_ actually went wrong. In that
case you would need rval, but IMHO it should be declared inside that if
clause.
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5]pci:bus.c Fix variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-16 17:01 UTC (permalink / raw)
To: Junchang Wang; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100616060738.GA12461@host-a-229.ustcsz.edu.cn>
On 06/15/2010 11:07 PM, Junchang Wang wrote:
> On Tue, Jun 15, 2010 at 10:33:52PM -0700, Justin P. Mattock wrote:
>> @@ -234,12 +234,10 @@ void pci_bus_add_devices(const struct pci_bus *bus)
>> void pci_enable_bridges(struct pci_bus *bus)
>> {
>> struct pci_dev *dev;
>> - int retval;
>>
>> list_for_each_entry(dev,&bus->devices, bus_list) {
>> if (dev->subordinate) {
>> if (!pci_is_enabled(dev)) {
>> - retval = pci_enable_device(dev);
> Hi Justin,
>
> pci_enable_device initializes device before it's used by a driver.
>
> I think you should add check instead of eliminating pci_enable_device.
>
> For example,
> retval = pci_enable_device(dev);
> if (retval< 0) {
> goto handle_err;
> }
>
> --Junchang
>
>
this gets it to compile with no warning. although not sure if correct.
if (dev->subordinate) {
if (!pci_is_enabled(dev)) {
retval = pci_enable_device(dev);
if (retval)
printk("test...\n");
pci_set_master(dev);
}
pci_enable_bridges(dev->subordinate);
}
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Justin P. Mattock @ 2010-06-16 16:01 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Kristoffer Ericson, stable, greg, linux-wireless, Peter Stuge,
John W. Linville
In-Reply-To: <AANLkTimDp52ULRcO9NMgeV34olfpD97wYfmr_atOQ5AF@mail.gmail.com>
On 06/16/2010 08:49 AM, Luis R. Rodriguez wrote:
> On Wed, Jun 16, 2010 at 6:33 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>> On 06/16/2010 01:12 AM, Kristoffer Ericson wrote:
>>>
>>> On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
>>>>
>>>> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>>>>
>>>> The newer single chip hardware family of chipsets have not been
>>>> experiencing issues with power saving set by default with recent
>>>> fixes merged (even into stable). The remaining issues are only
>>>> reported with AR5416 and since enabling PS by default can increase
>>>> power savings considerably best to take advantage of that feature
>>>> as this has been tested properly.
>>>
>>> I havent had any issues lately. But that said Ive moved on to
>>> 2.6.33, 2.6.34 which seems to work fine. Believe you set
>>> to disabled by default on those?
>>>
>>> /Kristoffer
>>>
>>
>> just tried to add this patch to the latest HEAD, but realized
>> ath_set_hw_capab is missing(or I cant seem to grep it)
>> if you have a patch for the latest tree let me know I can see if I'm hitting
>> anything like before.
>
> The patch would already be merged since 2.6.33.y, this patch is a
> backport for 2.6.32.y. I just hadn't had time to backport it yet,
> until today.
>
> Luis
>
so its already in there then.. if that's the case then the system runs
good with powersave on then..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-16 16:00 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276702443.2847.153.camel@mulgrave.site>
On 06/16/2010 08:34 AM, James Bottomley wrote:
> On Tue, 2010-06-15 at 22:33 -0700, Justin P. Mattock wrote:
>> The below patch fixes a warning message generated by gcc 4.6.0
>> CC drivers/scsi/hosts.o
>> drivers/scsi/hosts.c: In function 'scsi_host_alloc':
>> drivers/scsi/hosts.c:328:6: warning: variable 'rval' set but not used
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/scsi/hosts.c | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
>> index 6660fa9..00fd6a4 100644
>> --- a/drivers/scsi/hosts.c
>> +++ b/drivers/scsi/hosts.c
>> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
>> {
>> struct Scsi_Host *shost;
>> gfp_t gfp_mask = GFP_KERNEL;
>> - int rval;
>>
>> if (sht->unchecked_isa_dma&& privsize)
>> gfp_mask |= __GFP_DMA;
>> @@ -420,7 +419,6 @@ 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);
>> if (IS_ERR(shost->ehandler)) {
>> - rval = PTR_ERR(shost->ehandler);
>> goto fail_kfree;
>> }
>
> For future reference, this is less stylistically acceptable C: you've
> reduced the if clause to a single statement, so the braces need
> removing.
>
> However, I don't think we should be ignoring the fact that the eh thread
> failed to spawn, so I think some type of printed warning (giving the
> error code) would be a much more appropriate replacement.
>
> James
>
>
>
o.k. I'll give a try at that.. as a test I did this(below) seemed to
compile clean, but not sure if this is what you're asking for though:
From 8a4d6e793e0f92d180a6f48c53bbf00d2751ad01 Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <justinmattock@gmail.com>
Date: Wed, 16 Jun 2010 08:58:13 -0700
Subject: [PATCH] test
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/scsi/hosts.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 6660fa9..8d98a46 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct
scsi_host_template *sht, int privsize)
{
struct Scsi_Host *shost;
gfp_t gfp_mask = GFP_KERNEL;
- int rval;
if (sht->unchecked_isa_dma && privsize)
gfp_mask |= __GFP_DMA;
@@ -420,7 +419,7 @@ 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);
if (IS_ERR(shost->ehandler)) {
- rval = PTR_ERR(shost->ehandler);
+ printk(KERN_WARNING "test.....\n");
goto fail_kfree;
}
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH v2] ipw2200: Enable LED by default
From: Leann Ogasawara @ 2010-06-16 15:57 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette.chatre, ilw, linux-wireless, TJ, BrianK.Lee
In-Reply-To: <AANLkTikUFtsqjGV9oAFkPhceeHzFlfs98psdAPBE5z2N@mail.gmail.com>
On Tue, 2010-06-15 at 21:36 -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 15, 2010 at 7:41 PM, Leann Ogasawara
> <leann.ogasawara@canonical.com> wrote:
> > On Tue, 2010-06-15 at 18:20 -0700, Luis R. Rodriguez wrote:
> >> On Tue, Jun 15, 2010 at 5:55 PM, Leann Ogasawara
> >> <leann.ogasawara@canonical.com> wrote:
> >> > Hi All,
> >> >
> >> > As documented in 2005 in Documentation/networking/README.ipw2200, "The
> >> > LED code has been reported to hang some systems when running ifconfig
> >> > and is therefore disabled by default." We've however been carrying the
> >> > following patch in our Ubuntu kernel for quite some time which enables
> >> > the ipw2200 LED by default. This was a result of numerous user
> >> > requests. We've seen no subsequent bug reports of systems hanging due
> >> > to the the LED code being enabled by default. I'd therefore like to
> >> > propose the following patch to enable the LED by default. This patch
> >> > was originally authored by TJ. I apologize in advance that I do not
> >> > have TJ's full first and last name for provenance.
> >> >
> >> > Thanks,
> >> > Leann
> >> >
> >> > >From 315246037a0edab4d626de6ccb68c73d3fe61ce3 Mon Sep 17 00:00:00 2001
> >> > From: ubuntu@tjworld.net <ubuntu@tjworld.net>
> >> > Date: Mon, 23 Mar 2009 20:29:28 +0000
> >> > Subject: [PATCH] ipw2200: Enable LED by default
> >> >
> >> > BugLink: http://bugs.launchpad.net/bugs/21367
> >> >
> >> > Enable LED by default and update the MODULE_PARM_DESC. The original
> >> > reason for defaulting to disabled was documented in 2005 and noted, "The
> >> > LED code has been reported to hang some systems when running ifconfig
> >> > and is therefore disabled by default." This no longer appears
> >> > applicable and users have been requesting this be enabled for several
> >> > years.
> >> >
> >> > Originally-by: TJ <ubuntu@tjworld.net>
> >>
> >> Does Originally-by also imply he has read the Certificate of Origin
> >> and that he agrees for his code to be used in that way? That is the
> >> purpose of the SOB anyway, but if you took his code, does that imply
> >> that he agrees to it too?
> >
> > I'd CC'd TJ on the initial email, so I'm hoping he will respond here to
> > your inquiry. I can say that he had submitted the original form of the
> > patch to the Ubuntu kernel-team mailing list back in March, 2009:
> >
> > https://lists.ubuntu.com/archives/kernel-team/2009-March/005013.html
> >
> > In that original submission he did provide his official SOB.
> >
> > The patch was then applied with slight modification by Tim Gardner to
> > the Ubuntu kernel. In forwarding this upstream, I wanted to give TJ the
> > proper credit for originating the patch even though it's undergone some
> > slight modification (ie the MODULE_PARM_DESC change). TJ had not
> > officially signed off on this final form of the patch which is the
> > reason I used "Originally-by:". If there is a better approach please
> > let me know.
>
> In that case I would just recommend to keep his original SOB, then it
> would go through you/tim whoever it goes through until it reaches
> Linus. But just my $0.02.
Re-sending and just replacing the Originally-by: with TJ's actual SOB.
Thanks,
Leann
>From 315246037a0edab4d626de6ccb68c73d3fe61ce3 Mon Sep 17 00:00:00 2001
From: ubuntu@tjworld.net <ubuntu@tjworld.net>
Date: Mon, 23 Mar 2009 20:29:28 +0000
Subject: [PATCH] ipw2200: Enable LED by default
BugLink: http://bugs.launchpad.net/bugs/21367
Enable LED by default and update the MODULE_PARM_DESC. The original
reason for defaulting to disabled was documented in 2005 and noted, "The
LED code has been reported to hang some systems when running ifconfig
and is therefore disabled by default." This no longer appears
applicable and users have been requesting this be enabled for several
years.
Signed-off-by: TJ <ubuntu@tjworld.net>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
---
Documentation/networking/README.ipw2200 | 2 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index 80c7285..e4d3267 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -171,7 +171,7 @@ Where the supported parameter are:
led
Can be used to turn on experimental LED code.
- 0 = Off, 1 = On. Default is 0.
+ 0 = Off, 1 = On. Default is 1.
mode
Can be used to set the default mode of the adapter.
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 3aa3bb1..0805569 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -96,7 +96,7 @@ static int network_mode = 0;
static u32 ipw_debug_level;
static int associate;
static int auto_create = 1;
-static int led_support = 0;
+static int led_support = 1;
static int disable = 0;
static int bt_coexist = 0;
static int hwcrypto = 0;
@@ -12083,7 +12083,7 @@ module_param(auto_create, int, 0444);
MODULE_PARM_DESC(auto_create, "auto create adhoc network (default on)");
module_param_named(led, led_support, int, 0444);
-MODULE_PARM_DESC(led, "enable led control on some systems (default 0 off)");
+MODULE_PARM_DESC(led, "enable led control on some systems (default 1 on)");
module_param(debug, int, 0444);
MODULE_PARM_DESC(debug, "debug output mask");
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Luis R. Rodriguez @ 2010-06-16 15:49 UTC (permalink / raw)
To: Justin P. Mattock
Cc: Kristoffer Ericson, stable, greg, linux-wireless, Peter Stuge,
John W. Linville
In-Reply-To: <4C18D2A5.5080702@gmail.com>
On Wed, Jun 16, 2010 at 6:33 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 06/16/2010 01:12 AM, Kristoffer Ericson wrote:
>>
>> On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
>>>
>>> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>>>
>>> The newer single chip hardware family of chipsets have not been
>>> experiencing issues with power saving set by default with recent
>>> fixes merged (even into stable). The remaining issues are only
>>> reported with AR5416 and since enabling PS by default can increase
>>> power savings considerably best to take advantage of that feature
>>> as this has been tested properly.
>>
>> I havent had any issues lately. But that said Ive moved on to
>> 2.6.33, 2.6.34 which seems to work fine. Believe you set
>> to disabled by default on those?
>>
>> /Kristoffer
>>
>
> just tried to add this patch to the latest HEAD, but realized
> ath_set_hw_capab is missing(or I cant seem to grep it)
> if you have a patch for the latest tree let me know I can see if I'm hitting
> anything like before.
The patch would already be merged since 2.6.33.y, this patch is a
backport for 2.6.32.y. I just hadn't had time to backport it yet,
until today.
Luis
^ permalink raw reply
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Luis R. Rodriguez @ 2010-06-16 15:48 UTC (permalink / raw)
To: Kristoffer Ericson
Cc: stable, greg, linux-wireless, Peter Stuge, Justin P. Mattock,
John W. Linville
In-Reply-To: <20100616081227.GA1118@boggieman>
On Wed, Jun 16, 2010 at 1:12 AM, Kristoffer Ericson
<kristoffer.ericson@gmail.com> wrote:
> On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
>> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>>
>> The newer single chip hardware family of chipsets have not been
>> experiencing issues with power saving set by default with recent
>> fixes merged (even into stable). The remaining issues are only
>> reported with AR5416 and since enabling PS by default can increase
>> power savings considerably best to take advantage of that feature
>> as this has been tested properly.
>
> I havent had any issues lately. But that said Ive moved on to
> 2.6.33, 2.6.34 which seems to work fine. Believe you set
> to disabled by default on those?
2.6.33 and up all have PS enabled by default for all single chip
families. For AR5416 and related chipsets, its left disabled as it was
on 2.6.32 right now. The patch is intended only for 2.6.32.y as the
other kernels 2.6.33.y and up already have the same patch.
Luis
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Luis R. Rodriguez @ 2010-06-16 15:46 UTC (permalink / raw)
To: John W. Linville
Cc: Kouhei Sutou, Stephen.Chen, David.Quan, linux-wireless,
Michael.Green
In-Reply-To: <20100616152903.GA3138@tuxdriver.com>
On Wed, Jun 16, 2010 at 8:29 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Thu, Jun 17, 2010 at 12:02:23AM +0900, Kouhei Sutou wrote:
>> Hi,
>>
>> In <20100616134421.GB2404@tuxdriver.com>
>> "Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Wed, 16 Jun 2010 09:44:22 -0400,
>> "John W. Linville" <linville@tuxdriver.com> wrote:
>>
>> > On Wed, Jun 16, 2010 at 09:55:23PM +0900, Kouhei Sutou wrote:
>> >
>> >> I used 'ZD_REGDOMAIN_JAPAN_GW_US54GXS' as a macro name for
>> >> 0x49 because 0x49 is used by GW-US54GXS. Is it OK? Or should
>> >> I use other name for it?
>> >
>> > Hopefully someone can suggest a better name. Anyone know what inspired
>> > "ZD_REGDOMAIN_JAPAN_ADD"?
>>
>> 'ZD_REGDOMAIN_JAPAN_3' was used in another patch:
>> https://patchwork.kernel.org/patch/47220/
>>
>> But I don't know why '3' was used...
>
> '3' makes sense to me. The better question is why not change 'ADD' to '2'? :-)
2 is fine to replace ADD, I think "ADD" is additional :P
Luis
^ permalink raw reply
* Re: [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: James Bottomley @ 2010-06-16 15:34 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276666434-11227-6-git-send-email-justinmattock@gmail.com>
On Tue, 2010-06-15 at 22:33 -0700, Justin P. Mattock wrote:
> The below patch fixes a warning message generated by gcc 4.6.0
> CC drivers/scsi/hosts.o
> drivers/scsi/hosts.c: In function 'scsi_host_alloc':
> drivers/scsi/hosts.c:328:6: warning: variable 'rval' set but not used
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/scsi/hosts.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
> index 6660fa9..00fd6a4 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
> {
> struct Scsi_Host *shost;
> gfp_t gfp_mask = GFP_KERNEL;
> - int rval;
>
> if (sht->unchecked_isa_dma && privsize)
> gfp_mask |= __GFP_DMA;
> @@ -420,7 +419,6 @@ 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);
> if (IS_ERR(shost->ehandler)) {
> - rval = PTR_ERR(shost->ehandler);
> goto fail_kfree;
> }
For future reference, this is less stylistically acceptable C: you've
reduced the if clause to a single statement, so the braces need
removing.
However, I don't think we should be ignoring the fact that the eh thread
failed to spawn, so I think some type of printed warning (giving the
error code) would be a much more appropriate replacement.
James
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: John W. Linville @ 2010-06-16 15:29 UTC (permalink / raw)
To: Kouhei Sutou
Cc: mcgrof, Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <20100617.000223.656204364469558896.kou@clear-code.com>
On Thu, Jun 17, 2010 at 12:02:23AM +0900, Kouhei Sutou wrote:
> Hi,
>
> In <20100616134421.GB2404@tuxdriver.com>
> "Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Wed, 16 Jun 2010 09:44:22 -0400,
> "John W. Linville" <linville@tuxdriver.com> wrote:
>
> > On Wed, Jun 16, 2010 at 09:55:23PM +0900, Kouhei Sutou wrote:
> >
> >> I used 'ZD_REGDOMAIN_JAPAN_GW_US54GXS' as a macro name for
> >> 0x49 because 0x49 is used by GW-US54GXS. Is it OK? Or should
> >> I use other name for it?
> >
> > Hopefully someone can suggest a better name. Anyone know what inspired
> > "ZD_REGDOMAIN_JAPAN_ADD"?
>
> 'ZD_REGDOMAIN_JAPAN_3' was used in another patch:
> https://patchwork.kernel.org/patch/47220/
>
> But I don't know why '3' was used...
'3' makes sense to me. The better question is why not change 'ADD' to '2'? :-)
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] zd1211rw: ignore unknown regulatory domain.
From: Kouhei Sutou @ 2010-06-16 15:02 UTC (permalink / raw)
To: linville; +Cc: mcgrof, Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <20100616134421.GB2404@tuxdriver.com>
Hi,
In <20100616134421.GB2404@tuxdriver.com>
"Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Wed, 16 Jun 2010 09:44:22 -0400,
"John W. Linville" <linville@tuxdriver.com> wrote:
> On Wed, Jun 16, 2010 at 09:55:23PM +0900, Kouhei Sutou wrote:
>
>> I used 'ZD_REGDOMAIN_JAPAN_GW_US54GXS' as a macro name for
>> 0x49 because 0x49 is used by GW-US54GXS. Is it OK? Or should
>> I use other name for it?
>
> Hopefully someone can suggest a better name. Anyone know what inspired
> "ZD_REGDOMAIN_JAPAN_ADD"?
'ZD_REGDOMAIN_JAPAN_3' was used in another patch:
https://patchwork.kernel.org/patch/47220/
But I don't know why '3' was used...
Thanks,
--
kou
^ permalink raw reply
* Compat-wireless build on 2.6.34
From: Ben Gamari @ 2010-06-16 14:49 UTC (permalink / raw)
To: linux-wireless
Is the latest compat-wireless package known to build against 2.6.34? I
have tried both June 15 and June 14 and both fail with errors similar
to the following. Thanks for your help!
- Ben
make -C /lib/modules/2.6.34-ben/build
M=/home/ben/compat-wireless-2010-06-15 modules
make[1]: Entering directory `/home/ben/linux-stable'
CC [M]
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.o
CC [M]
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.o
CC [M]
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/libipw_module.o
CC [M]
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/libipw_tx.o
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:
In function ‘ipw2100_alloc_device’:
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:6138:
error: ‘struct net_device’ has no member named ‘wireless_handlers’
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:6144:
error: ‘struct net_device’ has no member named ‘wireless_data’
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:
At top level:
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8406:
error: unknown field ‘num_private’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8406:
warning: initialization makes pointer from integer without a cast
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8407:
error: unknown field ‘num_private_args’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8407:
warning: excess elements in struct initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8407:
warning: (near initialization for ‘ipw2100_wx_handler_def’)
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8408:
error: unknown field ‘private’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8408:
warning: excess elements in struct initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8408:
warning: (near initialization for ‘ipw2100_wx_handler_def’)
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8409:
error: unknown field ‘private_args’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8409:
warning: excess elements in struct initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2100.c:8409:
warning: (near initialization for ‘ipw2100_wx_handler_def’)
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10118:
error: unknown field ‘num_private’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10118:
warning: initialization makes pointer from integer without a cast
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10119:
error: unknown field ‘num_private_args’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10119:
warning: excess elements in struct initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10119:
warning: (near initialization for ‘ipw_wx_handler_def’)
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10120:
error: unknown field ‘private’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10120:
warning: excess elements in struct initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10120:
warning: (near initialization for ‘ipw_wx_handler_def’)
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10121:
error: unknown field ‘private_args’ specified in initializer
/home/ben/compat-wireless-2010-06-15/drivers/net/wireless/ipw2x00/ipw2200.c:10121:
warning: excess elements in struct initializer
/home/ben/c
^ permalink raw reply
* Re: "ressource temporarily unavailable" on 2.4 GHz, not on 5GHz
From: John W. Linville @ 2010-06-16 14:21 UTC (permalink / raw)
To: Dennis Borgmann; +Cc: linux-wireless, hostap
In-Reply-To: <4C18DA3D.1030303@googlemail.com>
On Wed, Jun 16, 2010 at 04:05:49PM +0200, Dennis Borgmann wrote:
> Hello wireless-list!
> Hello hostapd-list!
>
> I am using ath5k with hostapd-0.6.9 on a debian running kernel 2.6.34
> and I am observing a "ressource temporarily unavailable" - error code 11
> if I pump out multicast-packets quite fast. I wrote a small
> test-program, that handles this test and as soon as I go down to a
> 8ms-pause or below in betweens the packets, the error is thrown quite
> soon after starting the program. Funny thing is, that this error only
> occurs in g-band (2.4 GHz), not in a-band (5GHz).
>
> What could be the problem? Is this due to backoff-times in 2.4 GHz, that
> don't occur on 5 GHz? Or could this be a bug?
My only initial thought is that the 2.5GHz band is usually more
utilized. So there is more likely to be retransmissions, etc.
> Find attached my small piece of code to test and reproduce this effect.
Perhaps you could include actual dmesg output?
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: "ressource temporarily unavailable" on 2.4 GHz, not on 5GHz
From: Bob Copeland @ 2010-06-16 14:38 UTC (permalink / raw)
To: Dennis Borgmann; +Cc: linux-wireless, hostap
In-Reply-To: <4C18DA3D.1030303@googlemail.com>
On Wed, Jun 16, 2010 at 10:05 AM, Dennis Borgmann
<dennis.borgmann@googlemail.com> wrote:
> Hello wireless-list!
> Hello hostapd-list!
>
> I am using ath5k with hostapd-0.6.9 on a debian running kernel 2.6.34
> and I am observing a "ressource temporarily unavailable" - error code 11
[...]
> What could be the problem? Is this due to backoff-times in 2.4 GHz, that
> don't occur on 5 GHz? Or could this be a bug?
Does dmesg report any error (e.g. no available txbuf)?
My guess is you have more frequent successful delivery in 5 GHz than in
ISM band so you aren't running out of send buffers somewhere in the stack.
Of course, your program should expect and handle EAGAIN if you are
using MSG_DONTWAIT.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] mac80211: fix warn, enum may be used uninitialized
From: Christoph Fritz @ 2010-06-16 14:37 UTC (permalink / raw)
To: John W. Linville, Johannes Berg
Cc: kernel-janitors, linux-wireless, David S. Miller, Kalle Valo
regression introduced by b8d92c9c141ee3dc9b3537b1f0ffb4a54ea8d9b2
In function ‘ieee80211_work_rx_queued_mgmt’:
warning: ‘rma’ may be used uninitialized in this function
this re-adds default value WORK_ACT_NONE back to rma
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
---
net/mac80211/work.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index be3d4a6..b025dc7 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -715,7 +715,7 @@ static void ieee80211_work_rx_queued_mgmt(struct ieee80211_local *local,
struct ieee80211_rx_status *rx_status;
struct ieee80211_mgmt *mgmt;
struct ieee80211_work *wk;
- enum work_action rma;
+ enum work_action rma = WORK_ACT_NONE;
u16 fc;
rx_status = (struct ieee80211_rx_status *) skb->cb;
--
1.7.1
^ permalink raw reply related
* Re: "ressource temporarily unavailable" on 2.4 GHz, not on 5GHz
From: John W. Linville @ 2010-06-16 14:23 UTC (permalink / raw)
To: Dennis Borgmann; +Cc: linux-wireless, hostap
In-Reply-To: <4C18DA3D.1030303@googlemail.com>
On Wed, Jun 16, 2010 at 04:05:49PM +0200, Dennis Borgmann wrote:
> Hello wireless-list!
> Hello hostapd-list!
>
> I am using ath5k with hostapd-0.6.9 on a debian running kernel 2.6.34
> and I am observing a "ressource temporarily unavailable" - error code 11
> if I pump out multicast-packets quite fast. I wrote a small
> test-program, that handles this test and as soon as I go down to a
> 8ms-pause or below in betweens the packets, the error is thrown quite
> soon after starting the program. Funny thing is, that this error only
> occurs in g-band (2.4 GHz), not in a-band (5GHz).
>
> What could be the problem? Is this due to backoff-times in 2.4 GHz, that
> don't occur on 5 GHz? Or could this be a bug?
My only initial thought is that the 2.5GHz band is usually more
utilized. So there is more likely to be retransmissions, etc.
> Find attached my small piece of code to test and reproduce this effect.
Perhaps you could include actual dmesg output?
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
* "ressource temporarily unavailable" on 2.4 GHz, not on 5GHz
From: Dennis Borgmann @ 2010-06-16 14:05 UTC (permalink / raw)
To: linux-wireless, hostap
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Hello wireless-list!
Hello hostapd-list!
I am using ath5k with hostapd-0.6.9 on a debian running kernel 2.6.34
and I am observing a "ressource temporarily unavailable" - error code 11
if I pump out multicast-packets quite fast. I wrote a small
test-program, that handles this test and as soon as I go down to a
8ms-pause or below in betweens the packets, the error is thrown quite
soon after starting the program. Funny thing is, that this error only
occurs in g-band (2.4 GHz), not in a-band (5GHz).
What could be the problem? Is this due to backoff-times in 2.4 GHz, that
don't occur on 5 GHz? Or could this be a bug?
Find attached my small piece of code to test and reproduce this effect.
Kind regards,
Dennis
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: connection_test_multicast.c --]
[-- Type: text/x-csrc; name="connection_test_multicast.c", Size: 2300 bytes --]
#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>
#include <stdio.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
#include <linux/ip.h>
#include <string.h>
#include <stdlib.h>
#define MULTICAST_IP "224.0.0.1"
#define PORT 12345
struct sockaddr_in server_address;
int fd_socket;
int init_connection_client( void ) {
int sock, opt;
errno = 0;
//create a socket
sock = socket( PF_INET, SOCK_DGRAM, 0 );
if( sock == -1 ) {
printf("%s:%u socket() error (%s), error-code: %d\n", __FILE__, __LINE__, strerror(errno), sock);
exit(EXIT_FAILURE);
}
server_address.sin_family = PF_INET;
server_address.sin_addr.s_addr = inet_addr( MULTICAST_IP );
server_address.sin_port = htons( PORT );
if( bind( sock, (struct sockaddr*)&server_address, sizeof(struct sockaddr)) == -1 ) {
printf("%s:%u bind error (%s), error-code: %d\n", __FILE__, __LINE__, strerror(errno), errno);
exit(EXIT_FAILURE);
}
//set socket options
//IPTOS = type of service and precedence
//IPTOS_LOWDELAY = minimize delay
//IPTOS_PREC_PRIORITY =
opt = IPTOS_PREC_PRIORITY | IPTOS_LOWDELAY;
if( setsockopt( sock, IPPROTO_IP, IP_TOS, &opt, sizeof(opt)) == -1 ) {
printf("%s:%u setsockopt(IP_TOS) error (%s), error-code: %d\n", __FILE__, __LINE__, strerror(errno), errno);
exit(EXIT_FAILURE);
}
//give these packets the maximum priority
//SOL_SOCKET = manipulate at socket level
opt = 7;
if( setsockopt( sock, SOL_SOCKET, SO_PRIORITY, &opt, sizeof(opt)) == -1 ) {
printf("%s:%u setsockopt(SO_PRIORITY) error (%s), error-code: %d\n", __FILE__, __LINE__, strerror(errno), errno);
exit(EXIT_FAILURE);
}
return sock;
}
int send_data( unsigned char *network_data, size_t len ) {
if( sendto( fd_socket, network_data, len, MSG_DONTWAIT, \
(struct sockaddr*)&server_address, sizeof(struct sockaddr_in) ) == -1 ) {
printf("%s:%u sendto() error (%s), error-code: %d\n", __FILE__, __LINE__, strerror(errno), errno);
return errno;
}
return 0;
}
int main(int argc, char **argv) {
unsigned char *data_for_transmission;
int sleeper=atoi(argv[1]);
printf("%d\n",sleeper);
data_for_transmission = malloc( 1068 );
fd_socket=init_connection_client();
while(1) {
send_data( data_for_transmission, 1068 );
usleep(sleeper);
}
return 0;
}
^ permalink raw reply
* Re: [PATCH] ath9k: Modify LED blinking pattern during wifi activity.
From: John W. Linville @ 2010-06-16 13:38 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linux-wireless
In-Reply-To: <AANLkTimprPdviZPX26qcH-uM8FyNY09JEH3kRvqwDi-S@mail.gmail.com>
On Wed, Jun 16, 2010 at 11:21:27AM +0530, Vivek Natarajan wrote:
> On Wed, Jun 16, 2010 at 1:21 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > On Tue, Jun 15, 2010 at 10:50:17AM +0530, Vivek Natarajan wrote:
> >> Some vendors require the LED to be ON always irrespective of any
> >> radio activity. Introducing a module parameter to enable this,
> >> so that one can choose between always on or led blink during
> >> activity.
> >>
> >> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
> >
> > Any particular reason the always-on behaviour is the default?
>
> There is no specific reason for setting it as default. It is only that
> some customers preferred the led to be always on instead of blinking.
Well it is just that as I read the patch, you are changing the
behaviour for everyone rather than simply giving a new option for
those that don't like it that way it already is.
Look, I don't particular care about the behaviour. Blinking w/
activity makes sense to me. But I also get to read the seemingly
endless, whining complaints about how the blinking is distracting for
laptop users. I just would rather not add another endless stream of
complaints that say "my wifi LED used to blink w/ activity, now it
doesn't -- fix it!"
Perhaps we could standardize this somehow? Anyone care to make
a proposal?
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] zd1211rw: ignore unknown regulatory domain.
From: John W. Linville @ 2010-06-16 13:44 UTC (permalink / raw)
To: Kouhei Sutou
Cc: mcgrof, Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <20100616.215523.1718341995174283889.kou@clear-code.com>
On Wed, Jun 16, 2010 at 09:55:23PM +0900, Kouhei Sutou wrote:
> I used 'ZD_REGDOMAIN_JAPAN_GW_US54GXS' as a macro name for
> 0x49 because 0x49 is used by GW-US54GXS. Is it OK? Or should
> I use other name for it?
Hopefully someone can suggest a better name. Anyone know what inspired
"ZD_REGDOMAIN_JAPAN_ADD"?
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox