Add AD-HOC support to the rtl8187 based on the rtl8180 source
Signed-off-by: Attila Fazekas <[email protected]>
---
diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c
b/drivers/net/wireless/rtl818x/rtl8187/dev.c
index 638fbef..f8f9186 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
@@ -232,6 +232,7 @@ static void rtl8187_tx(struct ieee80211_hw *dev,
struct sk_buff *skb)
{
struct rtl8187_priv *priv = dev->priv;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_hdr *tx_hdr = (struct ieee80211_hdr *)(skb->data);
unsigned int ep;
void *buf;
struct urb *urb;
@@ -249,7 +250,7 @@ static void rtl8187_tx(struct ieee80211_hw *dev,
struct sk_buff *skb)
flags |= RTL818X_TX_DESC_FLAG_NO_ENC;
flags |= ieee80211_get_tx_rate(dev, info)->hw_value << 24;
- if (ieee80211_has_morefrags(((struct ieee80211_hdr
*)skb->data)->frame_control))
+ if (ieee80211_has_morefrags(tx_hdr->frame_control))
flags |= RTL818X_TX_DESC_FLAG_MOREFRAG;
if (info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) {
flags |= RTL818X_TX_DESC_FLAG_RTS;
@@ -261,6 +262,13 @@ static void rtl8187_tx(struct ieee80211_hw *dev,
struct sk_buff *skb)
flags |= ieee80211_get_rts_cts_rate(dev, info)->hw_value << 19;
}
+ if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ) {
+ if (info->flags & IEEE80211_TX_CTL_FIRST_FRAGMENT)
+ priv->seqno += 0x10;
+ tx_hdr->seq_ctrl &= cpu_to_le16(IEEE80211_SCTL_FRAG);
+ tx_hdr->seq_ctrl |= cpu_to_le16(priv->seqno);
+ }
+
if (!priv->is_rtl8187b) {
struct rtl8187_tx_hdr *hdr =
(struct rtl8187_tx_hdr *)skb_push(skb, sizeof(*hdr));
@@ -274,8 +282,6 @@ static void rtl8187_tx(struct ieee80211_hw *dev,
struct sk_buff *skb)
} else {
/* fc needs to be calculated before skb_push() */
unsigned int epmap[4] = { 6, 7, 5, 4 };
- struct ieee80211_hdr *tx_hdr =
- (struct ieee80211_hdr *)(skb->data);
u16 fc = le16_to_cpu(tx_hdr->frame_control);
struct rtl8187b_tx_hdr *hdr =
@@ -1031,10 +1037,61 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
cancel_delayed_work_sync(&priv->work);
}
+static u64 rtl8187_get_tsf(struct ieee80211_hw *dev, struct ieee80211_vif *vif)
+{
+ struct rtl8187_priv *priv = dev->priv;
+
+ return rtl818x_ioread32(priv, &priv->map->TSFT[0]) |
+ (u64)(rtl818x_ioread32(priv, &priv->map->TSFT[1])) << 32;
+}
+
+
+static void rtl8187_beacon_work(struct work_struct *work)
+{
+ struct rtl8187_vif *vif_priv =
+ container_of(work, struct rtl8187_vif, beacon_work.work);
+ struct ieee80211_vif *vif =
+ container_of((void *)vif_priv, struct ieee80211_vif, drv_priv);
+ struct ieee80211_hw *dev = vif_priv->dev;
+ struct ieee80211_mgmt *mgmt;
+ struct sk_buff *skb;
+
+ /* don't overflow the tx ring */
+ if (ieee80211_queue_stopped(dev, 0))
+ goto resched;
+
+ /* grab a fresh beacon */
+ skb = ieee80211_beacon_get(dev, vif);
+ if (!skb)
+ goto resched;
+
+ /*
+ * update beacon timestamp w/ TSF value
+ * TODO: make hardware update beacon timestamp
+ */
+ mgmt = (struct ieee80211_mgmt *)skb->data;
+ mgmt->u.beacon.timestamp = cpu_to_le64(rtl8187_get_tsf(dev, vif));
+
+ /* TODO: use actual beacon queue */
+ skb_set_queue_mapping(skb, 0);
+
+ rtl8187_tx(dev, skb);
+
+resched:
+ /*
+ * schedule next beacon
+ * TODO: use hardware support for beacon timing
+ */
+ schedule_delayed_work(&vif_priv->beacon_work,
+ usecs_to_jiffies(1024 * vif->bss_conf.beacon_int));
+}
+
+
static int rtl8187_add_interface(struct ieee80211_hw *dev,
struct ieee80211_vif *vif)
{
struct rtl8187_priv *priv = dev->priv;
+ struct rtl8187_vif *vif_priv;
int i;
int ret = -EOPNOTSUPP;
@@ -1044,6 +1101,7 @@ static int rtl8187_add_interface(struct ieee80211_hw *dev,
switch (vif->type) {
case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_ADHOC:
break;
default:
goto exit;
@@ -1052,6 +1110,13 @@ static int rtl8187_add_interface(struct
ieee80211_hw *dev,
ret = 0;
priv->vif = vif;
+ /* Initialize driver private area */
+ vif_priv = (struct rtl8187_vif *)&vif->drv_priv;
+ vif_priv->dev = dev;
+ INIT_DELAYED_WORK(&vif_priv->beacon_work, rtl8187_beacon_work);
+ vif_priv->enable_beacon = false;
+
+
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
for (i = 0; i < ETH_ALEN; i++)
rtl818x_iowrite8(priv, &priv->map->MAC[i],
@@ -1175,9 +1240,12 @@ static void rtl8187_bss_info_changed(struct
ieee80211_hw *dev,
u32 changed)
{
struct rtl8187_priv *priv = dev->priv;
+ struct rtl8187_vif *vif_priv;
int i;
u8 reg;
+ vif_priv = (struct rtl8187_vif *)&vif->drv_priv;
+
if (changed & BSS_CHANGED_BSSID) {
mutex_lock(&priv->conf_mutex);
for (i = 0; i < ETH_ALEN; i++)
@@ -1189,8 +1257,12 @@ static void rtl8187_bss_info_changed(struct
ieee80211_hw *dev,
else
reg = 0;
- if (is_valid_ether_addr(info->bssid))
- reg |= RTL818X_MSR_INFRA;
+ if (is_valid_ether_addr(info->bssid)) {
+ if (vif->type == NL80211_IFTYPE_ADHOC)
+ reg |= RTL818X_MSR_ADHOC;
+ else
+ reg |= RTL818X_MSR_INFRA;
+ }
else
reg |= RTL818X_MSR_NO_LINK;
@@ -1202,6 +1274,16 @@ static void rtl8187_bss_info_changed(struct
ieee80211_hw *dev,
if (changed & (BSS_CHANGED_ERP_SLOT | BSS_CHANGED_ERP_PREAMBLE))
rtl8187_conf_erp(priv, info->use_short_slot,
info->use_short_preamble);
+
+ if (changed & BSS_CHANGED_BEACON_ENABLED)
+ vif_priv->enable_beacon = info->enable_beacon;
+
+ if (changed & (BSS_CHANGED_BEACON_ENABLED | BSS_CHANGED_BEACON)) {
+ cancel_delayed_work_sync(&vif_priv->beacon_work);
+ if (vif_priv->enable_beacon)
+ schedule_work(&vif_priv->beacon_work.work);
+ }
+
}
static u64 rtl8187_prepare_multicast(struct ieee80211_hw *dev,
@@ -1279,13 +1361,6 @@ static int rtl8187_conf_tx(struct ieee80211_hw *dev,
return 0;
}
-static u64 rtl8187_get_tsf(struct ieee80211_hw *dev, struct ieee80211_vif *vif)
-{
- struct rtl8187_priv *priv = dev->priv;
-
- return rtl818x_ioread32(priv, &priv->map->TSFT[0]) |
- (u64)(rtl818x_ioread32(priv, &priv->map->TSFT[1])) << 32;
-}
static const struct ieee80211_ops rtl8187_ops = {
.tx = rtl8187_tx,
@@ -1514,12 +1589,9 @@ static int __devinit rtl8187_probe(struct
usb_interface *intf,
if (reg & 0xFF00)
priv->rfkill_mask = RFKILL_MASK_8198;
}
-
- /*
- * XXX: Once this driver supports anything that requires
- * beacons it must implement IEEE80211_TX_CTL_ASSIGN_SEQ.
- */
- dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
+ dev->vif_data_size = sizeof(struct rtl8187_vif);
+ dev->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_ADHOC) ;
if ((id->driver_info == DEVICE_RTL8187) && priv->is_rtl8187b)
printk(KERN_INFO "rtl8187: inconsistency between id with OEM"
diff --git a/drivers/net/wireless/rtl818x/rtl8187/rtl8187.h
b/drivers/net/wireless/rtl818x/rtl8187/rtl8187.h
index f1cc907..a63eafe 100644
--- a/drivers/net/wireless/rtl818x/rtl8187/rtl8187.h
+++ b/drivers/net/wireless/rtl818x/rtl8187/rtl8187.h
@@ -89,6 +89,14 @@ enum {
DEVICE_RTL8187B
};
+struct rtl8187_vif {
+ struct ieee80211_hw *dev;
+
+ /* beaconing */
+ struct delayed_work beacon_work;
+ bool enable_beacon;
+};
+
struct rtl8187_priv {
/* common between rtl818x drivers */
struct rtl818x_csr *map;
@@ -141,6 +149,7 @@ struct rtl8187_priv {
__le32 bits32;
} *io_dmabuf;
bool rfkill_off;
+ u16 seqno;
};
void rtl8187_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data);
--- On Tue, 21/2/12, Attila Fazekas <[email protected]> wrote:
> I think it is worth the effort.
>
> Hostapd AFAIK is not working with rtl8187 now.
> Until we can make it work in master mode, the adhoc mode
> could be an
> alternative. I think even if we can use it in master mode,
> ad-hoc mode
> should be implemented.
You (and others) could comment on the issue of not-working hostapd a bit more; we might want to get it working properly anyway.
As Larry requested - please send the patch without munching from your
e-mail client. Since you are on gmail, I could offer a little advice on git-send-email, which may or may not be something you already know. This is what I do to send patches from my gmail account (change "name" and "acct" and "FILLTHISIN" and "patch-file" to suit yourself), and you could add --cc a few of us there also:
git send-email --from 'name <[email protected]>' \
--to [email protected] --to [email protected] \
--smtp-server smtp.gmail.com --smtp-server-port 465 --smtp-user \ [email protected] --smtp-pass FILLTHISIN --smtp-ssl patch-file
You can do "man git-send-email" (all git man pages uses "git-something" to document the "git something" sub commands, with a dash between) to read about all the switches and what they are supposed to do.
> About refactoring:
>
> rtl8180_beacon_work()
> Now is almost the same, I think it is possible to make it
> generic by a
> macro, or by creating new source/object file linked to both
> driver, or
> even possible to create a common module.
> But, this function will be different if someone will be able
> to add
> some hardware aided beacon timestamp update. (If I can have
> more
> information about this hardware I'll try it)
> Creating a new common module just for one small function,
> IMHO not
> worth the effort.
> Please advice.
>
> struct rtl8187_vif, struct rtl8180_vif? now are the
> same, they might
> be the same in the future as well.
> We can remove them and create new one named rtl818x_vif in
> the rtl818x.h .
> Shall I do it ?
I haven't got a strong opinion on this - but we probably like to try your patch out first :-).
Thanks for the work!
Hin-Tak
--- On Wed, 22/2/12, Larry Finger <[email protected]> wrote:
<snipped bits>
> > As Larry requested - please send the patch without
> munching from your
> > e-mail client. Since you are on gmail, I could offer a
> little advice on git-send-email, which may or may not be
> something you already know. This is what I do to send
> patches from my gmail account (change "name" and "acct" and
> "FILLTHISIN" and "patch-file" to suit yourself), and you
> could add --cc a few of us there also:
> >
> > git send-email --from 'name<[email protected]>'
> \
> > --to [email protected]
> --to [email protected]
> \
> > --smtp-server smtp.gmail.com --smtp-server-port 465
> --smtp-user \ [email protected]
> --smtp-pass FILLTHISIN --smtp-ssl patch-file
> >
> > You can do "man git-send-email" (all git man pages uses
> "git-something" to document the "git something" sub
> commands, with a dash between) to read about all the
> switches and what they are supposed to do.
<snipped>
> I fixed and tested your patch. With it, I certainly see the
> beacons and I was
> able to use NetworkManager to connect once. However, I was
> never able to ping
> from either end of the network to the other.
Do you need something manual set-up like "ifconfig wlan1 192.168.0.1" for one box and "ifconfig wlan1 192.168.0.2" for the other box in the IP layer to work? I haven't quite got my head around this one - how network manager agrees for each for go into a private tcp/ip network, given there are three(?) private ranges to use, and setting up host names, and what ip adresses to assign... and since there is no dns for a network of two, it would have to ping by ip address?
> Besides the mangling of the patch by your mailer, you had
> many problems with
> spaces instead of tabs. Did you use scripts/checkpatch.pl to
> test for errors?
Hmm, probably try not to scare him away... Here is the definitive guide from Linus for submitting patches for the kernel in general:
http://linuxwireless.org/en/developers/Documentation/SubmittingPatches/sourcedoc
and here is one with information specific to wireless stuff:
http://linuxwireless.org/en/developers/Documentation/SubmittingPatches
I think it is worth the effort.
Hostapd AFAIK is not working with rtl8187 now.
Until we can make it work in master mode, the adhoc mode could be an
alternative. I think even if we can use it in master mode, ad-hoc mode
should be implemented.
About refactoring:
rtl8180_beacon_work()
Now is almost the same, I think it is possible to make it generic by a
macro, or by creating new source/object file linked to both driver, or
even possible to create a common module.
But, this function will be different if someone will be able to add
some hardware aided beacon timestamp update. (If I can have more
information about this hardware I'll try it)
Creating a new common module just for one small function, IMHO not
worth the effort.
Please advice.
struct rtl8187_vif, struct rtl8180_vif now are the same, they might
be the same in the future as well.
We can remove them and create new one named rtl818x_vif in the rtl818x.h .
Shall I do it ?
On Mon, Feb 20, 2012 at 12:17 AM, Hin-Tak Leung
<[email protected]> wrote:
> --- On Sun, 19/2/12, Larry Finger <[email protected]> wrote:
>
>> On 02/19/2012 01:54 PM, Attila
>> Fazekas wrote:
>> > Add AD-HOC support to the rtl8187 based on the rtl8180
>> source
>> >
>> > Signed-off-by: Attila Fazekas<[email protected]>
>> > ---
>> > diff --git
>> a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> > b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> > index 638fbef..f8f9186 100644
>> > --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> > +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> > @@ -232,6 +232,7 @@ static void rtl8187_tx(struct
>> ieee80211_hw *dev,
>> > struct sk_buff *skb)
>> >???{
>> >?????? struct rtl8187_priv
>> *priv = dev->priv;
>> >?????? struct
>> ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
>> > +??? struct ieee80211_hdr *tx_hdr =
>> ??? (struct ieee80211_hdr *)(skb->data);
>> >?????? unsigned int ep;
>> >?????? void *buf;
>> >?????? struct urb *urb;
>> > @@ -249,7 +250,7 @@ static void rtl8187_tx(struct
>> ieee80211_hw *dev,
>> > struct sk_buff *skb)
>>
>> This patch was mangled by your mailer. See how the line
>> above is wrapped? In addition, the tabs seem to have been
>> replaced by spaces.
>>
>> To test what works, you should mail a patch to yourself and
>> see if the version extracted from your mailer still
>> applies.
>
> I am curious about this patch - does it take this amount of driver-specific effort to make ad-hoc mode work? Master mode is preferably handled in a generic way by hostapd... "Add AD-HOC support to the rtl8187 based on the rtl8180 source" - could some refactor be done?
>
> Hin-Tak
On 02/22/2012 06:59 PM, Julian Calaby wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 11:44, Hin-Tak Leung
> <[email protected]> wrote:
>> --- On Wed, 22/2/12, Larry Finger<[email protected]> wrote:
>>> I fixed and tested your patch. With it, I certainly see the
>>> beacons and I was
>>> able to use NetworkManager to connect once. However, I was
>>> never able to ping
>>> from either end of the network to the other.
>>
>> Do you need something manual set-up like "ifconfig wlan1 192.168.0.1" for one box and "ifconfig wlan1 192.168.0.2" for the other box in the IP layer to work? I haven't quite got my head around this one - how network manager agrees for each for go into a private tcp/ip network, given there are three(?) private ranges to use, and setting up host names, and what ip adresses to assign... and since there is no dns for a network of two, it would have to ping by ip address?
>
> If it's anything like how it works on Ubuntu, when you start an Ad-Hoc
> network with NetworkManager, it chooses an IP range based on some
> internal logic (usually in the 10.0.0.0/8 private network) sets it's
> IP to something sensible then starts a DHCP server for everyone else
> on the network, so everyone should get a valid IP.
Actually, I was assigning the IP for both ends and not using DHCP. My test
network was a trivial one that was not connected to the outside world - only two
isolated computers that should have been talking to each other. I expected a
wireless NULL cable.
I could see the iwconfig from each end being part of the cell and each end had
an IP address, but no ping data flowed between them.
Larry
On 02/19/2012 01:54 PM, Attila Fazekas wrote:
> Add AD-HOC support to the rtl8187 based on the rtl8180 source
>
> Signed-off-by: Attila Fazekas<[email protected]>
> ---
> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c
> b/drivers/net/wireless/rtl818x/rtl8187/dev.c
> index 638fbef..f8f9186 100644
> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
> @@ -232,6 +232,7 @@ static void rtl8187_tx(struct ieee80211_hw *dev,
> struct sk_buff *skb)
> {
> struct rtl8187_priv *priv = dev->priv;
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> + struct ieee80211_hdr *tx_hdr = (struct ieee80211_hdr *)(skb->data);
> unsigned int ep;
> void *buf;
> struct urb *urb;
> @@ -249,7 +250,7 @@ static void rtl8187_tx(struct ieee80211_hw *dev,
> struct sk_buff *skb)
This patch was mangled by your mailer. See how the line above is wrapped? In
addition, the tabs seem to have been replaced by spaces.
To test what works, you should mail a patch to yourself and see if the version
extracted from your mailer still applies.
Larry
--- On Thu, 23/2/12, Julian Calaby <[email protected]> wrote:
> If it's anything like how it works on Ubuntu, when you start
> an Ad-Hoc
> network with NetworkManager, it chooses an IP range based on
> some
> internal logic (usually in the 10.0.0.0/8 private network)
> sets it's
> IP to something sensible then starts a DHCP server for
> everyone else
> on the network, so everyone should get a valid IP.
Thanks - that would make sense. (I have no experience setting up an ad-hoc network).
OTOH, just so that we have established the basics - I would shutdown networkmanger/wpa_supplicant and do things manually if I were to test prototype driver patches though. There are many reasons why ad-hoc mode itself might work but one cannot ping, other than the patch not working or the hardware not behaving. The latter is in the tcp/ip layer and quite a lot higher than the wifi mac layer - if one had iptables/netfilter blocking icmp echo, for example. I'd probably just look at the packet stats from iwconfig/ifconfig, and may be firing up wireshark. It is up to Attila to show that it does work, and Larry to show that it does not :-).
Hin-Tak
--- On Sun, 19/2/12, Larry Finger <[email protected]> wrote:
> On 02/19/2012 01:54 PM, Attila
> Fazekas wrote:
> > Add AD-HOC support to the rtl8187 based on the rtl8180
> source
> >
> > Signed-off-by: Attila Fazekas<[email protected]>
> > ---
> > diff --git
> a/drivers/net/wireless/rtl818x/rtl8187/dev.c
> > b/drivers/net/wireless/rtl818x/rtl8187/dev.c
> > index 638fbef..f8f9186 100644
> > --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
> > +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
> > @@ -232,6 +232,7 @@ static void rtl8187_tx(struct
> ieee80211_hw *dev,
> > struct sk_buff *skb)
> >???{
> >?????? struct rtl8187_priv
> *priv = dev->priv;
> >?????? struct
> ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> > +??? struct ieee80211_hdr *tx_hdr =
> ??? (struct ieee80211_hdr *)(skb->data);
> >?????? unsigned int ep;
> >?????? void *buf;
> >?????? struct urb *urb;
> > @@ -249,7 +250,7 @@ static void rtl8187_tx(struct
> ieee80211_hw *dev,
> > struct sk_buff *skb)
>
> This patch was mangled by your mailer. See how the line
> above is wrapped? In addition, the tabs seem to have been
> replaced by spaces.
>
> To test what works, you should mail a patch to yourself and
> see if the version extracted from your mailer still
> applies.
I am curious about this patch - does it take this amount of driver-specific effort to make ad-hoc mode work? Master mode is preferably handled in a generic way by hostapd... "Add AD-HOC support to the rtl8187 based on the rtl8180 source" - could some refactor be done?
Hin-Tak
Hi,
On Thu, Feb 23, 2012 at 11:44, Hin-Tak Leung
<[email protected]> wrote:
> --- On Wed, 22/2/12, Larry Finger <[email protected]> wrote:
>> I fixed and tested your patch. With it, I certainly see the
>> beacons and I was
>> able to use NetworkManager to connect once. However, I was
>> never able to ping
>> from either end of the network to the other.
>
> Do you need something manual set-up like "ifconfig wlan1 192.168.0.1" for one box and "ifconfig wlan1 192.168.0.2" for the other box in the IP layer to work? I haven't quite got my head around this one - how network manager agrees for each for go into a private tcp/ip network, given there are three(?) private ranges to use, and setting up host names, and what ip adresses to assign... and since there is no dns for a network of two, it would have to ping by ip address?
If it's anything like how it works on Ubuntu, when you start an Ad-Hoc
network with NetworkManager, it chooses an IP range based on some
internal logic (usually in the 10.0.0.0/8 private network) sets it's
IP to something sensible then starts a DHCP server for everyone else
on the network, so everyone should get a valid IP.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
On 02/22/2012 03:51 PM, Hin-Tak Leung wrote:
> --- On Tue, 21/2/12, Attila Fazekas<[email protected]> wrote:
>
>> I think it is worth the effort.
>>
>> Hostapd AFAIK is not working with rtl8187 now.
>> Until we can make it work in master mode, the adhoc mode
>> could be an
>> alternative. I think even if we can use it in master mode,
>> ad-hoc mode
>> should be implemented.
>
> You (and others) could comment on the issue of not-working hostapd a bit more; we might want to get it working properly anyway.
>
> As Larry requested - please send the patch without munching from your
> e-mail client. Since you are on gmail, I could offer a little advice on git-send-email, which may or may not be something you already know. This is what I do to send patches from my gmail account (change "name" and "acct" and "FILLTHISIN" and "patch-file" to suit yourself), and you could add --cc a few of us there also:
>
> git send-email --from 'name<[email protected]>' \
> --to [email protected] --to [email protected] \
> --smtp-server smtp.gmail.com --smtp-server-port 465 --smtp-user \ [email protected] --smtp-pass FILLTHISIN --smtp-ssl patch-file
>
> You can do "man git-send-email" (all git man pages uses "git-something" to document the "git something" sub commands, with a dash between) to read about all the switches and what they are supposed to do.
>
>> About refactoring:
>>
>> rtl8180_beacon_work()
>> Now is almost the same, I think it is possible to make it
>> generic by a
>> macro, or by creating new source/object file linked to both
>> driver, or
>> even possible to create a common module.
>> But, this function will be different if someone will be able
>> to add
>> some hardware aided beacon timestamp update. (If I can have
>> more
>> information about this hardware I'll try it)
>> Creating a new common module just for one small function,
>> IMHO not
>> worth the effort.
>> Please advice.
>>
>> struct rtl8187_vif, struct rtl8180_vif now are the
>> same, they might
>> be the same in the future as well.
>> We can remove them and create new one named rtl818x_vif in
>> the rtl818x.h .
>> Shall I do it ?
>
> I haven't got a strong opinion on this - but we probably like to try your patch out first :-).
If drivers rtl8180 and rtl8187 each end up with the same struct definition in
their private headers, it certainly makes sense to place the code in a common
header.
I fixed and tested your patch. With it, I certainly see the beacons and I was
able to use NetworkManager to connect once. However, I was never able to ping
from either end of the network to the other.
Besides the mangling of the patch by your mailer, you had many problems with
spaces instead of tabs. Did you use scripts/checkpatch.pl to test for errors?
Larry