There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
RTL8192SE. The method of distinguishing them is by the revision ID
at offset 0x8 of the PCI configuration space. If the value is 0x10,
then the device uses rtl8192se for a driver.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Post commit e4eefec7, the stack is
not generating the CCMP header for us anymore. This broke the CCMP
functionality since firmware was not doing this either. Set a flag
to tell the firmware to generate the CCMP header
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Following OOPS was seen when booting with card inserted

 BUG: unable to handle kernel NULL pointer dereference at 0000004c
 IP: [<f8b7718c>] cfg80211_get_drvinfo+0x21/0x115 [cfg80211]
 *pde = 00000000
 Oops: 0000 [#1] SMP
 Modules linked in: iwl3945 iwl_legacy mwifiex_sdio mac80211 11 sdhci_pci sdhci pl2303

'ethtool' on the mwifiex device returned this OOPS as
wiphy_dev() returned NULL.

Adding missing set_wiphy_dev() call to fix the problem.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().

To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.

Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the case we fail to allocate a new skb, the old skb should
be resubmitted unmodified.

Fixes bug introduced in a9e12869.
Signed-off-by: NMike McCormack <mikem@ring3k.org>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Should pass along packet if there's no CRC and no hardware error.
Signed-off-by: NMike McCormack <mikem@ring3k.org>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Setting tx power can be deferred during scan or changing channel.
If after that correct tx power settings will not be sent to device,
we can observe transmission problems and timeouts. Force to send
tx power settings also after partial rxon change, to assure device
always be configured with up-to-date settings.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=36492

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Avoid queue and run autowakeup_work when device is not present anymore.
That prevent rmmod and device remove crash introduced by:

commit 1c0bcf89
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date:   Sat Apr 30 17:18:18 2011 +0200

    rt2x00: Add autowake support for USB hardware
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes 802.11n stability and performance regression we have
since 2.6.35. It boost performance on my 5GHz N-only network from about
5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.

These are test results of 5x downloading of approximately 700MB iso
image:

vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946

This was achieved with NetworkManager configured to do not perform
periodical scans, by configuring constant BSSID. With periodical scans,
after some time, performance downgrade to unpatched driver level, like
in example below:

patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683

However patch still make better here, since similar test on unpatched
driver make link disconnects with below messages after some time:

wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
wlan1: authentication with 00:23:69:35:d1:3f timed out

On 2.6.35 kernel patch helps against connection hangs with messages:

iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
iwlagn 0000:20:00.0: On demand firmware reload
iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting

Cc: stable@kernel.org # 2.6.35+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit 06e8935f adds an IRQ handling
optimization for single-function SDIO cards like this one, but at the
same time exposes a small hardware bug.

During hardware init, an interrupt is generated with (apparently) no
source. Previously, mmc threw this interrupt away, but now (due to the
optimization), the mmc layer passes this onto libertas, before it is ready
(and before it has enabled interrupts), causing a crash.

Work around this hardware bug by registering the IRQ handler later and
making it capable of handling interrupts with no cause. The change that
makes the IRQ handler registration happen later actually eliminates
the spurious interrupt as well.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We use priv->mutex to avoid race conditions between iwl_chswitch_done()
and iwlagn_mac_channel_switch(), when marking channel switch in
progress. But iwl_chswitch_done() can be called in atomic context
from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().

These bugs were introduced by:

commit 79d07325
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Thu May 6 08:54:11 2010 -0700

    iwlwifi: support channel switch offload in driver

To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
marking channel switch pending.

Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.

Cc: stable@kernel.org # 2.6.36+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Disable fast channel change by default on AR2413/AR5413 due to
some bug reports (it still works for me but it's better to be safe).
Add a module parameter "fastchanswitch" in case anyone wants to enable
it and play with it.
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were incorrectly executing PCIe specific workarounds on PCI cards.
This resulted in:
Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
Reported-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In some cases we can read wrong temperature value. If after that
temperature value will not be updated to good one, we badly configure
tx power parameters and device is unable to send a data.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=35932

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is the same fix as

   commit 84105160
   Author: Matteo Croce <technoboy85@gmail.com>
   Date:   Fri Dec 3 02:25:08 2010 +0100

   The ath9k driver subtracts 3 dBm to the txpower as with two radios the
   signal power is doubled.
   The resulting value is assigned in an u16 which overflows and makes
   the card work at full power.

in two more places. I grepped the ath tree and didn't find any others.

Cc: stable@kernel.org
Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For 6150 devices, modify the supported PCI subsystem ID.

Cc: stable@kernel.org
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1

However on USB 1.1 endpoint becomes Bulk:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

Commit 37939810 assumed that endpoint is
always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg().

Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the
call and changes requested pipe to interrupt type (see usb_bulk_msg).
However with usb_interrupt_msg() on bulk endpoint does not correct the
pipe type to bulk, but instead URB is submitted with interrupt type pipe.

So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint
types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes
ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw
from working with OHCI.

Fix this by detecting endpoint type and using correct endpoint/pipe types
for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right
URB type on 'EP 4 OUT'.

Cc: stable@kernel.org
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix kernel oops when trying to use passive scheduled scans.  The
reason was that in passive scans there are no SSIDs, so there was a
NULL pointer dereference.

To solve the problem, we now check the number of SSIDs provided in the
sched_scan request and only access the list if there's one or more
(ie. passive scan is not forced).  We also force all the channels to
be passive by adding the IEEE80211_CHAN_PASSIVE_SCAN flag locally
before the checks in the wl1271_scan_get_sched_scan_channels()
function.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a different value for DFS dwell time when performing a scheduled
scan.  Previously we were using the same value as for normal passive
scans.  This adds some flexibility between these two different types
of passive scan.

For now we use 150 TUs for DFS channel dwell time.  This may need to
be fine-tuned in the future.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

DFS channels were never getting included in the scheduled scans,
because they always contain the passive flag as well and the call was
asking for DFS and active channels.

Fix this by ignoring the passive flag when collecting DFS channels.
Also, move the DFS channels in the channel list before the 5GHz active
channels (this was implemented in the FW differently than specified).
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were comparing bitwise AND results with a boolean, so when the
boolean was set to true, it was not matching as it should.

Fix this by booleanizing the bitwise AND results with !!.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Before this patch, the command sequence number is being set before
lbs_queue_cmd() adds the command to the queue. However, lbs_queue_cmd()
sometimes forces commands to queue-jump (e.g. CMD_802_11_WAKEUP_CONFIRM).
It currently does this without considering that sequence numbers might need
adjusting to keep things running in order.

Fix this by setting the sequence number at a later stage, just before
we're actually submitting the command to the hardware. Also fixes a
possible race where seqnum was being modified outside of the driver
lock.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The AR9287 calibration code was not being called because of an
incorrect MAC revision check.
This forced the AR9287 to use the AR9285 initial calibration code and
bypass the AR9287 code entirely.
Signed-off-by: NAdrian Chadd <adrian@freebsd.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We make oldconfig every time when a new kernel arrives, but
if we don't have such a device(I guess this is the most common
case for a new device), the default value should be 'n' so
that the kernel size we build doesn't grow up too much quickly.
For anyone who has the device, it is OK for them to turn it on
by themselves.

Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NTao Ma <boyu.mt@taobao.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rx_status.band is used uninitialized, what disallow to work on 5GHz .

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whenever there is a channel width change from 40 Mhz to 20 Mhz,
the hardware is reconfigured to ht20. Meantime before doing
the rate control updation, the packets are being transmitted are
selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH.

While transmitting ht40 rate packets in ht20 mode is causing
baseband panic with AR9003 based chips.

==== BB update: BB status=0x02001109 ====
ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2
src=0 **
ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 **
ath: ** BB mode: BB_gen_controls=0x000033c0 **
ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% **
ath: ==== BB update: done ====

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While receiving unsupported rate frame rx state machine
gets into a state 0xb and if phy_restart happens in that
state, BB would go hang. If RXSM is in 0xb state after
first bb panic, ensure to disable the phy_restart.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Resetting hardware helps to recover from baseband
hang/panic for AR9003 based chips.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Reported-by: NLarry Finger <larry.finger@lwfinger.net>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Although a previous fix handles the kernel panics that result from
failure to allocate a new RX buffer, memory fragmentation can be
reduced if the amsdu_8k capability is disabled as new buffers need only
be of O(0), not O(2).
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

To handle amsdu_8k capability, the PCI routine of this driver must
allocate receive buffers of order 2. Under heavy load, this causes
fragmentation of memory. The present code releases the current buffer
before checking to see if a new one is availble. Recovery from
allocation failures is not possible, which results in kernel panics.

The fix is to reorder the code to check that a new buffer can be
allocated before the old one is released. If not possible, the
received frame is dropped and the old one is reused. Without this
change, it is impossible to transfer a 2 GB file without a kernel panic.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>              [2.6.{37,38,39}]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While decoding received event packet from firmware, 4 bytes
of interface header are already removed unconditionally.
So for handling event only 4 more bytes needs to be pulled.
This is achieved by changing event header length to 4.

Almost all the events, except BA stream related and AMSDU
aggregation control events, do not have the payload in their
event skb. Such events handling depends only on the event ID.
This event ID is the first four bytes of the event skb, which
is copied to a separate variable before pulling the skb header.
Hence event handling worked only for those events that didn't
have payload in event skb.

This patch fixes the broken event path of the events with
payload in their event skb without harming existing working
event path for the events without payload.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NKiran Divekar <dkiran@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Weiping Pan noticed that the module option description for
xmit_hash_policy was incorrect and was nice enough to post a patch to
fix it.  The text was correct, but created a line over 80 characters and
I would rather not add those.  I realized I could take a few minutes and
clean up all the descriptions and things would look much better.  This
is the result.

Based on patch from Weiping Pan <panweiping3@gmail.com>.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
CC: Weiping Pan <panweiping3@gmail.com>
Reviewed-by: NWeiping Pan <panweiping3@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use platform device rather than net device in dev_err calls before net
device has been registered to avoid messages such as

	(null): DaVinci EMAC: Failed to get EMAC clock

Also replace remaining printks in probe with dev_{err,warn}.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Improves the documentation about how IGMP resend parameter
works, fix two missing checks and coding style issues.
Signed-off-by: NFlavio Leitner <fbl@redhat.com>
Acked-by: NRick Jones <rick.jones2@hp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This soft lockup was recently reported:

[root@dell-per715-01 ~]# echo +bond5 > /sys/class/net/bonding_masters
[root@dell-per715-01 ~]# echo +eth1 > /sys/class/net/bond5/bonding/slaves
bonding: bond5: doing slave updates when interface is down.
bonding bond5: master_dev is not up in bond_enslave
[root@dell-per715-01 ~]# echo -eth1 > /sys/class/net/bond5/bonding/slaves
bonding: bond5: doing slave updates when interface is down.

BUG: soft lockup - CPU#12 stuck for 60s! [bash:6444]
CPU 12:
Modules linked in: bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
be2d
Pid: 6444, comm: bash Not tainted 2.6.18-262.el5 #1
RIP: 0010:[<ffffffff80064bf0>]  [<ffffffff80064bf0>]
.text.lock.spinlock+0x26/00
RSP: 0018:ffff810113167da8  EFLAGS: 00000286
RAX: ffff810113167fd8 RBX: ffff810123a47800 RCX: 0000000000ff1025
RDX: 0000000000000000 RSI: ffff810123a47800 RDI: ffff81021b57f6f8
RBP: ffff81021b57f500 R08: 0000000000000000 R09: 000000000000000c
R10: 00000000ffffffff R11: ffff81011d41c000 R12: ffff81021b57f000
R13: 0000000000000000 R14: 0000000000000282 R15: 0000000000000282
FS:  00002b3b41ef3f50(0000) GS:ffff810123b27940(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002b3b456dd000 CR3: 000000031fc60000 CR4: 00000000000006e0

Call Trace:
 [<ffffffff80064af9>] _spin_lock_bh+0x9/0x14
 [<ffffffff886937d7>] :bonding:tlb_clear_slave+0x22/0xa1
 [<ffffffff8869423c>] :bonding:bond_alb_deinit_slave+0xba/0xf0
 [<ffffffff8868dda6>] :bonding:bond_release+0x1b4/0x450
 [<ffffffff8006457b>] __down_write_nested+0x12/0x92
 [<ffffffff88696ae4>] :bonding:bonding_store_slaves+0x25c/0x2f7
 [<ffffffff801106f7>] sysfs_write_file+0xb9/0xe8
 [<ffffffff80016b87>] vfs_write+0xce/0x174
 [<ffffffff80017450>] sys_write+0x45/0x6e
 [<ffffffff8005d28d>] tracesys+0xd5/0xe0

It occurs because we are able to change the slave configuarion of a bond while
the bond interface is down.  The bonding driver initializes some data structures
only after its ndo_open routine is called.  Among them is the initalization of
the alb tx and rx hash locks.  So if we add or remove a slave without first
opening the bond master device, we run the risk of trying to lock/unlock a
spinlock that has garbage for data in it, which results in our above softlock.

Note that sometimes this works, because in many cases an unlocked spinlock has
the raw_lock parameter initialized to zero (meaning that the kzalloc of the
net_device private data is equivalent to calling spin_lock_init), but thats not
true in all cases, and we aren't guaranteed that condition, so we need to pass
the relevant spinlocks through the spin_lock_init function.

Fix it by moving the spin_lock_init calls for the tx and rx hashtable locks to
the ndo_init path, so they are ready for use by the bond_store_slaves path.

Change notes:
v2) Based on conversation with Jay and Nicolas it seems that the ability to
enslave devices while the bond master is down should be safe to do.  As such
this is an outlier bug, and so instead we'll just initalize the errant spinlocks
in the init path rather than the open path, solving the problem.  We'll also
remove the warnings about the bond being down during enslave operations, since
it should be safe

v3) Fix spelling error
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Reported-by: jtluka@redhat.com
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: nicolas.2p.debian@gmail.com
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds the PCI ID of Fujitsu 1000base-SX NIC to tg3 driver.
Tested to detect the card, MAC and serdes, not tested with link at the
moment since I have no fiber switch here. I did not add new constants to
the pci_ids.h header file since these constants are used only here.
Signed-off-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>