* Re: [PATCH v2] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-09-01 8:05 UTC (permalink / raw)
To: Julian Calaby
Cc: Arnd Hannemann, linux-wireless@vger.kernel.org, joe@perches.com,
proski@gnu.org
In-Reply-To: <646765f40908311754l7bd16185pe21182cdba6e6ac8@mail.gmail.com>
Julian Calaby wrote:
> On Tue, Aug 25, 2009 at 04:51, Arnd
> Hannemann<hannemann@nets.rwth-aachen.de> wrote:
>> An integer overflow in the minstrel debug code prevented the
>> throughput to be displayed correctly. This patch fixes that,
>> by permutating operations like proposed by Pavel Roskin.
>>
>> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
>> ---
>> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
>> index 98f4807..3d72ec5 100644
>> --- a/net/mac80211/rc80211_minstrel_debugfs.c
>> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
>> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
>> p += sprintf(p, "%3u%s", mr->bitrate / 2,
>> (mr->bitrate & 1 ? ".5" : " "));
>>
>> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
>> + tp = mr->cur_tp / ((18000 << 10) / 96);
>
> Sorry about being so late, but wouldn't:
>
> tp = ((mr->cur_tp * 2) / 375) >> 10;
>
> also work? (Assuming that the numbers in the constant aren't important)
I needed a while to figure out why those constants are used, but finally
they made some sense, so I think its best to preserve them.
mr->cur_tp is the time to send one 1200 byte packet (9600 bits),
the loss probelity is scaled between 0-18000 to reduce rounding error.
>
> or even:
>
> tp = (mr->cur_tp / 375) >> 9;
See above.
Best regards,
Arnd
^ permalink raw reply
* [PATCH 18/19] wireless: convert drivers to netdev_tx_t
From: Stephen Hemminger @ 2009-09-01 5:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
In-Reply-To: <20090901055039.824876937@vyatta.com>
Mostly just simple conversions:
* ray_cs had bogus return of NET_TX_LOCKED but driver
was not using NETIF_F_LLTX
* hostap and ipw2x00 had some code that returned value
from a called function that also had to change to return netdev_tx_t
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/wimax/i2400m/netdev.c | 12 ++++++------
drivers/net/wireless/airo.c | 12 +++++++++---
drivers/net/wireless/arlan-main.c | 4 ++--
drivers/net/wireless/atmel.c | 2 +-
drivers/net/wireless/hostap/hostap_80211.h | 10 +++++++---
drivers/net/wireless/hostap/hostap_80211_tx.c | 11 +++++++----
drivers/net/wireless/ipw2x00/ipw2100.c | 10 +++++-----
drivers/net/wireless/ipw2x00/ipw2200.c | 9 +++++----
drivers/net/wireless/ipw2x00/libipw.h | 7 ++++---
drivers/net/wireless/ipw2x00/libipw_tx.c | 6 +++---
drivers/net/wireless/libertas/decl.h | 5 +++--
drivers/net/wireless/libertas/main.c | 3 ++-
drivers/net/wireless/libertas/tx.c | 6 ++----
drivers/net/wireless/mac80211_hwsim.c | 3 ++-
drivers/net/wireless/netwave_cs.c | 6 ++++--
drivers/net/wireless/orinoco/main.c | 2 +-
drivers/net/wireless/prism54/islpci_eth.c | 2 +-
drivers/net/wireless/prism54/islpci_eth.h | 2 +-
drivers/net/wireless/ray_cs.c | 14 +++++++++-----
drivers/net/wireless/strip.c | 2 +-
drivers/net/wireless/wavelan.c | 3 ++-
drivers/net/wireless/wavelan.p.h | 2 +-
drivers/net/wireless/wavelan_cs.c | 2 +-
drivers/net/wireless/wavelan_cs.p.h | 2 +-
drivers/net/wireless/wl3501_cs.c | 3 ++-
drivers/net/wireless/zd1201.c | 3 ++-
net/mac80211/ieee80211_i.h | 6 ++++--
net/mac80211/tx.c | 8 ++++----
28 files changed, 92 insertions(+), 65 deletions(-)
--- a/drivers/net/wireless/hostap/hostap_80211.h 2009-08-31 16:17:52.221080855 -0700
+++ b/drivers/net/wireless/hostap/hostap_80211.h 2009-08-31 16:33:06.481101881 -0700
@@ -3,6 +3,7 @@
#include <linux/types.h>
#include <linux/skbuff.h>
+#include <linux/netdevice.h>
struct hostap_ieee80211_mgmt {
__le16 frame_control;
@@ -85,8 +86,11 @@ void hostap_dump_rx_80211(const char *na
struct hostap_80211_rx_status *rx_stats);
void hostap_dump_tx_80211(const char *name, struct sk_buff *skb);
-int hostap_data_start_xmit(struct sk_buff *skb, struct net_device *dev);
-int hostap_mgmt_start_xmit(struct sk_buff *skb, struct net_device *dev);
-int hostap_master_start_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t hostap_data_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
+netdev_tx_t hostap_mgmt_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
+netdev_tx_t hostap_master_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
#endif /* HOSTAP_80211_H */
--- a/drivers/net/wireless/hostap/hostap_80211_tx.c 2009-08-31 16:17:52.221080855 -0700
+++ b/drivers/net/wireless/hostap/hostap_80211_tx.c 2009-08-31 16:33:42.131158031 -0700
@@ -53,7 +53,8 @@ void hostap_dump_tx_80211(const char *na
/* hard_start_xmit function for data interfaces (wlan#, wlan#wds#, wlan#sta)
* Convert Ethernet header into a suitable IEEE 802.11 header depending on
* device configuration. */
-int hostap_data_start_xmit(struct sk_buff *skb, struct net_device *dev)
+netdev_tx_t hostap_data_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct hostap_interface *iface;
local_info_t *local;
@@ -261,7 +262,8 @@ int hostap_data_start_xmit(struct sk_buf
/* hard_start_xmit function for hostapd wlan#ap interfaces */
-int hostap_mgmt_start_xmit(struct sk_buff *skb, struct net_device *dev)
+netdev_tx_t hostap_mgmt_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct hostap_interface *iface;
local_info_t *local;
@@ -373,11 +375,12 @@ static struct sk_buff * hostap_tx_encryp
/* hard_start_xmit function for master radio interface wifi#.
* AP processing (TX rate control, power save buffering, etc.).
* Use hardware TX function to send the frame. */
-int hostap_master_start_xmit(struct sk_buff *skb, struct net_device *dev)
+netdev_tx_t hostap_master_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct hostap_interface *iface;
local_info_t *local;
- int ret = NETDEV_TX_BUSY;
+ netdev_tx_t ret = NETDEV_TX_BUSY;
u16 fc;
struct hostap_tx_data tx;
ap_tx_ret tx_ret;
--- a/drivers/net/wireless/ipw2x00/ipw2200.c 2009-08-31 16:17:52.321081485 -0700
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c 2009-08-31 16:34:38.021326615 -0700
@@ -10459,12 +10459,12 @@ static void ipw_handle_promiscuous_tx(st
}
#endif
-static int ipw_net_hard_start_xmit(struct libipw_txb *txb,
- struct net_device *dev, int pri)
+static netdev_tx_t ipw_net_hard_start_xmit(struct libipw_txb *txb,
+ struct net_device *dev, int pri)
{
struct ipw_priv *priv = libipw_priv(dev);
unsigned long flags;
- int ret;
+ netdev_tx_t ret;
IPW_DEBUG_TX("dev->xmit(%d bytes)\n", txb->payload_size);
spin_lock_irqsave(&priv->lock, flags);
@@ -11602,7 +11602,8 @@ static int ipw_prom_stop(struct net_devi
return 0;
}
-static int ipw_prom_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ipw_prom_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
IPW_DEBUG_INFO("prom dev->xmit\n");
dev_kfree_skb(skb);
--- a/drivers/net/wireless/ipw2x00/libipw.h 2009-08-31 16:17:52.301107927 -0700
+++ b/drivers/net/wireless/ipw2x00/libipw.h 2009-08-31 16:34:56.121117022 -0700
@@ -867,8 +867,8 @@ struct libipw_device {
/* Callback functions */
void (*set_security) (struct net_device * dev,
struct libipw_security * sec);
- int (*hard_start_xmit) (struct libipw_txb * txb,
- struct net_device * dev, int pri);
+ netdev_tx_t (*hard_start_xmit) (struct libipw_txb * txb,
+ struct net_device * dev, int pri);
int (*reset_port) (struct net_device * dev);
int (*is_queue_full) (struct net_device * dev, int pri);
@@ -1028,7 +1028,8 @@ extern void libipw_networks_age(struct l
extern int libipw_set_encryption(struct libipw_device *ieee);
/* libipw_tx.c */
-extern int libipw_xmit(struct sk_buff *skb, struct net_device *dev);
+extern netdev_tx_t libipw_xmit(struct sk_buff *skb,
+ struct net_device *dev);
extern void libipw_txb_free(struct libipw_txb *);
/* libipw_rx.c */
--- a/drivers/net/wireless/ipw2x00/libipw_tx.c 2009-08-31 16:17:52.301107927 -0700
+++ b/drivers/net/wireless/ipw2x00/libipw_tx.c 2009-08-31 16:35:03.781105301 -0700
@@ -252,7 +252,7 @@ static int libipw_classify(struct sk_buf
/* Incoming skb is converted to a txb which consists of
* a block of 802.11 fragment packets (stored as skbs) */
-int libipw_xmit(struct sk_buff *skb, struct net_device *dev)
+netdev_tx_t libipw_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct libipw_device *ieee = netdev_priv(dev);
struct libipw_txb *txb = NULL;
@@ -523,8 +523,8 @@ int libipw_xmit(struct sk_buff *skb, str
dev_kfree_skb_any(skb);
if (txb) {
- int ret = (*ieee->hard_start_xmit) (txb, dev, priority);
- if (ret == 0) {
+ netdev_tx_t ret = (*ieee->hard_start_xmit)(txb, dev, priority);
+ if (ret == NETDEV_TX_OK) {
dev->stats.tx_packets++;
dev->stats.tx_bytes += txb->payload_size;
return NETDEV_TX_OK;
--- a/drivers/net/wimax/i2400m/netdev.c 2009-08-31 16:17:52.191080883 -0700
+++ b/drivers/net/wimax/i2400m/netdev.c 2009-08-31 16:32:16.163627458 -0700
@@ -334,12 +334,12 @@ int i2400m_net_tx(struct i2400m *i2400m,
* that will sleep. See i2400m_net_wake_tx() for details.
*/
static
-int i2400m_hard_start_xmit(struct sk_buff *skb,
- struct net_device *net_dev)
+netdev_tx_t i2400m_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *net_dev)
{
- int result;
struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
struct device *dev = i2400m_dev(i2400m);
+ int result;
d_fnstart(3, dev, "(skb %p net_dev %p)\n", skb, net_dev);
if (i2400m->state == I2400M_SS_IDLE)
@@ -353,9 +353,9 @@ int i2400m_hard_start_xmit(struct sk_buf
net_dev->stats.tx_bytes += skb->len;
}
kfree_skb(skb);
- result = NETDEV_TX_OK;
- d_fnend(3, dev, "(skb %p net_dev %p) = %d\n", skb, net_dev, result);
- return result;
+
+ d_fnend(3, dev, "(skb %p net_dev %p)\n", skb, net_dev);
+ return NETDEV_TX_OK;
}
--- a/drivers/net/wireless/airo.c 2009-08-31 16:17:52.251122313 -0700
+++ b/drivers/net/wireless/airo.c 2009-08-31 16:32:16.163627458 -0700
@@ -1920,7 +1920,9 @@ static int airo_open(struct net_device *
return 0;
}
-static int mpi_start_xmit(struct sk_buff *skb, struct net_device *dev) {
+static netdev_tx_t mpi_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
int npacks, pending;
unsigned long flags;
struct airo_info *ai = dev->ml_priv;
@@ -2119,7 +2121,9 @@ static void airo_end_xmit(struct net_dev
dev_kfree_skb(skb);
}
-static int airo_start_xmit(struct sk_buff *skb, struct net_device *dev) {
+static netdev_tx_t airo_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
s16 len;
int i, j;
struct airo_info *priv = dev->ml_priv;
@@ -2184,7 +2188,9 @@ static void airo_end_xmit11(struct net_d
dev_kfree_skb(skb);
}
-static int airo_start_xmit11(struct sk_buff *skb, struct net_device *dev) {
+static netdev_tx_t airo_start_xmit11(struct sk_buff *skb,
+ struct net_device *dev)
+{
s16 len;
int i, j;
struct airo_info *priv = dev->ml_priv;
--- a/drivers/net/wireless/arlan-main.c 2009-08-31 16:17:52.201081246 -0700
+++ b/drivers/net/wireless/arlan-main.c 2009-08-31 16:32:16.173591015 -0700
@@ -77,7 +77,7 @@ struct arlan_conf_stru arlan_conf[MAX_AR
static int arlans_found;
static int arlan_open(struct net_device *dev);
-static int arlan_tx(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t arlan_tx(struct sk_buff *skb, struct net_device *dev);
static irqreturn_t arlan_interrupt(int irq, void *dev_id);
static int arlan_close(struct net_device *dev);
static struct net_device_stats *
@@ -1169,7 +1169,7 @@ static void arlan_tx_timeout (struct net
}
-static int arlan_tx(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t arlan_tx(struct sk_buff *skb, struct net_device *dev)
{
short length;
unsigned char *buf;
--- a/drivers/net/wireless/atmel.c 2009-08-31 16:17:52.351091725 -0700
+++ b/drivers/net/wireless/atmel.c 2009-08-31 16:32:16.173591015 -0700
@@ -781,7 +781,7 @@ static void tx_update_descriptor(struct
priv->tx_free_mem -= len;
}
-static int start_tx(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t start_tx(struct sk_buff *skb, struct net_device *dev)
{
static const u8 SNAP_RFC1024[6] = { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };
struct atmel_private *priv = netdev_priv(dev);
--- a/drivers/net/wireless/libertas/decl.h 2009-08-31 16:17:52.281153994 -0700
+++ b/drivers/net/wireless/libertas/decl.h 2009-08-31 16:35:07.071275355 -0700
@@ -6,7 +6,7 @@
#ifndef _LBS_DECL_H_
#define _LBS_DECL_H_
-#include <linux/device.h>
+#include <linux/netdevice.h>
#include "defs.h"
@@ -41,7 +41,8 @@ u8 lbs_data_rate_to_fw_index(u32 rate);
int lbs_process_command_response(struct lbs_private *priv, u8 *data, u32 len);
void lbs_complete_command(struct lbs_private *priv, struct cmd_ctrl_node *cmd,
int result);
-int lbs_hard_start_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t lbs_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
int lbs_set_regiontable(struct lbs_private *priv, u8 region, u8 band);
int lbs_process_rxed_packet(struct lbs_private *priv, struct sk_buff *);
--- a/drivers/net/wireless/libertas/main.c 2009-08-31 16:17:52.291081163 -0700
+++ b/drivers/net/wireless/libertas/main.c 2009-08-31 16:35:10.491118027 -0700
@@ -1647,7 +1647,8 @@ static int lbs_rtap_stop(struct net_devi
return 0;
}
-static int lbs_rtap_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t lbs_rtap_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
netif_stop_queue(dev);
return NETDEV_TX_BUSY;
--- a/drivers/net/wireless/libertas/tx.c 2009-08-31 16:17:52.281153994 -0700
+++ b/drivers/net/wireless/libertas/tx.c 2009-08-31 16:35:15.351107216 -0700
@@ -57,19 +57,17 @@ static u32 convert_radiotap_rate_to_mv(u
* @param skb A pointer to skb which includes TX packet
* @return 0 or -1
*/
-int lbs_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+netdev_tx_t lbs_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
unsigned long flags;
struct lbs_private *priv = dev->ml_priv;
struct txpd *txpd;
char *p802x_hdr;
uint16_t pkt_len;
- int ret;
+ netdev_tx_t ret = NETDEV_TX_OK;
lbs_deb_enter(LBS_DEB_TX);
- ret = NETDEV_TX_OK;
-
/* We need to protect against the queues being restarted before
we get round to stopping them */
spin_lock_irqsave(&priv->driver_lock, flags);
--- a/drivers/net/wireless/mac80211_hwsim.c 2009-08-31 16:17:52.331108249 -0700
+++ b/drivers/net/wireless/mac80211_hwsim.c 2009-08-31 16:32:16.173591015 -0700
@@ -312,7 +312,8 @@ struct hwsim_radiotap_hdr {
} __attribute__ ((packed));
-static int hwsim_mon_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t hwsim_mon_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
/* TODO: allow packet injection */
dev_kfree_skb(skb);
--- a/drivers/net/wireless/netwave_cs.c 2009-08-31 16:17:52.241107004 -0700
+++ b/drivers/net/wireless/netwave_cs.c 2009-08-31 16:32:16.173591015 -0700
@@ -203,7 +203,8 @@ static int netwave_open(struct net_devic
static int netwave_close(struct net_device *dev); /* Close the device */
/* Packet transmission and Packet reception */
-static int netwave_start_xmit( struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t netwave_start_xmit( struct sk_buff *skb,
+ struct net_device *dev);
static int netwave_rx( struct net_device *dev);
/* Interrupt routines */
@@ -1026,7 +1027,8 @@ static int netwave_hw_xmit(unsigned char
return 0;
}
-static int netwave_start_xmit(struct sk_buff *skb, struct net_device *dev) {
+static netdev_tx_t netwave_start_xmit(struct sk_buff *skb,
+ struct net_device *dev) {
/* This flag indicate that the hardware can't perform a transmission.
* Theoritically, NET3 check it before sending a packet to the driver,
* but in fact it never do that and pool continuously.
--- a/drivers/net/wireless/orinoco/main.c 2009-08-31 16:17:52.291081163 -0700
+++ b/drivers/net/wireless/orinoco/main.c 2009-08-31 16:35:20.123589613 -0700
@@ -337,7 +337,7 @@ static int orinoco_change_mtu(struct net
/* Tx path */
/********************************************************************/
-static int orinoco_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t orinoco_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct orinoco_private *priv = ndev_priv(dev);
struct net_device_stats *stats = &priv->stats;
--- a/drivers/net/wireless/prism54/islpci_eth.c 2009-08-31 16:17:52.261081191 -0700
+++ b/drivers/net/wireless/prism54/islpci_eth.c 2009-08-31 16:32:16.173591015 -0700
@@ -72,7 +72,7 @@ islpci_eth_cleanup_transmit(islpci_priva
}
}
-int
+netdev_tx_t
islpci_eth_transmit(struct sk_buff *skb, struct net_device *ndev)
{
islpci_private *priv = netdev_priv(ndev);
--- a/drivers/net/wireless/prism54/islpci_eth.h 2009-08-31 16:17:52.271108094 -0700
+++ b/drivers/net/wireless/prism54/islpci_eth.h 2009-08-31 16:32:16.173591015 -0700
@@ -64,7 +64,7 @@ struct avs_80211_1_header {
};
void islpci_eth_cleanup_transmit(islpci_private *, isl38xx_control_block *);
-int islpci_eth_transmit(struct sk_buff *, struct net_device *);
+netdev_tx_t islpci_eth_transmit(struct sk_buff *, struct net_device *);
int islpci_eth_receive(islpci_private *);
void islpci_eth_tx_timeout(struct net_device *);
void islpci_do_reset_and_wake(struct work_struct *);
--- a/drivers/net/wireless/ray_cs.c 2009-08-31 16:17:52.361105988 -0700
+++ b/drivers/net/wireless/ray_cs.c 2009-08-31 16:32:16.173591015 -0700
@@ -104,7 +104,8 @@ static int ray_dev_init(struct net_devic
static const struct ethtool_ops netdev_ethtool_ops;
static int ray_open(struct net_device *dev);
-static int ray_dev_start_xmit(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t ray_dev_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
static void set_multicast_list(struct net_device *dev);
static void ray_update_multi_list(struct net_device *dev, int all);
static int translate_frame(ray_dev_t *local, struct tx_msg __iomem *ptx,
@@ -915,16 +916,19 @@ static int ray_dev_config(struct net_dev
}
/*===========================================================================*/
-static int ray_dev_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t ray_dev_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
ray_dev_t *local = netdev_priv(dev);
struct pcmcia_device *link = local->finder;
short length = skb->len;
- if (!(pcmcia_dev_present(link))) {
+ if (!pcmcia_dev_present(link)) {
DEBUG(2, "ray_dev_start_xmit - device not present\n");
- return NETDEV_TX_LOCKED;
+ dev_kfree_skb(skb);
+ return NETDEV_TX_OK;
}
+
DEBUG(3, "ray_dev_start_xmit(skb=%p, dev=%p)\n", skb, dev);
if (local->authentication_state == NEED_TO_AUTH) {
DEBUG(0, "ray_cs Sending authentication request.\n");
@@ -951,8 +955,8 @@ static int ray_dev_start_xmit(struct sk_
default:
dev->trans_start = jiffies;
dev_kfree_skb(skb);
- return NETDEV_TX_OK;
}
+
return NETDEV_TX_OK;
} /* ray_dev_start_xmit */
--- a/drivers/net/wireless/strip.c 2009-08-31 16:17:52.201081246 -0700
+++ b/drivers/net/wireless/strip.c 2009-08-31 16:32:16.183606045 -0700
@@ -1533,7 +1533,7 @@ static void strip_send(struct strip *str
}
/* Encapsulate a datagram and kick it into a TTY queue. */
-static int strip_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t strip_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct strip *strip_info = netdev_priv(dev);
--- a/drivers/net/wireless/wavelan.c 2009-08-31 16:17:52.211107939 -0700
+++ b/drivers/net/wireless/wavelan.c 2009-08-31 16:32:16.183606045 -0700
@@ -2841,7 +2841,8 @@ static int wv_packet_write(struct net_de
* the packet. We also prevent reentrance. Then we call the function
* to send the packet.
*/
-static int wavelan_packet_xmit(struct sk_buff *skb, struct net_device * dev)
+static netdev_tx_t wavelan_packet_xmit(struct sk_buff *skb,
+ struct net_device * dev)
{
net_local *lp = netdev_priv(dev);
unsigned long flags;
--- a/drivers/net/wireless/wavelan_cs.c 2009-08-31 16:17:52.231081009 -0700
+++ b/drivers/net/wireless/wavelan_cs.c 2009-08-31 16:32:16.183606045 -0700
@@ -3078,7 +3078,7 @@ wv_packet_write(struct net_device * dev,
* the packet. We also prevent reentrance. Then, we call the function
* to send the packet...
*/
-static int
+static netdev_tx_t
wavelan_packet_xmit(struct sk_buff * skb,
struct net_device * dev)
{
--- a/drivers/net/wireless/wl3501_cs.c 2009-08-31 16:17:52.331108249 -0700
+++ b/drivers/net/wireless/wl3501_cs.c 2009-08-31 16:32:16.183606045 -0700
@@ -1333,7 +1333,8 @@ static void wl3501_tx_timeout(struct net
* 1 - Could not transmit (dev_queue_xmit will queue it)
* and try to sent it later
*/
-static int wl3501_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t wl3501_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
int enabled, rc;
struct wl3501_card *this = netdev_priv(dev);
--- a/drivers/net/wireless/zd1201.c 2009-08-31 16:17:52.341091082 -0700
+++ b/drivers/net/wireless/zd1201.c 2009-08-31 16:32:16.183606045 -0700
@@ -779,7 +779,8 @@ static int zd1201_net_stop(struct net_de
(llc+snap+type+payload)
zd 1 null byte, zd1201 packet type
*/
-static int zd1201_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t zd1201_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct zd1201 *zd = netdev_priv(dev);
unsigned char *txbuf = zd->txdata;
--- a/drivers/net/wireless/wavelan.p.h 2009-08-31 16:17:52.251122313 -0700
+++ b/drivers/net/wireless/wavelan.p.h 2009-08-31 16:32:16.183606045 -0700
@@ -611,7 +611,7 @@ static inline int
wv_packet_write(struct net_device *, /* Write a packet to the Tx buffer. */
void *,
short);
-static int
+static netdev_tx_t
wavelan_packet_xmit(struct sk_buff *, /* Send a packet. */
struct net_device *);
/* -------------------- HARDWARE CONFIGURATION -------------------- */
--- a/drivers/net/wireless/wavelan_cs.p.h 2009-08-31 16:17:52.341091082 -0700
+++ b/drivers/net/wireless/wavelan_cs.p.h 2009-08-31 16:32:16.183606045 -0700
@@ -707,7 +707,7 @@ static void
wv_packet_write(struct net_device *, /* Write a packet to the Tx buffer */
void *,
short);
-static int
+static netdev_tx_t
wavelan_packet_xmit(struct sk_buff *, /* Send a packet */
struct net_device *);
/* -------------------- HARDWARE CONFIGURATION -------------------- */
--- a/drivers/net/wireless/ipw2x00/ipw2100.c 2009-08-31 16:17:52.311180087 -0700
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c 2009-08-31 16:34:41.791081639 -0700
@@ -3330,8 +3330,8 @@ static irqreturn_t ipw2100_interrupt(int
return IRQ_NONE;
}
-static int ipw2100_tx(struct libipw_txb *txb, struct net_device *dev,
- int pri)
+static netdev_tx_t ipw2100_tx(struct libipw_txb *txb,
+ struct net_device *dev, int pri)
{
struct ipw2100_priv *priv = libipw_priv(dev);
struct list_head *element;
@@ -3369,12 +3369,12 @@ static int ipw2100_tx(struct libipw_txb
ipw2100_tx_send_data(priv);
spin_unlock_irqrestore(&priv->low_lock, flags);
- return 0;
+ return NETDEV_TX_OK;
- fail_unlock:
+fail_unlock:
netif_stop_queue(dev);
spin_unlock_irqrestore(&priv->low_lock, flags);
- return 1;
+ return NETDEV_TX_BUSY;
}
static int ipw2100_msg_allocate(struct ipw2100_priv *priv)
--- a/net/mac80211/ieee80211_i.h 2009-08-31 16:17:52.181107339 -0700
+++ b/net/mac80211/ieee80211_i.h 2009-08-31 16:36:09.011107509 -0700
@@ -1050,8 +1050,10 @@ void ieee80211_recalc_idle(struct ieee80
/* tx handling */
void ieee80211_clear_tx_pending(struct ieee80211_local *local);
void ieee80211_tx_pending(unsigned long data);
-int ieee80211_monitor_start_xmit(struct sk_buff *skb, struct net_device *dev);
-int ieee80211_subif_start_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
+netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
+ struct net_device *dev);
/* HT */
void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
--- a/net/mac80211/tx.c 2009-08-31 16:17:52.191080883 -0700
+++ b/net/mac80211/tx.c 2009-08-31 16:36:13.706387007 -0700
@@ -1483,8 +1483,8 @@ static void ieee80211_xmit(struct ieee80
dev_put(sdata->dev);
}
-int ieee80211_monitor_start_xmit(struct sk_buff *skb,
- struct net_device *dev)
+netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
struct ieee80211_channel *chan = local->hw.conf.channel;
@@ -1568,8 +1568,8 @@ fail:
* encapsulated packet will then be passed to master interface, wlan#.11, for
* transmission (through low-level driver).
*/
-int ieee80211_subif_start_xmit(struct sk_buff *skb,
- struct net_device *dev)
+netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = sdata->local;
--
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Zhu Yi @ 2009-09-01 6:33 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Eric Paris, John W. Linville, Eric Paris, Catalin Marinas,
H. Peter Anvin, linux-kernel@vger.kernel.org, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311731h626a5b9bu486653c755cda2fa@mail.gmail.com>
On Tue, 2009-09-01 at 08:31 +0800, Luis R. Rodriguez wrote:
> >>
> http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
> >>
> >> FWIW for that patch:
> >>
> >> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >>
> >> So -- you if you're like me and had issues with bootup lag on
> >> wireless-testing, you can probably fix your wireless-testing by
> >> pulling his patches:
> >>
> >> git pull git://git.infradead.org/users/eparis/notify.git for-linus
> >>
> >> I saw Linus had some other fixes but I'll wait for rc9 for that as
> my
> >> box seems reasonably stable right now.
> >
> > Yes, -rc8 broke pretty badly for a number of people. Linus did pull
> all
> > of the fixes that I know of. I wouldn't suggest pulling just that
> one
> > commit. All 3 of the post -rc8 patches in my tree fix -rc8
> > regressions :(
>
> Thanks, the note -- so I guess best is to just pull from Linus ontop
> of wireless-testing.
I confirm I'm also suffered with the problem on today's wireless-testing
tip (udevadm --settle hangs on boot) and the above patch does fix the
issue for me. Thanks both for identify and fix the problem.
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Jaswinder Singh Rajput @ 2009-09-01 3:57 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Alan Jenkins,
Henrique de Moraes Holschuh, Iñaky Pérez-González,
Ivo van Doorn, Michael Buesch, Tomas Winkler
In-Reply-To: <20090831174542.GA5631@tuxdriver.com>
On Mon, 2009-08-31 at 13:45 -0400, John W. Linville wrote:
> On Wed, Aug 26, 2009 at 06:13:17PM +0200, 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?
>
> Michael? Jaswinder?
>
Acked-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
--
JSR
^ permalink raw reply
* Re: [PATCH] rfkill: relicense header file
From: Jaswinder Singh Rajput @ 2009-09-01 3:49 UTC (permalink / raw)
To: John W. Linville
Cc: Johannes Berg, linux-wireless, Alan Jenkins,
Henrique de Moraes Holschuh, Iñaky Pérez-González,
Ivo van Doorn, Michael Buesch, Tomas Winkler
In-Reply-To: <20090831174542.GA5631@tuxdriver.com>
On Mon, 2009-08-31 at 13:45 -0400, John W. Linville wrote:
> On Wed, Aug 26, 2009 at 06:13:17PM +0200, 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?
>
> Michael? Jaswinder?
>
No Problem, sorry for delay.
Thanks,
--
JSR
^ permalink raw reply
* Re: [PATCH v2] mac80211: Fix output of minstrels rc_stats
From: Julian Calaby @ 2009-09-01 0:54 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-wireless, joe, proski
In-Reply-To: <1251139906-31813-1-git-send-email-hannemann@nets.rwth-aachen.de>
On Tue, Aug 25, 2009 at 04:51, Arnd
Hannemann<hannemann@nets.rwth-aachen.de> wrote:
> An integer overflow in the minstrel debug code prevented the
> throughput to be displayed correctly. This patch fixes that,
> by permutating operations like proposed by Pavel Roskin.
>
> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
> index 98f4807..3d72ec5 100644
> --- a/net/mac80211/rc80211_minstrel_debugfs.c
> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
> p += sprintf(p, "%3u%s", mr->bitrate / 2,
> (mr->bitrate & 1 ? ".5" : " "));
>
> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
> + tp = mr->cur_tp / ((18000 << 10) / 96);
Sorry about being so late, but wouldn't:
tp = ((mr->cur_tp * 2) / 375) >> 10;
also work? (Assuming that the numbers in the constant aren't important)
or even:
tp = (mr->cur_tp / 375) >> 9;
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-09-01 0:31 UTC (permalink / raw)
To: Eric Paris
Cc: John W. Linville, Eric Paris, Catalin Marinas, H. Peter Anvin,
linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <1251764791.2158.7.camel@dhcp231-106.rdu.redhat.com>
On Mon, Aug 31, 2009 at 5:26 PM, Eric Paris<eparis@redhat.com> wrote:
> On Mon, 2009-08-31 at 16:54 -0700, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> > On Mon, Aug 31, 2009 at 12:47 PM, John W.
>> > Linville<linville@tuxdriver.com> wrote:
>> >> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
>> >>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
>> >>> Linville<linville@tuxdriver.com> wrote:
>> >>
>> >>> > My guess is that the culprit is between
>> >>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>> >>>
>> >>> But the issue is *not* in linux-2.6-allstable, it is only present on
>> >>> wireless-testing, and I went as far back as merge-2009-08-28. I was
>> >>> using whatever tag was available prior to you moving to rc8, and that
>> >>> worked.
>> >>
>> >> OK, then I can only guess that something went wrong in your bisection
>> >> (e.g. dirty build, something not marked properly, etc).
>> >
>> > Well so remember I did a clean git clone of wireless-testing and the
>> > issue was still there, but I determined just now it seems rc8 from
>> > Linus does indeed also have the issue. For some reason the issue was
>> > not present on hpa's rc8 on linux-2.6-allstable. Will double check on
>> > that again.
>>
>> OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
>> turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
>> for me.. I tested just one patch and it fixed my bootup lag:
>>
>> http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
>>
>> FWIW for that patch:
>>
>> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>>
>> So -- you if you're like me and had issues with bootup lag on
>> wireless-testing, you can probably fix your wireless-testing by
>> pulling his patches:
>>
>> git pull git://git.infradead.org/users/eparis/notify.git for-linus
>>
>> I saw Linus had some other fixes but I'll wait for rc9 for that as my
>> box seems reasonably stable right now.
>
> Yes, -rc8 broke pretty badly for a number of people. Linus did pull all
> of the fixes that I know of. I wouldn't suggest pulling just that one
> commit. All 3 of the post -rc8 patches in my tree fix -rc8
> regressions :(
Thanks, the note -- so I guess best is to just pull from Linus ontop
of wireless-testing.
Luis
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Eric Paris @ 2009-09-01 0:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Eric Paris, Catalin Marinas, H. Peter Anvin,
linux-kernel, Aneesh Kumar K.V, Greg Kroah-Hartman,
linux-wireless
In-Reply-To: <43e72e890908311654t5d9489d3w9a817cffab5cb8f8@mail.gmail.com>
On Mon, 2009-08-31 at 16:54 -0700, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> > On Mon, Aug 31, 2009 at 12:47 PM, John W.
> > Linville<linville@tuxdriver.com> wrote:
> >> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
> >>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
> >>> Linville<linville@tuxdriver.com> wrote:
> >>
> >>> > My guess is that the culprit is between
> >>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
> >>>
> >>> But the issue is *not* in linux-2.6-allstable, it is only present on
> >>> wireless-testing, and I went as far back as merge-2009-08-28. I was
> >>> using whatever tag was available prior to you moving to rc8, and that
> >>> worked.
> >>
> >> OK, then I can only guess that something went wrong in your bisection
> >> (e.g. dirty build, something not marked properly, etc).
> >
> > Well so remember I did a clean git clone of wireless-testing and the
> > issue was still there, but I determined just now it seems rc8 from
> > Linus does indeed also have the issue. For some reason the issue was
> > not present on hpa's rc8 on linux-2.6-allstable. Will double check on
> > that again.
>
> OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
> turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
> for me.. I tested just one patch and it fixed my bootup lag:
>
> http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
>
> FWIW for that patch:
>
> Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> So -- you if you're like me and had issues with bootup lag on
> wireless-testing, you can probably fix your wireless-testing by
> pulling his patches:
>
> git pull git://git.infradead.org/users/eparis/notify.git for-linus
>
> I saw Linus had some other fixes but I'll wait for rc9 for that as my
> box seems reasonably stable right now.
Yes, -rc8 broke pretty badly for a number of people. Linus did pull all
of the fixes that I know of. I wouldn't suggest pulling just that one
commit. All 3 of the post -rc8 patches in my tree fix -rc8
regressions :(
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Greg KH @ 2009-09-01 0:21 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Gábor Stefanik, John W. Linville, Larry Finger,
Hin-Tak Leung, Tobias Schlemmer, linux-wireless
In-Reply-To: <43e72e890908311656o6f4a4157k6f967dc4934e6dd0@mail.gmail.com>
On Mon, Aug 31, 2009 at 04:56:11PM -0700, Luis R. Rodriguez wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> > On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> >> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> >>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> >>>> Hin-Tak Leung wrote:
> >>>>>
> >>>>> I just took a look at the history - there aren't obvious bug fixes, a
> >>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
> >>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
> >>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
> >>>>> would affect tx level beyond 2.6.31-rc7, I think.
> >>>>
> >>>> Your analysis matches my recollection.
> >>>>
> >>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
> >>>> these days. There are no sources for the B on their web site. In
> >>>> addition, the one that Tobias loaded tainted his kernel.
> >>>>
> >>>> Larry
> >>>
> >>> The driver is not actually closed-source; they just don't provide any
> >>> drivers on their site anymore, instead they send their reference
> >>> drivers to OEMs, expecting the OEMs to release their own versions
> >>> (with sources - most vendors who do release Linux drivers in fact only
> >>> release sources, without binaries). The reason for this appears to be
> >>> that Realtek now encourages vendors to sell RTL81xx wireless chips
> >>> with modified USB IDs. (Or are you seeing a binary-only driver on
> >>> realtek.com.tw? That would definitely be a GPL violation, given that
> >>> they use a modified version of the GPLed libipw stack.)
> >>
> >> Gabor, do you speak to RealkTek folks? It seems what may be best for
> >> OEMs and RealTek themselves is to post drivers for inclusion into
> >> staging first and then for interested parties to port them properly.
> >>
> >> Luis
> >
> > Not yet, I haven't tried contacting them. I simply based my comments
> > on the fact that OEMs are releasing sources. However, contacting them
> > about work to include their drivers in the kernel is a good idea -
> > apparently there is nothing keeping Realtek from taking community
> > contributions (unlike e.g. Zydas - the vendor driver is based on
> > Andrea Merello's old r8180-sa2400 driver, and was not developed
> > in-house by Realtek).
>
> If anyone has contacts that does indeed seem reasonable to do, seems
> like it could help them and their customers.
I do have a few contacts there, and have been trying to work with them
to do this, but it is slow going :(
thanks,
greg k-h
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Inaky Perez-Gonzalez @ 2009-09-01 0:09 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Marcel Holtmann, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311634y5643818ate9d1b28cbbefa2b2@mail.gmail.com>
On Mon, 2009-08-31 at 17:34 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 4:10 PM, Inaky
> Perez-Gonzalez<inaky.perez-gonzalez@intel.com> wrote:
> > On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> >> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> >> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> >> >> Hi Luis,
> >> >>
> >> >>> > OK not so bad except for:
> >> >>> >
> >> >>> > > kernel/net/wimax/wimax.ko
> >> >>> >
> >> >>> > That's touching another subsystem but we could technically merge wimax
> >> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >> >>> > here is to unify anything that uses rfkill for backport usage.
> >> >>>
> >> >>> Oh boy, can of worms
> >> >>>
> >> >>> I have my own compat-wimax already, which already handles things for
> >> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >> >>> heavily used internally.
> >> >>>
> >> >>> I don't really know how much worth it might be and I know I don't have
> >> >>> resources to support both.
> >> >>
> >> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> >> WiMAX. It is really not worth to support it.
> >> >
> >> > Works for me, we then still need to address (if we really care) the
> >> > platform stuff. If someone is interested feel free to send patches to
> >> > add those, I figure as long we get down to the latest supported stable
> >> > kernel it should be good. The latest supported stable kernel is always
> >> > on display on kernel,org, today being 2.6.27.
> >>
> >> BTW inaky -- this is actually up to you, are you wiling to live with
> >> no rfkill for compat?
> >
> > I don't really mind -- but it could be a problem for anyone trying to
> > use it.
>
> Hm sure and there is still also the issue of users of wimax enabled on
> older kernels and using rfkill there. That is, users not using
> compat-wimax but using just compat-wireless and expecting rfkill to
> work smoothly between wimax and compat-wireless.
>
> I am not sure of the details of the platform rfkill drivers or how
> wimax or wireless drivers use these.. Perhaps there are no issues, I
> haven't really cared to look into it.
>
> > Not that I recommend not being able to switch the radio off :)
> > however, the WiMAX stack has APIs for it too, so at least there is a
> > workaround.
>
> You mean a way to rfkill without rfkill?
the wimax_rfkill() call at the end gets at the same point as the rfkill
call to toggle the radio.
> > But remember, I won't be able to support it at all.
>
> To support what specifically?
non-trivial bug reports. I always love to hear them, but I am really up
to my neck. I just don't want to create the wrong expectations from
users.
--
-- Inaky
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 23:56 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John W. Linville, Greg KH, Larry Finger, Hin-Tak Leung,
Tobias Schlemmer, linux-wireless
In-Reply-To: <69e28c910908311646w315bef9eo43d3342c13e38fca@mail.gmail.com>
2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>>> Hin-Tak Leung wrote:
>>>>>
>>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>>
>>>> Your analysis matches my recollection.
>>>>
>>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>>> these days. There are no sources for the B on their web site. In
>>>> addition, the one that Tobias loaded tainted his kernel.
>>>>
>>>> Larry
>>>
>>> The driver is not actually closed-source; they just don't provide any
>>> drivers on their site anymore, instead they send their reference
>>> drivers to OEMs, expecting the OEMs to release their own versions
>>> (with sources - most vendors who do release Linux drivers in fact only
>>> release sources, without binaries). The reason for this appears to be
>>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>>> with modified USB IDs. (Or are you seeing a binary-only driver on
>>> realtek.com.tw? That would definitely be a GPL violation, given that
>>> they use a modified version of the GPLed libipw stack.)
>>
>> Gabor, do you speak to RealkTek folks? It seems what may be best for
>> OEMs and RealTek themselves is to post drivers for inclusion into
>> staging first and then for interested parties to port them properly.
>>
>> Luis
>
> Not yet, I haven't tried contacting them. I simply based my comments
> on the fact that OEMs are releasing sources. However, contacting them
> about work to include their drivers in the kernel is a good idea -
> apparently there is nothing keeping Realtek from taking community
> contributions (unlike e.g. Zydas - the vendor driver is based on
> Andrea Merello's old r8180-sa2400 driver, and was not developed
> in-house by Realtek).
If anyone has contacts that does indeed seem reasonable to do, seems
like it could help them and their customers.
Luis
^ permalink raw reply
* Re: memleaks, acpi + ext4 + tty
From: Luis R. Rodriguez @ 2009-08-31 23:54 UTC (permalink / raw)
To: John W. Linville, Eric Paris
Cc: Catalin Marinas, H. Peter Anvin, linux-kernel, Aneesh Kumar K.V,
Greg Kroah-Hartman, linux-wireless
In-Reply-To: <43e72e890908311302s58743978wd8950f167a871cfb@mail.gmail.com>
On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 12:47 PM, John W.
> Linville<linville@tuxdriver.com> wrote:
>> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
>>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
>>> Linville<linville@tuxdriver.com> wrote:
>>
>>> > My guess is that the culprit is between
>>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>>>
>>> But the issue is *not* in linux-2.6-allstable, it is only present on
>>> wireless-testing, and I went as far back as merge-2009-08-28. I was
>>> using whatever tag was available prior to you moving to rc8, and that
>>> worked.
>>
>> OK, then I can only guess that something went wrong in your bisection
>> (e.g. dirty build, something not marked properly, etc).
>
> Well so remember I did a clean git clone of wireless-testing and the
> issue was still there, but I determined just now it seems rc8 from
> Linus does indeed also have the issue. For some reason the issue was
> not present on hpa's rc8 on linux-2.6-allstable. Will double check on
> that again.
OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
for me.. I tested just one patch and it fixed my bootup lag:
http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
FWIW for that patch:
Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
So -- you if you're like me and had issues with bootup lag on
wireless-testing, you can probably fix your wireless-testing by
pulling his patches:
git pull git://git.infradead.org/users/eparis/notify.git for-linus
I saw Linus had some other fixes but I'll wait for rc9 for that as my
box seems reasonably stable right now.
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Gábor Stefanik @ 2009-08-31 23:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Greg KH, Larry Finger, Hin-Tak Leung,
Tobias Schlemmer, linux-wireless
In-Reply-To: <43e72e890908311637r7b079e9fj2ac6b77f2b59eb79@mail.gmail.com>
On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>> Hin-Tak Leung wrote:
>>>>
>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>
>>> Your analysis matches my recollection.
>>>
>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>> these days. There are no sources for the B on their web site. In
>>> addition, the one that Tobias loaded tainted his kernel.
>>>
>>> Larry
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
> Gabor, do you speak to RealkTek folks? It seems what may be best for
> OEMs and RealTek themselves is to post drivers for inclusion into
> staging first and then for interested parties to port them properly.
>
> Luis
Not yet, I haven't tried contacting them. I simply based my comments
on the fact that OEMs are releasing sources. However, contacting them
about work to include their drivers in the kernel is a good idea -
apparently there is nothing keeping Realtek from taking community
contributions (unlike e.g. Zydas - the vendor driver is based on
Andrea Merello's old r8180-sa2400 driver, and was not developed
in-house by Realtek).
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Luis R. Rodriguez @ 2009-08-31 23:37 UTC (permalink / raw)
To: Gábor Stefanik, John W. Linville, Greg KH
Cc: Larry Finger, Hin-Tak Leung, Tobias Schlemmer, linux-wireless
In-Reply-To: <69e28c910908311418l7f033b5bp7a9b443cd253304@mail.gmail.com>
2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>> Hin-Tak Leung wrote:
>>>
>>> I just took a look at the history - there aren't obvious bug fixes, a
>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>> would affect tx level beyond 2.6.31-rc7, I think.
>>
>> Your analysis matches my recollection.
>>
>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>> these days. There are no sources for the B on their web site. In
>> addition, the one that Tobias loaded tainted his kernel.
>>
>> Larry
>
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)
Gabor, do you speak to RealkTek folks? It seems what may be best for
OEMs and RealTek themselves is to post drivers for inclusion into
staging first and then for interested parties to port them properly.
Luis
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 23:34 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: Marcel Holtmann, Hin-Tak Leung, linux-wireless
In-Reply-To: <1251760232.5165.28.camel@localhost.localdomain>
On Mon, Aug 31, 2009 at 4:10 PM, Inaky
Perez-Gonzalez<inaky.perez-gonzalez@intel.com> wrote:
> On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
>> >> Hi Luis,
>> >>
>> >>> > OK not so bad except for:
>> >>> >
>> >>> > > kernel/net/wimax/wimax.ko
>> >>> >
>> >>> > That's touching another subsystem but we could technically merge wimax
>> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
>> >>> > here is to unify anything that uses rfkill for backport usage.
>> >>>
>> >>> Oh boy, can of worms
>> >>>
>> >>> I have my own compat-wimax already, which already handles things for
>> >>> backwards compat (many #ifdef hacks to simplify life) and which is
>> >>> heavily used internally.
>> >>>
>> >>> I don't really know how much worth it might be and I know I don't have
>> >>> resources to support both.
>> >>
>> >> for the wireless-compat tree, I would just remove the RFKILL support for
>> >> WiMAX. It is really not worth to support it.
>> >
>> > Works for me, we then still need to address (if we really care) the
>> > platform stuff. If someone is interested feel free to send patches to
>> > add those, I figure as long we get down to the latest supported stable
>> > kernel it should be good. The latest supported stable kernel is always
>> > on display on kernel,org, today being 2.6.27.
>>
>> BTW inaky -- this is actually up to you, are you wiling to live with
>> no rfkill for compat?
>
> I don't really mind -- but it could be a problem for anyone trying to
> use it.
Hm sure and there is still also the issue of users of wimax enabled on
older kernels and using rfkill there. That is, users not using
compat-wimax but using just compat-wireless and expecting rfkill to
work smoothly between wimax and compat-wireless.
I am not sure of the details of the platform rfkill drivers or how
wimax or wireless drivers use these.. Perhaps there are no issues, I
haven't really cared to look into it.
> Not that I recommend not being able to switch the radio off :)
> however, the WiMAX stack has APIs for it too, so at least there is a
> workaround.
You mean a way to rfkill without rfkill?
> But remember, I won't be able to support it at all.
To support what specifically?
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Hin-Tak Leung @ 2009-08-31 23:16 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, Luis R. Rodriguez, Tobias Schlemmer,
linux-wireless
In-Reply-To: <4A9C42C5.6050400@lwfinger.net>
2009/8/31 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
>
> No driver at all. I looked at the Toshiba site, but found only Windows
> drivers. Which OEM has the driver available?
>
> Larry
The r8187 is distributed from OEMs - stand to reason, as realtek don't
really sell their own brand on high-street shops? We got one release
e-mailed to us, and there are a few floating around on the internet
under some laptop or usb hardware vendors. It is available under this,
for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
r8187mesh is the one in the mesh directory.
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4)
From: Gábor Stefanik @ 2009-08-31 23:11 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Michael Buesch, Leonardo H. Souza Hamada, linux-wireless
In-Reply-To: <3ace41890908311602g4a976ec5k4f1f5145662cf183@mail.gmail.com>
(Restoring CCs from original message.)
2009/9/1 Hin-Tak Leung <hintak.leung@gmail.com>:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Mon, Aug 31, 2009 at 9:35 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Mon, Aug 31, 2009 at 8:27 PM, Michael Buesch<mb@bu3sch.de> wrote:
>>>> On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
>>>>> It would appear that the rw driver's ieee80211->mac80211 conversion
>>>>> has broken big- endian platforms, at a first guess.
>>>>
>>>> Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
>>>> But that's maybe two or three release cycles in the past.
>>>>
>>>> --
>>>> Greetings, Michael.
>>>>
>>>
>>> The rw ieee80211->mac80211 conversion happens in 2.6.27->26.28 ...
>>> Iguess the question is whether it was 2.6.28 or 2.6.27 you had success
>>> with? That's unfortunately two *and* three cycles in the past,
>>> respectively :-).
>>
>> I seem to remember that the conversion happened between 2.6.24 and
>> 2.6.25 - the 2.6.26 injection patch on patches.aircrack-ng.org is also
>> clearly for the mac80211 version.
>
> Some part persists till 2.6.28 - I was running git diff between
> different tags like this:
>
> git diff v2.6.27:drivers/net/wireless/zd1211rw/
> v2.6.28:drivers/net/wireless/zd1211rw/
> diff --git a/Makefile b/Makefile
> index cc36126..1907eaf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,6 @@
> obj-$(CONFIG_ZD1211RW) += zd1211rw.o
>
> -zd1211rw-objs := zd_chip.o zd_ieee80211.o zd_mac.o \
> +zd1211rw-objs := zd_chip.o zd_mac.o \
> zd_rf_al2230.o zd_rf_rf2959.o \
> zd_rf_al7230b.o zd_rf_uw2453.o \
> zd_rf.o zd_usb.o
> diff --git a/zd_chip.c b/zd_chip.c
> index 0acb5c3..e0ac58b 100644
> --- a/zd_chip.c
> +++ b/zd_chip.c
> @@ -28,7 +28,6 @@
>
> #include "zd_def.h"
> #include "zd_chip.h"
> -#include "zd_ieee80211.h"
> #include "zd_mac.h"
> #include "zd_rf.h"
>
AFAIK that was a cleanup from the changeover to mac80211 - originally,
zd_ieee80211 housed the bindings to ieee80211softmac. After the
conversion to mac80211, some mac80211 bindings ended up in zd_mac, the
others in zd_ieee80211. In 2.6.28, the two files were merged.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Inaky Perez-Gonzalez @ 2009-08-31 23:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Marcel Holtmann, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311605m368f3703vfd8a25694e69072e@mail.gmail.com>
On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> >> Hi Luis,
> >>
> >>> > OK not so bad except for:
> >>> >
> >>> > > kernel/net/wimax/wimax.ko
> >>> >
> >>> > That's touching another subsystem but we could technically merge wimax
> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >>> > here is to unify anything that uses rfkill for backport usage.
> >>>
> >>> Oh boy, can of worms
> >>>
> >>> I have my own compat-wimax already, which already handles things for
> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >>> heavily used internally.
> >>>
> >>> I don't really know how much worth it might be and I know I don't have
> >>> resources to support both.
> >>
> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> WiMAX. It is really not worth to support it.
> >
> > Works for me, we then still need to address (if we really care) the
> > platform stuff. If someone is interested feel free to send patches to
> > add those, I figure as long we get down to the latest supported stable
> > kernel it should be good. The latest supported stable kernel is always
> > on display on kernel,org, today being 2.6.27.
>
> BTW inaky -- this is actually up to you, are you wiling to live with
> no rfkill for compat?
I don't really mind -- but it could be a problem for anyone trying to
use it. Not that I recommend not being able to switch the radio off :)
however, the WiMAX stack has APIs for it too, so at least there is a
workaround.
But remember, I won't be able to support it at all.
--
-- Inaky
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 23:05 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Inaky Perez-Gonzalez, Hin-Tak Leung, linux-wireless
In-Reply-To: <43e72e890908311445q60c703a3ha8ef8e599e3e712@mail.gmail.com>
On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
>> Hi Luis,
>>
>>> > OK not so bad except for:
>>> >
>>> > > kernel/net/wimax/wimax.ko
>>> >
>>> > That's touching another subsystem but we could technically merge wimax
>>> > into compat-wireless if Inaky thinks that's a good idea. the point
>>> > here is to unify anything that uses rfkill for backport usage.
>>>
>>> Oh boy, can of worms
>>>
>>> I have my own compat-wimax already, which already handles things for
>>> backwards compat (many #ifdef hacks to simplify life) and which is
>>> heavily used internally.
>>>
>>> I don't really know how much worth it might be and I know I don't have
>>> resources to support both.
>>
>> for the wireless-compat tree, I would just remove the RFKILL support for
>> WiMAX. It is really not worth to support it.
>
> Works for me, we then still need to address (if we really care) the
> platform stuff. If someone is interested feel free to send patches to
> add those, I figure as long we get down to the latest supported stable
> kernel it should be good. The latest supported stable kernel is always
> on display on kernel,org, today being 2.6.27.
BTW inaky -- this is actually up to you, are you wiling to live with
no rfkill for compat?
Luis
^ permalink raw reply
* Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)
From: Luis R. Rodriguez @ 2009-08-31 21:45 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Inaky Perez-Gonzalez, Hin-Tak Leung, linux-wireless
In-Reply-To: <1251751251.1266.16.camel@localhost.localdomain>
On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> Hi Luis,
>
>> > OK not so bad except for:
>> >
>> > > kernel/net/wimax/wimax.ko
>> >
>> > That's touching another subsystem but we could technically merge wimax
>> > into compat-wireless if Inaky thinks that's a good idea. the point
>> > here is to unify anything that uses rfkill for backport usage.
>>
>> Oh boy, can of worms
>>
>> I have my own compat-wimax already, which already handles things for
>> backwards compat (many #ifdef hacks to simplify life) and which is
>> heavily used internally.
>>
>> I don't really know how much worth it might be and I know I don't have
>> resources to support both.
>
> for the wireless-compat tree, I would just remove the RFKILL support for
> WiMAX. It is really not worth to support it.
Works for me, we then still need to address (if we really care) the
platform stuff. If someone is interested feel free to send patches to
add those, I figure as long we get down to the latest supported stable
kernel it should be good. The latest supported stable kernel is always
on display on kernel,org, today being 2.6.27.
Luis
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Larry Finger @ 2009-08-31 21:38 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Hin-Tak Leung, Luis R. Rodriguez, Tobias Schlemmer,
linux-wireless
In-Reply-To: <69e28c910908311418l7f033b5bp7a9b443cd253304@mail.gmail.com>
Gábor Stefanik wrote:
>
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)
No driver at all. I looked at the Toshiba site, but found only Windows
drivers. Which OEM has the driver available?
Larry
^ permalink raw reply
* Re: [PATCH] ar9170: added phy register initialisation from eeprom values
From: Christian Lamparter @ 2009-08-31 21:37 UTC (permalink / raw)
To: Joerg Albert
Cc: John W. Linville, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <4A9C25AE.9020109@gmx.de>
(changed cc', web.de finally pissed me off with a 500 mail quota)
2009/8/31 Joerg Albert <jal2@gmx.de>:
> On 08/31/2009 11:53 AM, Chunkeey@web.de wrote:
>> ...
>> See Documentation/CodingStyle - Chapter 8
>>
>> The preferred style for long (multi-line) comments is:
>> /*
>> * look up a certain register in ar5416_phy_init[] and return the init. value
>> * for the band and bandwidth given. Return 0 if register address not found.
>> */
>> ...
>
> Thanks for the comments. I agree with all of them and will re-spin a patch.
Great!
>> It's amazing how much **** you can _cut_ from the vendor driver.
>
> Yes, at first sight it looks really complex but it isn't.
well, there's still a thing... we can only copy what's there in driver,
But since the two-stage fw is capable of reinitializing
the rf/phy we could do all sorts of stuff without breaking it.
>> BTW: does this patch help the 1-stage fw stability, or is it still broken?
>
> Turned out I had a corrupt firmware file. After downloading from Luis' URL it works fine
> with my WNDA3100. Guess I had an earlier version from before 2009/05/28 or firefox
> corrupted it during download.
>
> What's your setup to get 80+ MBit/s throughput with the two-stage firmware?
simply another 11n card a few meters away (but in the same room of course,
since the 5GHz band doesn't like to go through concrete)
I tested a few configurations and only with a rt2860pci was able to get a
satisfying result over a small distance (7 m, but still in the same room ;) )
Other cards: like the ar5416 also worked, but not that well (tx rates halved)
and iwl4965, iwl5300 didn't work at all in n. (but they're flying with 11a)
> I've used an 802.11g AP so far, but have access to an 802.11n dual-band AP now.
> Guess I should use 5GHz as 2.4 is rather crowded here.
> How can I put ar9170 into 802.11n/40MHz mode?
well you need a patch which lets you use the MCS rates and
kicks off BlockAck sessions. I posted a version some time
ago, (AFAIK initial RFC?). However due to fact that the code belongs
into the rc-algorithm and the lack of "out-house testing" feedback,
I had to drop it. I can send you an _updated_ (well, it should apply without
fuzz... but you still have to select the MCS by hand) version if you want,
however not until Friday. Of course, If you have free time on your hand,
you could do the fix-ups by yourself and start the madNess right on! ;-)
(Note: Felix is looking into minstrel/HT. I expect once the code is
available, that we only have to patch ar9170 just a _little_ bit to get
it _sort of_ working.
(it might never probably work with the current available firmwares,
since the BA tx_status is totally bogus)
Regards,
Chr
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Gábor Stefanik @ 2009-08-31 21:18 UTC (permalink / raw)
To: Larry Finger
Cc: Hin-Tak Leung, Luis R. Rodriguez, Tobias Schlemmer,
linux-wireless
In-Reply-To: <4A9C3C59.5010305@lwfinger.net>
On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
>>
>> I just took a look at the history - there aren't obvious bug fixes, a
>> bunch of work queue-related changes from you & Johannes; feature-wise,
>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>> would affect tx level beyond 2.6.31-rc7, I think.
>
> Your analysis matches my recollection.
>
> Apparently RealTek is supplying a closed-source driver for RTL8187B
> these days. There are no sources for the B on their web site. In
> addition, the one that Tobias loaded tainted his kernel.
>
> Larry
The driver is not actually closed-source; they just don't provide any
drivers on their site anymore, instead they send their reference
drivers to OEMs, expecting the OEMs to release their own versions
(with sources - most vendors who do release Linux drivers in fact only
release sources, without binaries). The reason for this appears to be
that Realtek now encourages vendors to sell RTL81xx wireless chips
with modified USB IDs. (Or are you seeing a binary-only driver on
realtek.com.tw? That would definitely be a GPL violation, given that
they use a modified version of the GPLed libipw stack.)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: rtl8187b Problem with tx level
From: Larry Finger @ 2009-08-31 21:10 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, Tobias Schlemmer, linux-wireless
In-Reply-To: <3ace41890908311157v4fbc9829j6db9c91ef6fff3c7@mail.gmail.com>
Hin-Tak Leung wrote:
>
> I just took a look at the history - there aren't obvious bug fixes, a
> bunch of work queue-related changes from you & Johannes; feature-wise,
> Larry added LED blinking after 2.6.30, and Herton added rfkill support
> quite recently after 2.6.31-rc7 . But no, there isn't any change that
> would affect tx level beyond 2.6.31-rc7, I think.
Your analysis matches my recollection.
Apparently RealTek is supplying a closed-source driver for RTL8187B
these days. There are no sources for the B on their web site. In
addition, the one that Tobias loaded tainted his kernel.
Larry
^ permalink raw reply
* Test message, please ignore.
From: Gábor Stefanik @ 2009-08-31 21:01 UTC (permalink / raw)
To: linux-wireless, Broadcom Wireless, linux-kernel
I suspect that this will trigger a response from a spambot.
reset
^ 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