[PATCH 0/2] Fix iwl6000 does not work in 2.6.31 kernel
Ike Panhc
User reports that the Ubuntu Karmic (2.6.31-14-generic) recognize the the PCI
id of iwl6000 series but can not scan for APs and not even to associate to AP.
We need two commits cherry-picked from mainline kernel to fix this problem.
Since we have only version 4 firmware for iwl6000 in the linux-firmware package.
We need to change the IWL6000_UCODE_API_MAX to v4 for driver to load version 4
firmware.
After fixing the firmware loading issue, the dmesg reports randomly command
timeout for RXON, Unifying RXON timing is necessary for iwl6000. One minor
conflict solved due to we still need sw_crypto in iwl-dev.h
Patches against linux-2.6.31.8 and Ubuntu-2.6.31-17.54 are listed below.
Ike Panhc (1):
iwlwifi: unify iwl_setup_rxon_timing
Wey-Yi Guy (1):
iwlwifi: change IWL6000_UCODE_API_MAX to v4
drivers/net/wireless/iwlwifi/iwl-3945.c | 1 +
drivers/net/wireless/iwlwifi/iwl-6000.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 64 -----------------------
drivers/net/wireless/iwlwifi/iwl-commands.h | 20 +++++++-
drivers/net/wireless/iwlwifi/iwl-core.c | 59 +++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
drivers/net/wireless/iwlwifi/iwl3945-base.c | 74 +--------------------------
8 files changed, 84 insertions(+), 140 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ike Panhc
of AGN and 3945. HWs differ only in supported maximal
beacon interval. This is reflected in hw_paras.max_beacon_itrvl
Signed-off-by: Tomas Winkler <tomas....@intel.com>
Signed-off-by: Reinette Chatre <reinett...@intel.com>
Signed-off-by: John W. Linville <linv...@tuxdriver.com>
(cherry picked from commit 2c2f3b33888419fb9e7d015b9dc67b9db4437efa)
Conflicts:
drivers/net/wireless/iwlwifi/iwl-dev.h
CC: sta...@kernel.org
Signed-off-by: Ike Panhc <ike...@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/496496
---
drivers/net/wireless/iwlwifi/iwl-3945.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn.c | 64 -----------------------
drivers/net/wireless/iwlwifi/iwl-commands.h | 2 +
drivers/net/wireless/iwlwifi/iwl-core.c | 59 +++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
drivers/net/wireless/iwlwifi/iwl3945-base.c | 74 +--------------------------
7 files changed, 66 insertions(+), 136 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index b73ab6c..baef5a8 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -2562,6 +2562,7 @@ int iwl3945_hw_set_hw_params(struct iwl_priv *priv)
priv->hw_params.bcast_sta_id = IWL3945_BROADCAST_ID;
priv->hw_params.rx_wrt_ptr_reg = FH39_RSCSR_CHNL0_WPTR;
+ priv->hw_params.max_beacon_itrvl = IWL39_MAX_UCODE_BEACON_INTERVAL;
return 0;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index 2a577ae..774f538 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -512,70 +512,6 @@ int iwl_hw_tx_queue_init(struct iwl_priv *priv,
return 0;
}
-
-/******************************************************************************
- *
- * Misc. internal state and helper functions
- *
- ******************************************************************************/
-
-#define MAX_UCODE_BEACON_INTERVAL 4096
-
-static u16 iwl_adjust_beacon_interval(u16 beacon_val)
-{
- u16 new_val = 0;
- u16 beacon_factor = 0;
-
- beacon_factor = (beacon_val + MAX_UCODE_BEACON_INTERVAL)
- / MAX_UCODE_BEACON_INTERVAL;
- new_val = beacon_val / beacon_factor;
-
- if (!new_val)
- new_val = MAX_UCODE_BEACON_INTERVAL;
-
- return new_val;
-}
-
-static void iwl_setup_rxon_timing(struct iwl_priv *priv)
-{
- u64 tsf;
- s32 interval_tm, rem;
- unsigned long flags;
- struct ieee80211_conf *conf = NULL;
- u16 beacon_int = 0;
-
- conf = ieee80211_get_hw_conf(priv->hw);
-
- spin_lock_irqsave(&priv->lock, flags);
- priv->rxon_timing.timestamp = cpu_to_le64(priv->timestamp);
- priv->rxon_timing.listen_interval = cpu_to_le16(conf->listen_interval);
-
- if (priv->iw_mode == NL80211_IFTYPE_STATION) {
- beacon_int = iwl_adjust_beacon_interval(priv->beacon_int);
- priv->rxon_timing.atim_window = 0;
- } else {
- beacon_int = iwl_adjust_beacon_interval(
- priv->vif->bss_conf.beacon_int);
-
- /* TODO: we need to get atim_window from upper stack
- * for now we set to 0 */
- priv->rxon_timing.atim_window = 0;
- }
-
- priv->rxon_timing.beacon_interval = cpu_to_le16(beacon_int);
-
- tsf = priv->timestamp; /* tsf is modifed by do_div: copy it */
- interval_tm = beacon_int * 1024;
- rem = do_div(tsf, interval_tm);
- priv->rxon_timing.beacon_init_val = cpu_to_le32(interval_tm - rem);
-
- spin_unlock_irqrestore(&priv->lock, flags);
- IWL_DEBUG_ASSOC(priv, "beacon interval %d beacon timer %d beacon tim %d\n",
- le16_to_cpu(priv->rxon_timing.beacon_interval),
- le32_to_cpu(priv->rxon_timing.beacon_init_val),
- le16_to_cpu(priv->rxon_timing.atim_window));
-}
-
/******************************************************************************
*
* Generic RX handler implementations
diff --git a/drivers/net/wireless/iwlwifi/iwl-commands.h b/drivers/net/wireless/iwlwifi/iwl-commands.h
index 69a97c7..a61393a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-commands.h
+++ b/drivers/net/wireless/iwlwifi/iwl-commands.h
@@ -765,6 +765,8 @@ struct iwl5000_rxon_assoc_cmd {
} __attribute__ ((packed));
#define IWL_CONN_MAX_LISTEN_INTERVAL 10
+#define IWL_MAX_UCODE_BEACON_INTERVAL 4 /* 4096 */
+#define IWL39_MAX_UCODE_BEACON_INTERVAL 1 /* 1024 */
/*
* REPLY_RXON_TIMING = 0x14 (command, has simple generic response)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 18b135f..d678e6a 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -635,6 +635,63 @@ u8 iwl_is_fat_tx_allowed(struct iwl_priv *priv,
}
EXPORT_SYMBOL(iwl_is_fat_tx_allowed);
+static u16 iwl_adjust_beacon_interval(u16 beacon_val, u16 max_beacon_val)
+{
+ u16 new_val = 0;
+ u16 beacon_factor = 0;
+
+ beacon_factor = (beacon_val + max_beacon_val) / max_beacon_val;
+ new_val = beacon_val / beacon_factor;
+
+ if (!new_val)
+ new_val = max_beacon_val;
+
+ return new_val;
+}
+
+void iwl_setup_rxon_timing(struct iwl_priv *priv)
+{
+ u64 tsf;
+ s32 interval_tm, rem;
+ unsigned long flags;
+ struct ieee80211_conf *conf = NULL;
+ u16 beacon_int;
+
+ conf = ieee80211_get_hw_conf(priv->hw);
+
+ spin_lock_irqsave(&priv->lock, flags);
+ priv->rxon_timing.timestamp = cpu_to_le64(priv->timestamp);
+ priv->rxon_timing.listen_interval = cpu_to_le16(conf->listen_interval);
+
+ if (priv->iw_mode == NL80211_IFTYPE_STATION) {
+ beacon_int = priv->beacon_int;
+ priv->rxon_timing.atim_window = 0;
+ } else {
+ beacon_int = priv->vif->bss_conf.beacon_int;
+
+ /* TODO: we need to get atim_window from upper stack
+ * for now we set to 0 */
+ priv->rxon_timing.atim_window = 0;
+ }
+
+ beacon_int = iwl_adjust_beacon_interval(beacon_int,
+ priv->hw_params.max_beacon_itrvl * 1024);
+ priv->rxon_timing.beacon_interval = cpu_to_le16(beacon_int);
+
+ tsf = priv->timestamp; /* tsf is modifed by do_div: copy it */
+ interval_tm = beacon_int * 1024;
+ rem = do_div(tsf, interval_tm);
+ priv->rxon_timing.beacon_init_val = cpu_to_le32(interval_tm - rem);
+
+ spin_unlock_irqrestore(&priv->lock, flags);
+ IWL_DEBUG_ASSOC(priv,
+ "beacon interval %d beacon timer %d beacon tim %d\n",
+ le16_to_cpu(priv->rxon_timing.beacon_interval),
+ le32_to_cpu(priv->rxon_timing.beacon_init_val),
+ le16_to_cpu(priv->rxon_timing.atim_window));
+}
+EXPORT_SYMBOL(iwl_setup_rxon_timing);
+
void iwl_set_rxon_hwcrypto(struct iwl_priv *priv, int hw_decrypt)
{
struct iwl_rxon_cmd *rxon = &priv->staging_rxon;
@@ -1373,6 +1430,8 @@ int iwl_set_hw_params(struct iwl_priv *priv)
priv->hw_params.rx_buf_size = IWL_RX_BUF_SIZE_4K;
priv->hw_params.max_pkt_size = priv->hw_params.rx_buf_size - 256;
+ priv->hw_params.max_beacon_itrvl = IWL_MAX_UCODE_BEACON_INTERVAL;
+
if (priv->cfg->mod_params->disable_11n)
priv->cfg->sku &= ~IWL_SKU_N;
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 1e51891..03eef83 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -572,6 +572,7 @@ extern void iwl_rx_reply_rx_phy(struct iwl_priv *priv,
void iwl_rx_reply_compressed_ba(struct iwl_priv *priv,
struct iwl_rx_mem_buffer *rxb);
+void iwl_setup_rxon_timing(struct iwl_priv *priv);
static inline int iwl_send_rxon_assoc(struct iwl_priv *priv)
{
return priv->cfg->ops->hcmd->rxon_assoc(priv);
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index e8c8607..f9d05bb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -626,6 +626,7 @@ struct iwl_hw_params {
u8 bcast_sta_id;
u8 fat_channel;
u8 sw_crypto;
+ u8 max_beacon_itrvl; /* in 1024 ms */
u32 max_inst_size;
u32 max_data_size;
u32 max_bsm_size;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 4fac582..34f521c 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -361,76 +361,6 @@ static void iwl3945_unset_hw_params(struct iwl_priv *priv)
priv->shared_phys);
}
-#define MAX_UCODE_BEACON_INTERVAL 1024
-#define INTEL_CONN_LISTEN_INTERVAL cpu_to_le16(0xA)
-
-static __le16 iwl3945_adjust_beacon_interval(u16 beacon_val)
-{
- u16 new_val = 0;
- u16 beacon_factor = 0;
-
- beacon_factor =
- (beacon_val + MAX_UCODE_BEACON_INTERVAL)
- / MAX_UCODE_BEACON_INTERVAL;
- new_val = beacon_val / beacon_factor;
-
- return cpu_to_le16(new_val);
-}
-
-static void iwl3945_setup_rxon_timing(struct iwl_priv *priv)
-{
- u64 interval_tm_unit;
- u64 tsf, result;
- unsigned long flags;
- struct ieee80211_conf *conf = NULL;
- u16 beacon_int = 0;
-
- conf = ieee80211_get_hw_conf(priv->hw);
-
- spin_lock_irqsave(&priv->lock, flags);
- priv->rxon_timing.timestamp = cpu_to_le64(priv->timestamp);
- priv->rxon_timing.listen_interval = INTEL_CONN_LISTEN_INTERVAL;
-
- tsf = priv->timestamp;
-
- beacon_int = priv->beacon_int;
- spin_unlock_irqrestore(&priv->lock, flags);
-
- if (priv->iw_mode == NL80211_IFTYPE_STATION) {
- if (beacon_int == 0) {
- priv->rxon_timing.beacon_interval = cpu_to_le16(100);
- priv->rxon_timing.beacon_init_val = cpu_to_le32(102400);
- } else {
- priv->rxon_timing.beacon_interval =
- cpu_to_le16(beacon_int);
- priv->rxon_timing.beacon_interval =
- iwl3945_adjust_beacon_interval(
- le16_to_cpu(priv->rxon_timing.beacon_interval));
- }
-
- priv->rxon_timing.atim_window = 0;
- } else {
- priv->rxon_timing.beacon_interval =
- iwl3945_adjust_beacon_interval(
- priv->vif->bss_conf.beacon_int);
- /* TODO: we need to get atim_window from upper stack
- * for now we set to 0 */
- priv->rxon_timing.atim_window = 0;
- }
-
- interval_tm_unit =
- (le16_to_cpu(priv->rxon_timing.beacon_interval) * 1024);
- result = do_div(tsf, interval_tm_unit);
- priv->rxon_timing.beacon_init_val =
- cpu_to_le32((u32) ((u64) interval_tm_unit - result));
-
- IWL_DEBUG_ASSOC(priv,
- "beacon interval %d beacon timer %d beacon tim %d\n",
- le16_to_cpu(priv->rxon_timing.beacon_interval),
- le32_to_cpu(priv->rxon_timing.beacon_init_val),
- le16_to_cpu(priv->rxon_timing.atim_window));
-}
-
static void iwl3945_build_tx_cmd_hwcrypto(struct iwl_priv *priv,
struct ieee80211_tx_info *info,
struct iwl_cmd *cmd,
@@ -3084,7 +3014,7 @@ void iwl3945_post_associate(struct iwl_priv *priv)
iwlcore_commit_rxon(priv);
memset(&priv->rxon_timing, 0, sizeof(struct iwl_rxon_time_cmd));
- iwl3945_setup_rxon_timing(priv);
+ iwl_setup_rxon_timing(priv);
rc = iwl_send_cmd_pdu(priv, REPLY_RXON_TIMING,
sizeof(priv->rxon_timing), &priv->rxon_timing);
if (rc)
@@ -3279,7 +3209,7 @@ void iwl3945_config_ap(struct iwl_priv *priv)
/* RXON Timing */
memset(&priv->rxon_timing, 0, sizeof(struct iwl_rxon_time_cmd));
- iwl3945_setup_rxon_timing(priv);
+ iwl_setup_rxon_timing(priv);
rc = iwl_send_cmd_pdu(priv, REPLY_RXON_TIMING,
sizeof(priv->rxon_timing),
&priv->rxon_timing);
--
1.6.3.3
Greg KH
> This patch unifies setup_rxon_timing funcions
> of AGN and 3945. HWs differ only in supported maximal
> beacon interval. This is reflected in hw_paras.max_beacon_itrvl
>
> Signed-off-by: Tomas Winkler <tomas....@intel.com>
> Signed-off-by: Reinette Chatre <reinett...@intel.com>
> Signed-off-by: John W. Linville <linv...@tuxdriver.com>
> (cherry picked from commit 2c2f3b33888419fb9e7d015b9dc67b9db4437efa)
>
> Conflicts:
>
> drivers/net/wireless/iwlwifi/iwl-dev.h
What does this mean?
> CC: sta...@kernel.org
> Signed-off-by: Ike Panhc <ike...@canonical.com>
>
> BugLink: http://bugs.launchpad.net/bugs/496496
What are you expecting this patch to be applied to?
confused,
greg k-h
Ike Panhc
> On Tue, Dec 15, 2009 at 11:45:10AM +0800, Ike Panhc wrote:
>> This patch unifies setup_rxon_timing funcions
>> of AGN and 3945. HWs differ only in supported maximal
>> beacon interval. This is reflected in hw_paras.max_beacon_itrvl
>>
>> Signed-off-by: Tomas Winkler <tomas....@intel.com>
>> Signed-off-by: Reinette Chatre <reinett...@intel.com>
>> Signed-off-by: John W. Linville <linv...@tuxdriver.com>
>> (cherry picked from commit 2c2f3b33888419fb9e7d015b9dc67b9db4437efa)
>>
>> Conflicts:
>>
>> drivers/net/wireless/iwlwifi/iwl-dev.h
>
> What does this mean?
>
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@@ -625,7 -608,7 +625,11 @@@ struct iwl_hw_params
u8 max_stations;
u8 bcast_sta_id;
u8 fat_channel;
++<<<<<<< HEAD:drivers/net/wireless/iwlwifi/iwl-dev.h
+ u8 sw_crypto;
++=======
+ u8 max_beacon_itrvl; /* in 1024 ms */
++>>>>>>> 2c2f3b3... iwlwifi: unify iwl_setup_rxon_timing:drivers/net/wireless/iwlwifi/iwl-dev.h
u32 max_inst_size;
u32 max_data_size;
u32 max_bsm_size;
The sw_crypto is removed in the prior commit (90e8e4), and the commit
is not in the stable tree. We still need sw_crypto.
So, the patch is modified to keep sw_crypto.
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -626,6 +626,7 @@ struct iwl_hw_params {
u8 bcast_sta_id;
u8 fat_channel;
u8 sw_crypto;
+ u8 max_beacon_itrvl; /* in 1024 ms */
u32 max_inst_size;
u32 max_data_size;
u32 max_bsm_size;
>> CC: sta...@kernel.org
>> Signed-off-by: Ike Panhc <ike...@canonical.com>
>>
>> BugLink: http://bugs.launchpad.net/bugs/496496
>
> What are you expecting this patch to be applied to?
>
> confused,
Please consider applying to linux-2.6.31.y
Greg KH
And why would we care? We've never used this kind of marking before in
the kernel changelogs that I know of.
> >> CC: sta...@kernel.org
> >> Signed-off-by: Ike Panhc <ike...@canonical.com>
> >>
> >> BugLink: http://bugs.launchpad.net/bugs/496496
> >
> > What are you expecting this patch to be applied to?
> >
> > confused,
> Please consider applying to linux-2.6.31.y
I need the subsystem maintainer to agree with this, have they?
thanks,
Marcel Holtmann
I agree here. Not copying Reinette on this is just wrong. And blindly
picking some patches and sending them for -stable even more.
Regards
Marcel
John W. Linville
> On Tue, Dec 15, 2009 at 03:02:17PM +0800, Ike Panhc wrote:
> > Please consider applying to linux-2.6.31.y
>
> I need the subsystem maintainer to agree with this, have they?
It seems fine to me. You may want to let Intel comment too.
John
--
John W. Linville Someday the world will need a hero, and you
linv...@tuxdriver.com might be all we have. Be ready.
John W. Linville
> I agree here. Not copying Reinette on this is just wrong. And blindly
> picking some patches and sending them for -stable even more.
I agree that Reinette should have been copied. I'm not sure I agree
that sending the patches was wrong by itself.
Canonical gets kicked in the teeth for lack of upstream participation
all the time. I even have some of their enamel on my shoes...
But let's not be too hard on them for making a mistake while trying
to do something that is overall helpful to the community at large.
Just my $0.02...
John
--
John W. Linville Someday the world will need a hero, and you
linv...@tuxdriver.com might be all we have. Be ready.
Greg KH
> On Tue, Dec 15, 2009 at 08:34:00AM -0800, Marcel Holtmann wrote:
>
> > I agree here. Not copying Reinette on this is just wrong. And blindly
> > picking some patches and sending them for -stable even more.
>
> I agree that Reinette should have been copied. I'm not sure I agree
> that sending the patches was wrong by itself.
I'm not saying it is wrong, but I agree, you need to copy the
maintainer, as we would need their ack before being able to accept any
type of backport.
Ike, the script, scripts/get_maintainer.pl is your friend here.
thanks,
greg k-h
Stefan Bader
> On Tue, Dec 15, 2009 at 11:39:24AM -0500, John W. Linville wrote:
>> On Tue, Dec 15, 2009 at 08:34:00AM -0800, Marcel Holtmann wrote:
>>
>>> I agree here. Not copying Reinette on this is just wrong. And blindly
>>> picking some patches and sending them for -stable even more.
>> I agree that Reinette should have been copied. I'm not sure I agree
>> that sending the patches was wrong by itself.
>
> I'm not saying it is wrong, but I agree, you need to copy the
> maintainer, as we would need their ack before being able to accept any
> type of backport.
>
> Ike, the script, scripts/get_maintainer.pl is your friend here.
I should take some of the bashing here for not having been too
specific when pushing people to "send it to stable". As John said,
we are learning here.
I see that this gets improved.
Thanks,
Stefan
reinette chatre
> On Tue, Dec 15, 2009 at 05:49:43AM -0800, Greg KH wrote:
> > On Tue, Dec 15, 2009 at 03:02:17PM +0800, Ike Panhc wrote:
>
> > > Please consider applying to linux-2.6.31.y
> >
> > I need the subsystem maintainer to agree with this, have they?
>
> It seems fine to me. You may want to let Intel comment too.
>
No objection here. Even so, I find it strange that this patch fixes a
problem since it really should not have any functional changes.
I see this patch is 2/2 of a series ... was 1/2 an iwlwifi patch also?
Reinette
Greg KH
> On Tue, 2009-12-15 at 08:31 -0800, John W. Linville wrote:
> > On Tue, Dec 15, 2009 at 05:49:43AM -0800, Greg KH wrote:
> > > On Tue, Dec 15, 2009 at 03:02:17PM +0800, Ike Panhc wrote:
> >
> > > > Please consider applying to linux-2.6.31.y
> > >
> > > I need the subsystem maintainer to agree with this, have they?
> >
> > It seems fine to me. You may want to let Intel comment too.
> >
>
> No objection here. Even so, I find it strange that this patch fixes a
> problem since it really should not have any functional changes.
Ok, if there is no functional change, why is this needed?
Ike?
thanks,
greg k-h
Ike Panhc
> On Tue, Dec 15, 2009 at 11:42:48AM -0800, reinette chatre wrote:
>> On Tue, 2009-12-15 at 08:31 -0800, John W. Linville wrote:
>>> On Tue, Dec 15, 2009 at 05:49:43AM -0800, Greg KH wrote:
>>>> On Tue, Dec 15, 2009 at 03:02:17PM +0800, Ike Panhc wrote:
>>>>> Please consider applying to linux-2.6.31.y
>>>> I need the subsystem maintainer to agree with this, have they?
>>> It seems fine to me. You may want to let Intel comment too.
>>>
>> No objection here. Even so, I find it strange that this patch fixes a
>> problem since it really should not have any functional changes.
>
> Ok, if there is no functional change, why is this needed?
>
> Ike?
>
> thanks,
>
> greg k-h
misunderstanding about the patch. Please do not put the second patch into
stable.
But Please consider applying the first patch (change IWL6000_UCODE_API_MAX
to v4) to 2.6.31-stable tree. It will be good to use v4 firmware on iwl6000.
Greg KH
> Greg KH wrote:
> > On Tue, Dec 15, 2009 at 11:42:48AM -0800, reinette chatre wrote:
> >> On Tue, 2009-12-15 at 08:31 -0800, John W. Linville wrote:
> >>> On Tue, Dec 15, 2009 at 05:49:43AM -0800, Greg KH wrote:
> >>>> On Tue, Dec 15, 2009 at 03:02:17PM +0800, Ike Panhc wrote:
> >>>>> Please consider applying to linux-2.6.31.y
> >>>> I need the subsystem maintainer to agree with this, have they?
> >>> It seems fine to me. You may want to let Intel comment too.
> >>>
> >> No objection here. Even so, I find it strange that this patch fixes a
> >> problem since it really should not have any functional changes.
> >
> > Ok, if there is no functional change, why is this needed?
> >
> > Ike?
> >
> > thanks,
> >
> > greg k-h
> I review the patch again. Yes, it is no functional change. Sorry I have
> misunderstanding about the patch. Please do not put the second patch into
> stable.
Ok, will do.
> But Please consider applying the first patch (change IWL6000_UCODE_API_MAX
> to v4) to 2.6.31-stable tree. It will be good to use v4 firmware on iwl6000.
Why, what bug does it fix? Will it require users to update their
firmware versions on their system as well?
thanks,
greg k-h
reinette chatre
> But Please consider applying the first patch (change IWL6000_UCODE_API_MAX
> to v4) to 2.6.31-stable tree. It will be good to use v4 firmware on iwl6000.
Please no. This will effectively enable 6000 series in 2.6.31. We did
not target 2.6.31 for 6000 series enabling and more patches, which are
in 2.6.32, are required for 6000 series to work well.
Reinette
Ike Panhc
> On Tue, 2009-12-15 at 22:46 -0800, Ike Panhc wrote:
>
>> But Please consider applying the first patch (change IWL6000_UCODE_API_MAX
>> to v4) to 2.6.31-stable tree. It will be good to use v4 firmware on iwl6000.
>
> Please no. This will effectively enable 6000 series in 2.6.31. We did
> not target 2.6.31 for 6000 series enabling and more patches, which are
> in 2.6.32, are required for 6000 series to work well.
>
> Reinette
>
Greg KH
> reinette chatre wrote:
> > On Tue, 2009-12-15 at 22:46 -0800, Ike Panhc wrote:
> >
> >> But Please consider applying the first patch (change IWL6000_UCODE_API_MAX
> >> to v4) to 2.6.31-stable tree. It will be good to use v4 firmware on iwl6000.
> >
> > Please no. This will effectively enable 6000 series in 2.6.31. We did
> > not target 2.6.31 for 6000 series enabling and more patches, which are
> > in 2.6.32, are required for 6000 series to work well.
> >
> > Reinette
> >
> Got it, so backport any patch for iwl6000 to 2.6.31-stable is not reasonable.
Bugfixes are fine, but that is not what this is.
Please go read the file, Documentation/stable_kernel_rules.txt to give
you an idea of what we are expecting here.
thanks,
greg k-h