Bleh. Why would you post a patch with an invalid sender address?!
----- Forwarded message from Mail Delivery System
<mailer-dae...@symphytum.spacehopper.org> -----
From: Mail Delivery System <mailer-dae...@symphytum.spacehopper.org>
Date: Mon, 6 Feb 2012 10:34:00 +0000 (GMT)
To: s...@spacehopper.org
Subject: Undelivered Mail Returned to Sender
This is the mail system at host symphytum.spacehopper.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<inva...@nocrater.com>: host mx1.emailsrvr.com[98.129.184.131] said: 550 5.7.1
<inva...@nocrater.com>: Relay access denied. (in reply to RCPT TO command)
Reporting-MTA: dns; symphytum.spacehopper.org
X-Postfix-Queue-ID: 0EAB514E5CB
X-Postfix-Sender: rfc822; s...@spacehopper.org
Arrival-Date: Mon, 6 Feb 2012 10:33:55 +0000 (GMT)
Final-Recipient: rfc822; inva...@nocrater.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx1.emailsrvr.com
Diagnostic-Code: smtp; 550 5.7.1 <inva...@nocrater.com>: Relay access denied.
From: Stuart Henderson <s...@spacehopper.org>
Date: Mon, 6 Feb 2012 10:33:55 +0000
To: Rebecca <inva...@nocrater.com>
Cc: bugs@openbsd.org
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: Huawei E1752 patch
On 2012/02/06 06:34, Rebecca wrote:
> Hi,
>
> We discovered that our Huawei E1752 has a different product ID than is
> listed in the kernel source, and thus was not working by default.
>
> This patch adds in the ID for ours, and it now works fine, but I wasn't
> sure of the preferred way to deal with two devices that go by the same
> name, so I've just appended _ALTERNATE to the model number.
>
> Please let me know what the correct 'etiquette' is in these situations!
We normally use _2, _3, etc. e.g.
Index: umsm.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.85
diff -u -p -r1.85 umsm.c
--- umsm.c 14 Jan 2012 10:26:11 -0000 1.85
+++ umsm.c 6 Feb 2012 10:32:20 -0000
@@ -147,6 +147,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_K4510 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E1750 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E1752 }, 0},
+ {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E1752_2 }, 0},
{{ USB_VENDOR_HYUNDAI, USB_PRODUCT_HYUNDAI_UM175 }, 0},
Index: usbdevs
===================================================================
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.571
diff -u -p -r1.571 usbdevs
--- usbdevs 31 Jan 2012 21:10:19 -0000 1.571
+++ usbdevs 6 Feb 2012 10:32:20 -0000
@@ -1997,6 +1997,7 @@ product HUAWEI E180 0x140c HUAWEI Mobil
product HUAWEI E510 0x1411 HUAWEI Mobile E510
product HUAWEI E181 0x1414 HUAWEI Mobile E181
product HUAWEI E1752 0x1417 HUAWEI Mobile Modem
+product HUAWEI E1752_2 0x141b HUAWEI Mobile Modem
product HUAWEI E182 0x1429 HUAWEI Mobile Modem
product HUAWEI E161 0x1446 HUAWEI Mobile Modem
product HUAWEI K3765 0x1465 HUAWEI Mobile K3765
> +++ usb/usbdevs.h Mon Feb 6 05:21:47 2012
btw, these files are normally regenerated by running 'make' in dev/usb
rather than being hand-adjusted.
----- End forwarded message -----
