* Re: [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Bob Copeland @ 2009-08-27 3:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
On Wed, Aug 26, 2009 at 10:30 PM, Pavel Roskin<proski@gnu.org> wrote:
> The `val' variable in ath5k_eeprom_read_turbo_modes() is used
> uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
> it:
>
> eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
> eeprom.c:441: warning: 'val' may be used uninitialized in this function
Thanks!
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 4/4] ath5k: add hardware CCMP encyption support
From: Bob Copeland @ 2009-08-27 3:27 UTC (permalink / raw)
To: Pavel Roskin
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <1251338971.17295.17.camel@mj>
On Wed, Aug 26, 2009 at 10:09:31PM -0400, Pavel Roskin wrote:
> On Mon, 2009-08-24 at 23:00 -0400, Bob Copeland wrote:
> > + ah->ah_aes_support =
> > + (ee->ee_version >= AR5K_EEPROM_VERSION_5_0 &&
> > + !AR5K_EEPROM_AES_DIS(ee->ee_misc5) &&
> > + (ah->ah_mac_version > (AR5K_SREV_AR5212 >> 4) ||
> > + (ah->ah_mac_version == (AR5K_SREV_AR5212 >> 4) &&
> > + ah->ah_mac_revision >= (AR5K_SREV_AR5211 >> 4))));
>
> The above use of ah->ah_mac_revision is clearly incorrect. You are
> comparing a revision with a symbol for a version.
Well, this is exactly what legacy-hal does... so blame atheros :)
But yeah, we can just change it to look directly at the mac srev
since the revision check is confusing and the whole thing is needlessly
complex.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Congratulations
From: Larry Finger @ 2009-08-27 2:55 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <69e28c910908261922p5ee551aeobd535fc2ceb2a814@mail.gmail.com>
Gábor Stefanik wrote:
> 2009/8/27 Larry Finger <Larry.Finger@lwfinger.net>:
>> Gábor,
>>
>> Congratulations on your progress. With today's patches my BCM4312
>> 802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
>> moment. I'm using WPA2 encryption and have connected to APs on
>> channels 1 and 11. My logs are clean.
>
> That's good to hear!
>
>> As you noted, performance is a little weak, but I get transmits of
>> 9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
>
> What is your actual RX throughput? For me, it's usable up to 24Mb/s,
> but the actual throughput is limited to 1.2Mb/s.
That 18 Mb/s receive rate was observed data transfer from my server
that is wired to the router/AP and over the air to the BCM4312, just
as the 11 Mb/s was observed transfer from the BCM4312 to the server. I
have no idea what bit rate was set into the interface. Every time I
looked, it was at 1 Mb/s, but the throughput is better than that.
--snip--
>> For those of you with N PHYs, the RE of those devices will be my next
>> step.
>
> My next step will be calibration. :-)
>
> (However, calibration specs are still not complete - there are 2 wlc_*
> calls in PR41573. But that only matters for rev.0, and apparently all
> 4312s are rev.1.)
I missed those (obviously). Are there any other places in the LP PHY
that need work?
Larry
^ permalink raw reply
* [PATCH 2/2] ath5k: don't use PCI ID to find the chip revision
From: Pavel Roskin @ 2009-08-27 2:30 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <20090827023000.21926.90867.stgit@mj.roinet.com>
AR5K_SREV is available even if the chip has been put to sleep. Relying
on the chip register allows binding non-standard PCI IDs by
echo VENDOR_ID PRODUCT_ID >/sys/bus/pci/drivers/ath5k/new_id
without having to specify the driver data as well.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath5k/attach.c | 14 +++++++----
drivers/net/wireless/ath/ath5k/base.c | 38 ++++++++++++++++---------------
3 files changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index cdc79cd..c2d4c6a 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1159,7 +1159,7 @@ struct ath5k_hw {
*/
/* Attach/Detach Functions */
-extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version);
+extern struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc);
extern void ath5k_hw_detach(struct ath5k_hw *ah);
/* LED functions */
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index 109ab7b..0d789ef 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -95,14 +95,13 @@ static int ath5k_hw_post(struct ath5k_hw *ah)
* ath5k_hw_attach - Check if hw is supported and init the needed structs
*
* @sc: The &struct ath5k_softc we got from the driver's attach function
- * @mac_version: The mac version id (check out ath5k.h) based on pci id
*
* Check if the device is supported, perform a POST and initialize the needed
* structs. Returns -ENOMEM if we don't have memory for the needed structs,
* -ENODEV if the device is not supported or prints an error msg if something
* else went wrong.
*/
-struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
+struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc)
{
struct ath5k_hw *ah;
struct pci_dev *pdev = sc->pdev;
@@ -136,9 +135,15 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
ah->ah_software_retry = false;
/*
- * Set the mac version based on the pci id
+ * Find the mac version
*/
- ah->ah_version = mac_version;
+ srev = ath5k_hw_reg_read(ah, AR5K_SREV);
+ if (srev < AR5K_SREV_AR5311)
+ ah->ah_version = AR5K_AR5210;
+ else if (srev < AR5K_SREV_AR5212)
+ ah->ah_version = AR5K_AR5211;
+ else
+ ah->ah_version = AR5K_AR5212;
/*Fill the ath5k_hw struct with the needed functions*/
ret = ath5k_hw_init_desc_functions(ah);
@@ -151,7 +156,6 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
goto err_free;
/* Get MAC, PHY and RADIO revisions */
- srev = ath5k_hw_reg_read(ah, AR5K_SREV);
ah->ah_mac_srev = srev;
ah->ah_mac_version = AR5K_REG_MS(srev, AR5K_SREV_VER);
ah->ah_mac_revision = AR5K_REG_MS(srev, AR5K_SREV_REV);
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 94d46fd..9c6ab53 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -84,24 +84,24 @@ MODULE_VERSION("0.6.0 (EXPERIMENTAL)");
/* Known PCI ids */
static const struct pci_device_id ath5k_pci_id_table[] = {
- { PCI_VDEVICE(ATHEROS, 0x0207), .driver_data = AR5K_AR5210 }, /* 5210 early */
- { PCI_VDEVICE(ATHEROS, 0x0007), .driver_data = AR5K_AR5210 }, /* 5210 */
- { PCI_VDEVICE(ATHEROS, 0x0011), .driver_data = AR5K_AR5211 }, /* 5311 - this is on AHB bus !*/
- { PCI_VDEVICE(ATHEROS, 0x0012), .driver_data = AR5K_AR5211 }, /* 5211 */
- { PCI_VDEVICE(ATHEROS, 0x0013), .driver_data = AR5K_AR5212 }, /* 5212 */
- { PCI_VDEVICE(3COM_2, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 5212 */
- { PCI_VDEVICE(3COM, 0x0013), .driver_data = AR5K_AR5212 }, /* 3com 3CRDAG675 5212 */
- { PCI_VDEVICE(ATHEROS, 0x1014), .driver_data = AR5K_AR5212 }, /* IBM minipci 5212 */
- { PCI_VDEVICE(ATHEROS, 0x0014), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0015), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0016), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0017), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0018), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x0019), .driver_data = AR5K_AR5212 }, /* 5212 combatible */
- { PCI_VDEVICE(ATHEROS, 0x001a), .driver_data = AR5K_AR5212 }, /* 2413 Griffin-lite */
- { PCI_VDEVICE(ATHEROS, 0x001b), .driver_data = AR5K_AR5212 }, /* 5413 Eagle */
- { PCI_VDEVICE(ATHEROS, 0x001c), .driver_data = AR5K_AR5212 }, /* PCI-E cards */
- { PCI_VDEVICE(ATHEROS, 0x001d), .driver_data = AR5K_AR5212 }, /* 2417 Nala */
+ { PCI_VDEVICE(ATHEROS, 0x0207) }, /* 5210 early */
+ { PCI_VDEVICE(ATHEROS, 0x0007) }, /* 5210 */
+ { PCI_VDEVICE(ATHEROS, 0x0011) }, /* 5311 - this is on AHB bus !*/
+ { PCI_VDEVICE(ATHEROS, 0x0012) }, /* 5211 */
+ { PCI_VDEVICE(ATHEROS, 0x0013) }, /* 5212 */
+ { PCI_VDEVICE(3COM_2, 0x0013) }, /* 3com 5212 */
+ { PCI_VDEVICE(3COM, 0x0013) }, /* 3com 3CRDAG675 5212 */
+ { PCI_VDEVICE(ATHEROS, 0x1014) }, /* IBM minipci 5212 */
+ { PCI_VDEVICE(ATHEROS, 0x0014) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0015) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0016) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0017) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0018) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x0019) }, /* 5212 combatible */
+ { PCI_VDEVICE(ATHEROS, 0x001a) }, /* 2413 Griffin-lite */
+ { PCI_VDEVICE(ATHEROS, 0x001b) }, /* 5413 Eagle */
+ { PCI_VDEVICE(ATHEROS, 0x001c) }, /* PCI-E cards */
+ { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
{ 0 }
};
MODULE_DEVICE_TABLE(pci, ath5k_pci_id_table);
@@ -566,7 +566,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
}
/* Initialize device */
- sc->ah = ath5k_hw_attach(sc, id->driver_data);
+ sc->ah = ath5k_hw_attach(sc);
if (IS_ERR(sc->ah)) {
ret = PTR_ERR(sc->ah);
goto err_irq;
^ permalink raw reply related
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Gábor Stefanik @ 2009-08-27 2:29 UTC (permalink / raw)
To: Andrey Yurovsky
Cc: Richard Farina, Hin-Tak Leung, Larry Finger, John W Linville,
Herton Ronaldo Krzesinski, Hin-Tak Leung, linux-wireless
In-Reply-To: <45e8e6c40908261903r1e495ee6tb69277d99aa83e2b@mail.gmail.com>
On Thu, Aug 27, 2009 at 4:03 AM, Andrey Yurovsky<andrey@cozybit.com> wrote:
> Hi Richard,
>
> On Wed, Aug 26, 2009 at 4:11 PM, Richard Farina<sidhayn@gmail.com> wrote:
>> Again, I'm not trying to point my finger blaming someone, I'm trying to help
>> fix a problem. I am traveling for the next few days, when I get home to my
>> camera I hope you are all calm enough to help me troubleshoot this bug so we
>> can find a solution instead of accusing each other of accusing each other.
>
> you may want to try kexec in place of having to take photos of the
> kernel panic output. This will enable you to load a crash-recovery
> kernel, which will be booted automatically once you've successfully
> reproduced the problem. From there you can use gdb together with
> /proc/vmcore and your kernel image to reconstruct what you'd see in
> dmesg and paste the entire oops. Please see
> Documentation/kdump/kdump.txt for more details and use
> Documentation/kdump/gdbmacros.txt to give gdb a "dmesg" macro.
Or use the "crash" utility (a wrapper for gdb), which can directly
extract the kernel log from vmcore.
>
> -Andrey
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 1/2] ath5k: fix uninitialized value use in ath5k_eeprom_read_turbo_modes()
From: Pavel Roskin @ 2009-08-27 2:30 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, John W. Linville
The `val' variable in ath5k_eeprom_read_turbo_modes() is used
uninitialized. gcc 4.4.1 with -fno-inline-functions-called-once reports
it:
eeprom.c: In function 'ath5k_eeprom_read_turbo_modes':
eeprom.c:441: warning: 'val' may be used uninitialized in this function
Comparing the code to the Atheros HAL, it's clear that the split between
ath5k_eeprom_read_modes() and ath5k_eeprom_read_turbo_modes() was
incorrect.
The Atheros HAL reads both turbo and non-turbo data from EEPROM in one
function. Some turbo mode parameters are derived from the same EEPROM
values as non-turbo parameters, just from different bits.
Merge ath5k_eeprom_read_turbo_modes() into ath5k_eeprom_read_modes() to
fix the warning. The actual values and offsets have been cross-checked
against Atheros HAL.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath5k/eeprom.c | 29 +++++------------------------
1 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.c b/drivers/net/wireless/ath/ath5k/eeprom.c
index 8af477d..644962a 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath/ath5k/eeprom.c
@@ -414,27 +414,11 @@ static int ath5k_eeprom_read_modes(struct ath5k_hw *ah, u32 *offset,
break;
}
-done:
- /* return new offset */
- *offset = o;
-
- return 0;
-}
-
-/*
- * Read turbo mode information on newer EEPROM versions
- */
-static int
-ath5k_eeprom_read_turbo_modes(struct ath5k_hw *ah,
- u32 *offset, unsigned int mode)
-{
- struct ath5k_eeprom_info *ee = &ah->ah_capabilities.cap_eeprom;
- u32 o = *offset;
- u16 val;
- int ret;
-
+ /*
+ * Read turbo mode information on newer EEPROM versions
+ */
if (ee->ee_version < AR5K_EEPROM_VERSION_5_0)
- return 0;
+ goto done;
switch (mode){
case AR5K_EEPROM_MODE_11A:
@@ -468,6 +452,7 @@ ath5k_eeprom_read_turbo_modes(struct ath5k_hw *ah,
break;
}
+done:
/* return new offset */
*offset = o;
@@ -504,10 +489,6 @@ ath5k_eeprom_init_modes(struct ath5k_hw *ah)
ret = ath5k_eeprom_read_modes(ah, &offset, mode);
if (ret)
return ret;
-
- ret = ath5k_eeprom_read_turbo_modes(ah, &offset, mode);
- if (ret)
- return ret;
}
/* override for older eeprom versions for better performance */
^ permalink raw reply related
* Re: Congratulations
From: Gábor Stefanik @ 2009-08-27 2:22 UTC (permalink / raw)
To: Larry Finger
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <4A95D2A8.9090208@lwfinger.net>
2009/8/27 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor,
>
> Congratulations on your progress. With today's patches my BCM4312
> 802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
> moment. I'm using WPA2 encryption and have connected to APs on
> channels 1 and 11. My logs are clean.
That's good to hear!
>
> As you noted, performance is a little weak, but I get transmits of
> 9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
What is your actual RX throughput? For me, it's usable up to 24Mb/s,
but the actual throughput is limited to 1.2Mb/s.
>
> I certainly hope that you get the patches approved so that these
> changes will be in the 2.6.32 kernel.
The patches are already in the tree, actually.
>
> Once again, congratulations to you, Michael, and the others members of
> the reverse engineering team. Seeing the device comes to life makes
> all those hours of staring at MIPS binary code seem very worthwhile.
>
> For those of you with N PHYs, the RE of those devices will be my next
> step.
My next step will be calibration. :-)
(However, calibration specs are still not complete - there are 2 wlc_*
calls in PR41573. But that only matters for rev.0, and apparently all
4312s are rev.1.)
>
> Larry
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 4/4] ath5k: add hardware CCMP encyption support
From: Pavel Roskin @ 2009-08-27 2:09 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, jirislaby, mickflemm, lrodriguez, linux-wireless,
ath5k-devel
In-Reply-To: <1251169233-24169-5-git-send-email-me@bobcopeland.com>
On Mon, 2009-08-24 at 23:00 -0400, Bob Copeland wrote:
> + ah->ah_aes_support =
> + (ee->ee_version >= AR5K_EEPROM_VERSION_5_0 &&
> + !AR5K_EEPROM_AES_DIS(ee->ee_misc5) &&
> + (ah->ah_mac_version > (AR5K_SREV_AR5212 >> 4) ||
> + (ah->ah_mac_version == (AR5K_SREV_AR5212 >> 4) &&
> + ah->ah_mac_revision >= (AR5K_SREV_AR5211 >> 4))));
The above use of ah->ah_mac_revision is clearly incorrect. You are
comparing a revision with a symbol for a version.
I suggest that you use ah_mac_srev instead. Before this patch,
ah_mac_revision was a write-only variable and was a good candidate for
removal.
The last three quoted lines are equivalent to (ah->ah_mac_srev >= 0x54)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Andrey Yurovsky @ 2009-08-27 2:03 UTC (permalink / raw)
To: Richard Farina
Cc: Hin-Tak Leung, Larry Finger, John W Linville,
Herton Ronaldo Krzesinski, Hin-Tak Leung, linux-wireless
In-Reply-To: <4A95C128.5000405@gmail.com>
Hi Richard,
On Wed, Aug 26, 2009 at 4:11 PM, Richard Farina<sidhayn@gmail.com> wrote:
> Again, I'm not trying to point my finger blaming someone, I'm trying to help
> fix a problem. I am traveling for the next few days, when I get home to my
> camera I hope you are all calm enough to help me troubleshoot this bug so we
> can find a solution instead of accusing each other of accusing each other.
you may want to try kexec in place of having to take photos of the
kernel panic output. This will enable you to load a crash-recovery
kernel, which will be booted automatically once you've successfully
reproduced the problem. From there you can use gdb together with
/proc/vmcore and your kernel image to reconstruct what you'd see in
dmesg and paste the entire oops. Please see
Documentation/kdump/kdump.txt for more details and use
Documentation/kdump/gdbmacros.txt to give gdb a "dmesg" macro.
-Andrey
^ permalink raw reply
* Congratulations
From: Larry Finger @ 2009-08-27 0:26 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Mark Huijgen, Broadcom Wireless,
linux-wireless
In-Reply-To: <1251323178-7173-1-git-send-email-netrolller.3d@gmail.com>
Gábor,
Congratulations on your progress. With today's patches my BCM4312
802.11b/g card with PCI ID 14e4:4315 works - I'm using it at the
moment. I'm using WPA2 encryption and have connected to APs on
channels 1 and 11. My logs are clean.
As you noted, performance is a little weak, but I get transmits of
9-11 Mb/s and receive rates up to 18 Mb/s - eminently usable.
I certainly hope that you get the patches approved so that these
changes will be in the 2.6.32 kernel.
Once again, congratulations to you, Michael, and the others members of
the reverse engineering team. Seeing the device comes to life makes
all those hours of staring at MIPS binary code seem very worthwhile.
For those of you with N PHYs, the RE of those devices will be my next
step.
Larry
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-27 0:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <43e72e890908261645n24a040cds84f012095a40c15b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Thu, Aug 27, 2009 at 12:45 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
2.6.30 has /sys/class/rfkill (it is exposed by the vendor as-shipped
rfkill.ko). But I just tried something like this, and it seems to work
- the patch is simple enough and just 3 hunks - what it does:
1) 'make unload' should unload rfkill also,
2) remove the compat-wireless class renaming hunk (so it advertise
itself as 'rfkill' rather than 'rfkill_backport')
3) remove the compat-wireless input hander renaming hunk.
I am not sure what the input handle->name (3) is for, somebody care to
explain? Is there any reason why I should do something like outlined
here in the patch?
Hin-Tak
[-- Attachment #2: compat-wireless_remove_backport_naming.diff --]
[-- Type: text/x-patch, Size: 1765 bytes --]
diff --git a/compat/patches/03-rfkill.patch b/compat/patches/03-rfkill.patch
index 61eb762..368767f 100644
--- a/compat/patches/03-rfkill.patch
+++ b/compat/patches/03-rfkill.patch
@@ -34,15 +34,6 @@ just keep /dev/rfkill and not /dev/rfkill_backport.
#include <linux/sched.h>
#include "rfkill.h"
-@@ -229,7 +233,7 @@ static int rfkill_connect(struct input_h
-
- handle->dev = dev;
- handle->handler = handler;
-- handle->name = "rfkill";
-+ handle->name = "rfkill_backport";
-
- /* causes rfkill_start() to be called */
- error = input_register_handle(handle);
--- a/net/rfkill/core.c 2009-08-20 13:48:36.083267397 -0700
+++ b/net/rfkill/core.c 2009-08-20 13:48:37.051267098 -0700
@@ -26,7 +26,7 @@
@@ -81,15 +72,6 @@ just keep /dev/rfkill and not /dev/rfkill_backport.
static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
/**
-@@ -776,7 +776,7 @@
- }
-
- static struct class rfkill_class = {
-- .name = "rfkill",
-+ .name = "rfkill_backport",
- .dev_release = rfkill_release,
- .dev_attrs = rfkill_dev_attrs,
- .dev_uevent = rfkill_dev_uevent,
@@ -922,7 +922,7 @@
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
diff --git a/scripts/unload.sh b/scripts/unload.sh
index 75bbfc9..0537056 100755
--- a/scripts/unload.sh
+++ b/scripts/unload.sh
@@ -25,6 +25,7 @@ MODULES="$MODULES rndis_wlan rndis_host cdc_ether usbnet"
# eeprom_93cx6 is used by rt2x00 (rt61pci, rt2500pci, rt2400pci)
# and Realtek drivers ( rtl8187, rtl8180)
MODULES="$MODULES eeprom_93cx6"
+MODULES="$MODULES rfkill"
MODULES="$MODULES lib80211_crypt_ccmp lib80211_crypt_tkip lib80211_crypt_wep"
MODULES="$MODULES mac80211 cfg80211 lib80211"
MADWIFI_MODULES="ath_pci ath_rate_sample wlan_scan_sta wlan ath_hal"
^ permalink raw reply related
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-26 23:45 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908261555g339e65d1n6627cc3d1713287e@mail.gmail.com>
On Wed, Aug 26, 2009 at 3:55 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 11:28 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> (added list hal to To:, since it has become relevant; previous
>>> exchanges of the thread on linux-wireless)
>>>
>>> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>>>>
>>>>>> > Or wait ... are you using compat-wireless?
>>>>>>
>>>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>>>>> in /sys/class is important.
>>>>>
>>>>> Sorry, didn't see.
>>>>>
>>>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>>>>> some compat*.h but obviously the kernel won't ever call that notifier,
>>>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>>>>> handle that -- it'll be working fine in a regular tree.
>>>>>
>>>>> Luis, the only way to handle that would be to manually call the PRE_UP
>>>>> notifier from mac80211's subif_open() and if that returns an error
>>>>> (warning: the calling convention is weird) return the error... that's
>>>>> weird but would work.
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> Hmm, got a bit side-tracked. But hal doesn't know the device having a
>>>> killswitch is still wrong somewhere?
>>>> (i.e. am wondering where we should advertise that ability, or how hal
>>>> works that out)
>>>>
>>>> Hin-Tak
>>>>
>>>
>>> I looked into hal and I can now say that it is certainly not
>>> compat-wireless "rfkill_backport"-aware; apparently all it does is
>>> monitoring entries under /sys/class that it knows about. I made a
>>> quick hack:
>>
>> This is wrong, we just do not need to use rfkill_backport for sysfs
>> stuff, consider sending me patch that removes that hunk for
>> compat-wireless instead and test it.
>>
>> Luis
>>
>
> Hmm, I did mention the other option - make rfkill_backport exposes its
> data structure as '/sys/class/rfkill' instead of
> '/sys/class/rfkill_backport'. Is there any reason why
> compat-wireless's rfkill_backport does not called itself 'rfkill' and
> unload and replace the old rfkill? That would be much neater, and
> userland tools like hal won't need to know anything about
> compat-wireless.
Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Richard Farina @ 2009-08-26 23:11 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Larry Finger, John W Linville, Herton Ronaldo Krzesinski,
Hin-Tak Leung, linux-wireless
In-Reply-To: <3ace41890908261538s6818b56ax56cca5af18398dbc@mail.gmail.com>
Hin-Tak Leung wrote:
> On Wed, Aug 26, 2009 at 10:34 PM, Richard Farina<sidhayn@gmail.com> wrote:
>
>
>> I apologize if you thought there was an accusation here, that certainly was
>> not my intention. With all due respect assuming that I'm
>> a jerk is neither safe nor polite. In your original patch for this I find
>> the following text:
>>
>
>
>> Yes, I realize that, which is why I said the "bug is still alive" not "the
>> patch is not applied". I even went out of my way to describe how the
>> testing was different...
>>
>
> While I thought Larry's reply was a bit brief, I looked back on the
> thread and I think I am on Larry's side. All you mentioned was that
> you had a crash on unplug, and then you automatically assume that it
> is because the most recent crash-related fix (which Larry kindly made)
> did not work. You have no proof that your problem is even the same as
> what the fix tried to solve. You did not try to go back to a non-LED
> enabled compat-wireless, for example.
>
> To be honest, I think you 'went out of your way' to try to pin your
> problem on one of the developers, so that your problem is guaranteed
> to receive attention. That's not very fair...
>
> That said, I think this thread has gone on long enough - all that
> happened is that (1) you had a crash on unplug, (2) you tried to pin
> it on Larry, (3) many people has checked and verified that what Larry
> did went in, (4) we still don't know whether your crash is related to
> the LED change or not.
>
> Since we still don't know whether your crash is related to any
> LED-related change or not, this thread is not going well.
>
>
I accept your criticism. I should have been more clear. This happens
only when CONFIG_RTL8187_LEDS=y is set.
I'm not trying to "pin" the bug on Larry claiming it is his fault, I'm
merely stating that I am experiencing a problem that looks extremely
similar to what he described when he pushed the mentioned patch.
Again, I'm not trying to point my finger blaming someone, I'm trying to
help fix a problem. I am traveling for the next few days, when I get
home to my camera I hope you are all calm enough to help me troubleshoot
this bug so we can find a solution instead of accusing each other of
accusing each other.
My apologies for any perceived insults against anyone, seriously, that's
not my goal here.
-Rick
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Henrique de Moraes Holschuh @ 2009-08-26 23:10 UTC (permalink / raw)
To: Johannes Berg
Cc: John Linville, linux-wireless, Alan Jenkins,
Iñaky Pérez-González, Ivo van Doorn,
Jaswinder Singh Rajput, Michael Buesch, Tomas Winkler
In-Reply-To: <1251303197.15619.29.camel@johannes.local>
On Wed, 26 Aug 2009, Johannes Berg wrote:
> This header file is copied into userspace tools that
> need not be GPLv2 licensed, make that easier.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Cc: Iñaky Pérez-González <inaky.perez-gonzalez@intel.com>
> Cc: Ivo van Doorn <IvDoorn@gmail.com>
> Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: Michael Buesch <mb@bu3sch.de>
> Cc: Tomas Winkler <tomas.winkler@intel.com>
> ---
> Need ACK from everybody listed who ever touched this
> file according to git. Please?
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> include/linux/rfkill.h | 25 +++++++++++--------------
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> --- wireless-testing.orig/include/linux/rfkill.h 2009-08-26 18:09:57.000000000 +0200
> +++ wireless-testing/include/linux/rfkill.h 2009-08-26 18:10:52.000000000 +0200
> @@ -6,20 +6,17 @@
> * Copyright (C) 2007 Dmitry Torokhov
> * Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
> *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the
> - * Free Software Foundation, Inc.,
> - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
>
> #include <linux/types.h>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-26 22:55 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <43e72e890908261528m23b8fe78w209e305f27e68fa1@mail.gmail.com>
On Wed, Aug 26, 2009 at 11:28 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> (added list hal to To:, since it has become relevant; previous
>> exchanges of the thread on linux-wireless)
>>
>> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>>>
>>>>> > Or wait ... are you using compat-wireless?
>>>>>
>>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>>>> in /sys/class is important.
>>>>
>>>> Sorry, didn't see.
>>>>
>>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>>>> some compat*.h but obviously the kernel won't ever call that notifier,
>>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>>>> handle that -- it'll be working fine in a regular tree.
>>>>
>>>> Luis, the only way to handle that would be to manually call the PRE_UP
>>>> notifier from mac80211's subif_open() and if that returns an error
>>>> (warning: the calling convention is weird) return the error... that's
>>>> weird but would work.
>>>>
>>>> johannes
>>>>
>>>
>>> Hmm, got a bit side-tracked. But hal doesn't know the device having a
>>> killswitch is still wrong somewhere?
>>> (i.e. am wondering where we should advertise that ability, or how hal
>>> works that out)
>>>
>>> Hin-Tak
>>>
>>
>> I looked into hal and I can now say that it is certainly not
>> compat-wireless "rfkill_backport"-aware; apparently all it does is
>> monitoring entries under /sys/class that it knows about. I made a
>> quick hack:
>
> This is wrong, we just do not need to use rfkill_backport for sysfs
> stuff, consider sending me patch that removes that hunk for
> compat-wireless instead and test it.
>
> Luis
>
Hmm, I did mention the other option - make rfkill_backport exposes its
data structure as '/sys/class/rfkill' instead of
'/sys/class/rfkill_backport'. Is there any reason why
compat-wireless's rfkill_backport does not called itself 'rfkill' and
unload and replace the old rfkill? That would be much neater, and
userland tools like hal won't need to know anything about
compat-wireless.
Hin-Tak
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Luis R. Rodriguez @ 2009-08-26 22:46 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <1251325824.20531.1.camel@johannes.local>
On Wed, Aug 26, 2009 at 3:30 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 15:26 -0700, Luis R. Rodriguez wrote:
>
>> I was thinking of the case where someone hit rfkill between dev_open()
>> and mac80211's subif_open() but I am either not sure if this is
>> possible.
>
> Oh, but that's ok -- we'll set the interface down again very quickly
> after. Besides, you could be in subif_open() already while hitting it,
> somewhere in driver initialisation...
>
>> If there is a real value to adding it to mac80211 then we wouldn't
>> need to tug around a hunk for it on compat.
>
> I don't see any value in it.
OK -- then someone interested can add the hunk to compat.
Luis
^ permalink raw reply
* Re: [PATCH] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Hin-Tak Leung @ 2009-08-26 22:38 UTC (permalink / raw)
To: Richard Farina
Cc: Larry Finger, John W Linville, Herton Ronaldo Krzesinski,
Hin-Tak Leung, linux-wireless
In-Reply-To: <4A95AA64.20502@gmail.com>
On Wed, Aug 26, 2009 at 10:34 PM, Richard Farina<sidhayn@gmail.com> wrote:
> I apologize if you thought there was an accusation here, that certainly was
> not my intention. With all due respect assuming that I'm
> a jerk is neither safe nor polite. In your original patch for this I find
> the following text:
> Yes, I realize that, which is why I said the "bug is still alive" not "the
> patch is not applied". I even went out of my way to describe how the
> testing was different...
While I thought Larry's reply was a bit brief, I looked back on the
thread and I think I am on Larry's side. All you mentioned was that
you had a crash on unplug, and then you automatically assume that it
is because the most recent crash-related fix (which Larry kindly made)
did not work. You have no proof that your problem is even the same as
what the fix tried to solve. You did not try to go back to a non-LED
enabled compat-wireless, for example.
To be honest, I think you 'went out of your way' to try to pin your
problem on one of the developers, so that your problem is guaranteed
to receive attention. That's not very fair...
That said, I think this thread has gone on long enough - all that
happened is that (1) you had a crash on unplug, (2) you tried to pin
it on Larry, (3) many people has checked and verified that what Larry
did went in, (4) we still don't know whether your crash is related to
the LED change or not.
Since we still don't know whether your crash is related to any
LED-related change or not, this thread is not going well.
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Johannes Berg @ 2009-08-26 22:30 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <43e72e890908261526g538eea56l873314e576331449@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On Wed, 2009-08-26 at 15:26 -0700, Luis R. Rodriguez wrote:
> I was thinking of the case where someone hit rfkill between dev_open()
> and mac80211's subif_open() but I am either not sure if this is
> possible.
Oh, but that's ok -- we'll set the interface down again very quickly
after. Besides, you could be in subif_open() already while hitting it,
somewhere in driver initialisation...
> If there is a real value to adding it to mac80211 then we wouldn't
> need to tug around a hunk for it on compat.
I don't see any value in it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-26 22:28 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Johannes Berg, hal, htl10, Larry Finger,
Herton Ronaldo Krzesinski, linux-wireless
In-Reply-To: <3ace41890908261511i3056c049kca82831015ff2aa0@mail.gmail.com>
On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> (added list hal to To:, since it has become relevant; previous
> exchanges of the thread on linux-wireless)
>
> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>>
>>>> > Or wait ... are you using compat-wireless?
>>>>
>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>>> in /sys/class is important.
>>>
>>> Sorry, didn't see.
>>>
>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>>> some compat*.h but obviously the kernel won't ever call that notifier,
>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>>> handle that -- it'll be working fine in a regular tree.
>>>
>>> Luis, the only way to handle that would be to manually call the PRE_UP
>>> notifier from mac80211's subif_open() and if that returns an error
>>> (warning: the calling convention is weird) return the error... that's
>>> weird but would work.
>>>
>>> johannes
>>>
>>
>> Hmm, got a bit side-tracked. But hal doesn't know the device having a
>> killswitch is still wrong somewhere?
>> (i.e. am wondering where we should advertise that ability, or how hal
>> works that out)
>>
>> Hin-Tak
>>
>
> I looked into hal and I can now say that it is certainly not
> compat-wireless "rfkill_backport"-aware; apparently all it does is
> monitoring entries under /sys/class that it knows about. I made a
> quick hack:
This is wrong, we just do not need to use rfkill_backport for sysfs
stuff, consider sending me patch that removes that hunk for
compat-wireless instead and test it.
Luis
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Luis R. Rodriguez @ 2009-08-26 22:26 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <1251324755.20531.0.camel@johannes.local>
On Wed, Aug 26, 2009 at 3:12 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-26 at 15:06 -0700, Luis R. Rodriguez wrote:
>
>> > Neat, thanks. Not sure if I'll get to this this anytime soon, but if
>> > someone is interested in it please give it a shot and send a patch.
>> > That would be nice.
>>
>> What if we *also* just do that from mac80211 as well upstream?
>
> Why?
I was thinking of the case where someone hit rfkill between dev_open()
and mac80211's subif_open() but I am either not sure if this is
possible.
> It's fine as it is, and we don't want to clutter all cfg80211
> drivers with it.
If there is a real value to adding it to mac80211 then we wouldn't
need to tug around a hunk for it on compat.
Luis
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Johannes Berg @ 2009-08-26 22:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <43e72e890908261506h6b9ec4efq2d190388663d4671@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Wed, 2009-08-26 at 15:06 -0700, Luis R. Rodriguez wrote:
> > Neat, thanks. Not sure if I'll get to this this anytime soon, but if
> > someone is interested in it please give it a shot and send a patch.
> > That would be nice.
>
> What if we *also* just do that from mac80211 as well upstream?
Why? It's fine as it is, and we don't want to clutter all cfg80211
drivers with it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Hin-Tak Leung @ 2009-08-26 22:11 UTC (permalink / raw)
To: Johannes Berg, hal
Cc: htl10, Larry Finger, Herton Ronaldo Krzesinski, linux-wireless,
Luis R. Rodriguez
(added list hal to To:, since it has become relevant; previous
exchanges of the thread on linux-wireless)
On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>
>>> > Or wait ... are you using compat-wireless?
>>>
>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>> in /sys/class is important.
>>
>> Sorry, didn't see.
>>
>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>> some compat*.h but obviously the kernel won't ever call that notifier,
>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>> handle that -- it'll be working fine in a regular tree.
>>
>> Luis, the only way to handle that would be to manually call the PRE_UP
>> notifier from mac80211's subif_open() and if that returns an error
>> (warning: the calling convention is weird) return the error... that's
>> weird but would work.
>>
>> johannes
>>
>
> Hmm, got a bit side-tracked. But hal doesn't know the device having a
> killswitch is still wrong somewhere?
> (i.e. am wondering where we should advertise that ability, or how hal
> works that out)
>
> Hin-Tak
>
I looked into hal and I can now say that it is certainly not
compat-wireless "rfkill_backport"-aware; apparently all it does is
monitoring entries under /sys/class that it knows about. I made a
quick hack:
-----------
diff --git a/hald/linux/device.c b/hald/linux/device.c
index 2eca1ef..61e94b7 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -4621,7 +4621,7 @@ static DevHandler dev_handler_power_supply =
static DevHandler dev_handler_rfkill =
{
- .subsystem = "rfkill",
+ .subsystem = "rfkill_backport",
.add = rfkill_add,
.compute_udi = rfkill_compute_udi,
.refresh = rfkill_refresh,
-----------------
so that it looks for /sys/class/rfkill_backport instead of rfkill ,
and restarting hald, and lshal finally shows the killswitch. And
NetworkManager also becomes aware of the rfkill state and no longer
re-enable the device:
---------------
Aug 26 22:08:36 localhost NetworkManager: <info> HAL disappeared
.
Aug 26 22:08:43 localhost NetworkManager: <info> HAL re-appeared
Aug 26 22:08:43 localhost NetworkManager: <info> Found radio
killswitch /org/freedesktop/Hal/devices/usb_device_bda_8197_00e04c000001_if0_rfkill_phy0_wlan
Aug 26 22:09:16 localhost kernel: rtl8187: wireless radio switch turned off
Aug 26 22:09:20 localhost NetworkManager: <info> Wireless now
disabled by radio killswitch
.
Aug 26 22:13:21 localhost kernel: rtl8187: wireless radio switch turned on
Aug 26 22:13:27 localhost NetworkManager: <info> Wireless now enabled
by radio killswitch
-------------
So, to summarise, from 2.6.31 onwards, cfg80211 should enforce the
rfkill state from within the kernel no matter what hal/NM does; on
non-bleeding edge systems, hal works out rfkill states from
'/sys/class/rfkill' and let NM know. if you have a non-bleeding edge
system but want to try compat-wireless anyway, hal simply doesn't know
about rfkill_backport and NM re-enables the device when one plays with
the rfkill switch.
I guess there are two ways to go about this:
(1) make compat-wireless unload and replace the as-shipped rfkill
module completely and populate /sys/class/rfkill .
(2) make hal monitor and treat /sys/class/rfkill_backport the same way
and in addition to /sys/class/rfkill .
So I went about (2) and just duplicated the rfkill entry like this,
and it seems to work - anybody from hal wants to take this in?
--------------
diff --git a/hald/linux/device.c b/hald/linux/device.c
index 2eca1ef..feb198e 100644
--- a/hald/linux/device.c
+++ b/hald/linux/device.c
@@ -4628,6 +4628,15 @@ static DevHandler dev_handler_rfkill =
.remove = dev_remove
};
+static DevHandler dev_handler_rfkill_backport =
+{
+ .subsystem = "rfkill_backport",
+ .add = rfkill_add,
+ .compute_udi = rfkill_compute_udi,
+ .refresh = rfkill_refresh,
+ .remove = dev_remove
+};
+
static DevHandler dev_handler_scsi = {
.subsystem = "scsi",
.add = scsi_add,
@@ -4817,6 +4826,7 @@ static DevHandler *dev_handlers[] = {
&dev_handler_ps3_system_bus,
&dev_handler_pseudo,
&dev_handler_rfkill,
+ &dev_handler_rfkill_backport,
&dev_handler_scsi,
&dev_handler_scsi_generic,
&dev_handler_scsi_host,
------------------------------
^ permalink raw reply related
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Luis R. Rodriguez @ 2009-08-26 22:06 UTC (permalink / raw)
To: Johannes Berg
Cc: htl10, Hin-Tak Leung, Larry Finger, Herton Ronaldo Krzesinski,
linux-wireless
In-Reply-To: <43e72e890908261333m1d576fdhaa16088affec5426@mail.gmail.com>
On Wed, Aug 26, 2009 at 1:33 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Wed, Aug 26, 2009 at 7:34 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote:
>>
>>> > Or wait ... are you using compat-wireless?
>>>
>>> Yes, I am. I mentioned this and did wonder if the _backport/ part
>>> in /sys/class is important.
>>
>> Sorry, didn't see.
>>
>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to
>> some compat*.h but obviously the kernel won't ever call that notifier,
>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to
>> handle that -- it'll be working fine in a regular tree.
>>
>> Luis, the only way to handle that would be to manually call the PRE_UP
>> notifier from mac80211's subif_open() and if that returns an error
>> (warning: the calling convention is weird) return the error... that's
>> weird but would work.
>
> Neat, thanks. Not sure if I'll get to this this anytime soon, but if
> someone is interested in it please give it a shot and send a patch.
> That would be nice.
What if we *also* just do that from mac80211 as well upstream?
Luis
^ permalink raw reply
* [PATCH v3] b43: LP-PHY: Revert to the original PHY register write routine
From: Gábor Stefanik @ 2009-08-26 21:46 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
After some discussion on IRC about the PHY register write change,
I am not sure anymore if this is the right thing to do.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
v3: Use 16-bit writes.
drivers/net/wireless/b43/phy_lp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 80f245c..a57c40d 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
{
- b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
+ b43_write16(dev, B43_MMIO_PHY_CONTROL, reg);
+ b43_write16(dev, B43_MMIO_PHY_DATA, value);
}
static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
--
1.5.6
^ permalink raw reply related
* [PATCH v2] b43: LP-PHY: Revert to the original PHY register write routine
From: Gábor Stefanik @ 2009-08-26 21:45 UTC (permalink / raw)
To: John Linville, Michael Buesch, Larry Finger, Mark Huijgen
Cc: Broadcom Wireless, linux-wireless
After some discussion on IRC about the PHY register write change,
I am not sure anymore if this is the right thing to do.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
v2: No more "From: root".
drivers/net/wireless/b43/phy_lp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 80f245c..a57c40d 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -1496,7 +1496,8 @@ static u16 b43_lpphy_op_read(struct b43_wldev *dev, u16 reg)
static void b43_lpphy_op_write(struct b43_wldev *dev, u16 reg, u16 value)
{
- b43_write32(dev, B43_MMIO_PHY_CONTROL, ((u32)value << 16) | reg);
+ b43_write32(dev, B43_MMIO_PHY_CONTROL, reg);
+ b43_write32(dev, B43_MMIO_PHY_DATA, value);
}
static void b43_lpphy_op_maskset(struct b43_wldev *dev, u16 reg, u16 mask,
--
1.5.6
^ permalink raw reply related
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