* [PATCH] bas_gigaset: fix pre_reset handling
From: Tilman Schmidt @ 2012-10-24 18:44 UTC (permalink / raw)
To: Karsten Keil, David Miller
Cc: Oliver Neukum,
gigaset307x-common-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Hansjoerg Lipp,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
The delayed work function int_in_work() may call usb_reset_device()
and thus, indirectly, the driver's pre_reset method. Trying to
cancel the work synchronously in that situation would deadlock.
Fix by avoiding cancel_work_sync() in the pre_reset method.
If the reset was NOT initiated by int_in_work() this might cause
int_in_work() to run after the post_reset method, with urb_int_in
already resubmitted, so handle that case gracefully.
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/gigaset/bas-gigaset.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/isdn/gigaset/bas-gigaset.c b/drivers/isdn/gigaset/bas-gigaset.c
index 5275887..c44950d 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -617,7 +617,13 @@ static void int_in_work(struct work_struct *work)
if (rc == 0)
/* success, resubmit interrupt read URB */
rc = usb_submit_urb(urb, GFP_ATOMIC);
- if (rc != 0 && rc != -ENODEV) {
+
+ switch (rc) {
+ case 0: /* success */
+ case -ENODEV: /* device gone */
+ case -EINVAL: /* URB already resubmitted, or terminal badness */
+ break;
+ default: /* failure: try to recover by resetting the device */
dev_err(cs->dev, "clear halt failed: %s\n", get_usb_rcmsg(rc));
rc = usb_lock_device_for_reset(ucs->udev, ucs->interface);
if (rc == 0) {
@@ -2442,7 +2448,9 @@ static void gigaset_disconnect(struct usb_interface *interface)
}
/* gigaset_suspend
- * This function is called before the USB connection is suspended.
+ * This function is called before the USB connection is suspended
+ * or before the USB device is reset.
+ * In the latter case, message == PMSG_ON.
*/
static int gigaset_suspend(struct usb_interface *intf, pm_message_t message)
{
@@ -2498,7 +2506,12 @@ static int gigaset_suspend(struct usb_interface *intf, pm_message_t message)
del_timer_sync(&ucs->timer_atrdy);
del_timer_sync(&ucs->timer_cmd_in);
del_timer_sync(&ucs->timer_int_in);
- cancel_work_sync(&ucs->int_in_wq);
+
+ /* don't try to cancel int_in_wq from within reset as it
+ * might be the one requesting the reset
+ */
+ if (message.event != PM_EVENT_ON)
+ cancel_work_sync(&ucs->int_in_wq);
gig_dbg(DEBUG_SUSPEND, "suspend complete");
return 0;
--
1.7.3.4
^ permalink raw reply related
* qmi-wwan bug
From: Shawn J. Goff @ 2012-10-24 18:50 UTC (permalink / raw)
To: netdev
I've backported qmi-wwan to 2.6.39 (it's here:
https://bitbucket.org/accelecon/linux-at91/changesets), and it mostly
works, but I've come across a problem. The modem will sometimes stop
responding to any qmi data (but the AT commands on the TTY ports keep
working). This only happens when there is significant traffic flowing
through the device (downloading a large file) while at the same time, AT
commands are sent to one of the TTY ports (I first noticed with my own
modem query program, but I can reproduce it using microcom to send
"ATI\r" in a loop). I see this problem with different devices from
different manufacturers. I've only made it happen on my kernel - I tried
on 3.6.2, but it seems to not happen there. I've also tried using a
similar modem that uses a different driver (sierra-net) and that doesn't
have the same problem.
When it is in failure, if I try to ping an address, the system sends out
several an ARP requests but gets no response. To get the device to
respond again, I have to administratively set the wwan interface down,
then up, use libqmi to get the connection going again, then dhcp to get
an address.
I also have some USB traces of the failure and recovery process. I'm not
familiar with CDC or QMI, so it's not yet clear to me exactly what's
happening, but it looks like the modem just stops sending anything on
its QMI endpoint for no reason.
How might I dive further into the issue? So far, my next step is to look
into CDC and QMI and try to decypher the USB traces. If anyone is
interested, I can share a tcpdump or a USB trace.
--
Shawn J. Goff | Accelerated Concepts | Embedded Systems Engineer | 1-813-983-7501
^ permalink raw reply
* Re: [PATCH] gianfar_ptp: use iomem, not ioports resource tree in probe
From: Paul Gortmaker @ 2012-10-24 19:09 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: netdev@vger.kernel.org, Wei Yang, Manoil Claudiu-B08782
In-Reply-To: <6AE080B68D46FC4BA2D2769E68D765B70810B134@039-SN2MPN1-023.039d.mgd.msft.net>
On 12-10-24 01:59 PM, Tabi Timur-B04825 wrote:
> On Wed, Oct 24, 2012 at 10:21 AM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
>> From: Wei Yang <Wei.Yang@windriver.com>
>>
>> When using a 36 bit dtb file, the driver complains "resource busy".
>>
>> Investigating the source of the message leads one to the
>> gianfar_ptp_probe function.
>>
>> Since the type of the device resource requested in this function
>> is IORESOURCE_MEM, it should use "iomem_resource" instead of
>> "ioports_resource".
>
> I can't comment on this patch, since I didn't write the driver, but I
> am confused on one thing. Why is the driver using platform_xxx calls
Even if it makes sense to convert the driver to of_xxx calls,
I think the obvious bug should be fixed as a separate commit,
so that the -stable folks have something to cherry pick.
P.
--
> to get data? Why isn't it using of_xxx calls to read properties from
> the device tree? For example, why is it using
>
> etsects->irq = platform_get_irq(dev, 0);
>
> to get the IRQ? Shouldn't it do this instead:
>
> etsects->irq = irq_of_parse_and_map(node, 0);
>
^ permalink raw reply
* Re: [PATCH] gianfar_ptp: use iomem, not ioports resource tree in probe
From: Timur Tabi @ 2012-10-24 19:12 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev@vger.kernel.org, Wei Yang, Manoil Claudiu-B08782
In-Reply-To: <50883D03.1000600@windriver.com>
Paul Gortmaker wrote:
> Even if it makes sense to convert the driver to of_xxx calls,
> I think the obvious bug should be fixed as a separate commit,
> so that the -stable folks have something to cherry pick.
Oh, I agree with that. I was just wondering why an OF-enabled driver
would not use OF calls. I've never seen that before. My instinct is that
the original developer had no idea what he was doing, but perhaps there is
a very good reason for the way the driver is written.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH v2] sctp: Make hmac algorithm selection for cookie generation dynamic
From: Neil Horman @ 2012-10-24 19:20 UTC (permalink / raw)
To: linux-sctp; +Cc: Neil Horman, Vlad Yasevich, David S. Miller, netdev
In-Reply-To: <1350661926-8312-1-git-send-email-nhorman@tuxdriver.com>
Currently sctp allows for the optional use of md5 of sha1 hmac algorithms to
generate cookie values when establishing new connections via two build time
config options. Theres no real reason to make this a static selection. We can
add a sysctl that allows for the dynamic selection of these algorithms at run
time, with the default value determined by the corresponding crypto library
availability.
This comes in handy when, for example running a system in FIPS mode, where use
of md5 is disallowed, but SHA1 is permitted.
Note: This new sysctl has no corresponding socket option to select the cookie
hmac algorithm. I chose not to implement that intentionally, as RFC 6458
contains no option for this value, and I opted not to pollute the socket option
namespace.
Change notes:
v2)
* Updated subject to have the proper sctp prefix as per Dave M.
* Replaced deafult selection options with new options that allow
developers to explicitly select available hmac algs at build time
as per suggestion by Vlad Y.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: netdev@vger.kernel.org
---
Documentation/networking/ip-sysctl.txt | 14 ++++++++
include/net/netns/sctp.h | 3 ++
include/net/sctp/constants.h | 8 -----
include/net/sctp/structs.h | 1 +
net/sctp/Kconfig | 39 ++++++++--------------
net/sctp/protocol.c | 9 ++++++
net/sctp/socket.c | 11 ++++---
net/sctp/sysctl.c | 59 ++++++++++++++++++++++++++++++++++
8 files changed, 106 insertions(+), 38 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index c7fc107..98ac0d7 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1514,6 +1514,20 @@ cookie_preserve_enable - BOOLEAN
Default: 1
+cookie_hmac_alg - STRING
+ Select the hmac algorithm used when generating the cookie value sent by
+ a listening sctp socket to a connecting client in the INIT-ACK chunk.
+ Valid values are:
+ * md5
+ * sha1
+ * none
+ Ability to assign md5 or sha1 as the selected alg is predicated on the
+ configuarion of those algorithms at build time (CONFIG_CRYPTO_MD5 and
+ CONFIG_CRYPTO_SHA1).
+
+ Default: Dependent on configuration. MD5 if available, else SHA1 if
+ available, else none.
+
rcvbuf_policy - INTEGER
Determines if the receive buffer is attributed to the socket or to
association. SCTP supports the capability to create multiple
diff --git a/include/net/netns/sctp.h b/include/net/netns/sctp.h
index 5e5eb1f..3573a81 100644
--- a/include/net/netns/sctp.h
+++ b/include/net/netns/sctp.h
@@ -62,6 +62,9 @@ struct netns_sctp {
/* Whether Cookie Preservative is enabled(1) or not(0) */
int cookie_preserve_enable;
+ /* The namespace default hmac alg */
+ char *sctp_hmac_alg;
+
/* Valid.Cookie.Life - 60 seconds */
unsigned int valid_cookie_life;
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index d053d2e..c29707d 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -312,14 +312,6 @@ enum { SCTP_MAX_GABS = 16 };
* functions simpler to write.
*/
-#if defined (CONFIG_SCTP_HMAC_MD5)
-#define SCTP_COOKIE_HMAC_ALG "hmac(md5)"
-#elif defined (CONFIG_SCTP_HMAC_SHA1)
-#define SCTP_COOKIE_HMAC_ALG "hmac(sha1)"
-#else
-#define SCTP_COOKIE_HMAC_ALG NULL
-#endif
-
/* These return values describe the success or failure of a number of
* routines which form the lower interface to SCTP_outqueue.
*/
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 0fef00f..ce5f957 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -177,6 +177,7 @@ struct sctp_sock {
/* Access to HMAC transform. */
struct crypto_hash *hmac;
+ char *sctp_hmac_alg;
/* What is our base endpointer? */
struct sctp_endpoint *ep;
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index 126b014..a9edd2e 100644
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -9,7 +9,6 @@ menuconfig IP_SCTP
select CRYPTO
select CRYPTO_HMAC
select CRYPTO_SHA1
- select CRYPTO_MD5 if SCTP_HMAC_MD5
select LIBCRC32C
---help---
Stream Control Transmission Protocol
@@ -68,33 +67,21 @@ config SCTP_DBG_OBJCNT
If unsure, say N
-choice
- prompt "SCTP: Cookie HMAC Algorithm"
- default SCTP_HMAC_MD5
+config SCTP_COOKIE_HMAC_MD5
+ bool "Enable optional MD5 hmac cookie generation"
help
- HMAC algorithm to be used during association initialization. It
- is strongly recommended to use HMAC-SHA1 or HMAC-MD5. See
- configuration for Cryptographic API and enable those algorithms
- to make usable by SCTP.
-
-config SCTP_HMAC_NONE
- bool "None"
- help
- Choosing this disables the use of an HMAC during association
- establishment. It is advised to use either HMAC-MD5 or HMAC-SHA1.
-
-config SCTP_HMAC_SHA1
- bool "HMAC-SHA1"
- help
- Enable the use of HMAC-SHA1 during association establishment. It
- is advised to use either HMAC-MD5 or HMAC-SHA1.
-
-config SCTP_HMAC_MD5
- bool "HMAC-MD5"
+ Enable optional MD5 hmac based SCTP cookie generation
+ default y
+ select CRYPTO_HMAC if SCTP_COOKIE_HMAC_MD5
+ select CRYPTO_MD5 if SCTP_COOKIE_HMAC_MD5
+
+config SCTP_COOKIE_HMAC_SHA1
+ bool "Enable optional SHA1 hmac cookie generation"
help
- Enable the use of HMAC-MD5 during association establishment. It is
- advised to use either HMAC-MD5 or HMAC-SHA1.
+ Enable optional SHA1 hmac based SCTP cookie generation
+ default y
+ select CRYPTO_HMAC if SCTP_COOKIE_HMAC_SHA1
+ select CRYPTO_SHA1 if SCTP_COOKIE_HMAC_SHA1
-endchoice
endif # IP_SCTP
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 2d51842..456bc3d 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1190,6 +1190,15 @@ static int sctp_net_init(struct net *net)
/* Whether Cookie Preservative is enabled(1) or not(0) */
net->sctp.cookie_preserve_enable = 1;
+ /* Default sctp sockets to use md5 as their hmac alg */
+#if defined (CONFIG_CRYPTO_MD5)
+ net->sctp.sctp_hmac_alg = "md5";
+#elif defined (CONFIG_CRYPTO_SHA1)
+ net->sctp.sctp_hmac_alg = "sha1";
+#else
+ net->sctp.sctp_hmac_alg = NULL;
+#endif
+
/* Max.Burst - 4 */
net->sctp.max_burst = SCTP_DEFAULT_MAX_BURST;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index d37d24f..c388262 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -109,7 +109,6 @@ static int sctp_do_bind(struct sock *, union sctp_addr *, int);
static int sctp_autobind(struct sock *sk);
static void sctp_sock_migrate(struct sock *, struct sock *,
struct sctp_association *, sctp_socket_type_t);
-static char *sctp_hmac_alg = SCTP_COOKIE_HMAC_ALG;
extern struct kmem_cache *sctp_bucket_cachep;
extern long sysctl_sctp_mem[3];
@@ -3889,6 +3888,8 @@ SCTP_STATIC int sctp_init_sock(struct sock *sk)
sp->default_rcv_context = 0;
sp->max_burst = net->sctp.max_burst;
+ sp->sctp_hmac_alg = net->sctp.sctp_hmac_alg;
+
/* Initialize default setup parameters. These parameters
* can be modified with the SCTP_INITMSG socket option or
* overridden by the SCTP_INIT CMSG.
@@ -5966,13 +5967,15 @@ SCTP_STATIC int sctp_listen_start(struct sock *sk, int backlog)
struct sctp_sock *sp = sctp_sk(sk);
struct sctp_endpoint *ep = sp->ep;
struct crypto_hash *tfm = NULL;
+ char alg[32];
/* Allocate HMAC for generating cookie. */
- if (!sctp_sk(sk)->hmac && sctp_hmac_alg) {
- tfm = crypto_alloc_hash(sctp_hmac_alg, 0, CRYPTO_ALG_ASYNC);
+ if (!sp->hmac && sp->sctp_hmac_alg) {
+ sprintf(alg, "hmac(%s)", sp->sctp_hmac_alg);
+ tfm = crypto_alloc_hash(alg, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm)) {
net_info_ratelimited("failed to load transform for %s: %ld\n",
- sctp_hmac_alg, PTR_ERR(tfm));
+ sp->sctp_hmac_alg, PTR_ERR(tfm));
return -ENOSYS;
}
sctp_sk(sk)->hmac = tfm;
diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
index 70e3ba5..043889a 100644
--- a/net/sctp/sysctl.c
+++ b/net/sctp/sysctl.c
@@ -62,6 +62,11 @@ extern long sysctl_sctp_mem[3];
extern int sysctl_sctp_rmem[3];
extern int sysctl_sctp_wmem[3];
+static int proc_sctp_do_hmac_alg(ctl_table *ctl,
+ int write,
+ void __user *buffer, size_t *lenp,
+
+ loff_t *ppos);
static ctl_table sctp_table[] = {
{
.procname = "sctp_mem",
@@ -147,6 +152,12 @@ static ctl_table sctp_net_table[] = {
.proc_handler = proc_dointvec,
},
{
+ .procname = "cookie_hmac_alg",
+ .maxlen = 8,
+ .mode = 0644,
+ .proc_handler = proc_sctp_do_hmac_alg,
+ },
+ {
.procname = "valid_cookie_life",
.data = &init_net.sctp.valid_cookie_life,
.maxlen = sizeof(unsigned int),
@@ -289,6 +300,54 @@ static ctl_table sctp_net_table[] = {
{ /* sentinel */ }
};
+static int proc_sctp_do_hmac_alg(ctl_table *ctl,
+ int write,
+ void __user *buffer, size_t *lenp,
+ loff_t *ppos)
+{
+ struct net *net = current->nsproxy->net_ns;
+ char tmp[8];
+ ctl_table tbl;
+ int ret;
+ int changed = 0;
+ char *none = "none";
+
+ memset(&tbl, 0, sizeof(struct ctl_table));
+
+ if (write) {
+ tbl.data = tmp;
+ tbl.maxlen = 8;
+ } else {
+ tbl.data = net->sctp.sctp_hmac_alg ? : none;
+ tbl.maxlen = strlen(tbl.data);
+ }
+ ret = proc_dostring(&tbl, write, buffer, lenp, ppos);
+
+ if (write) {
+#ifdef CONFIG_CRYPTO_MD5
+ if (!strncmp(tmp, "md5", 3)) {
+ net->sctp.sctp_hmac_alg = "md5";
+ changed = 1;
+ }
+#endif
+#ifdef CONFIG_CRYPTO_SHA1
+ if (!strncmp(tmp, "sha1", 4)) {
+ net->sctp.sctp_hmac_alg = "sha1";
+ changed = 1;
+ }
+#endif
+ if (!strncmp(tmp, "none", 4)) {
+ net->sctp.sctp_hmac_alg = NULL;
+ changed = 1;
+ }
+
+ if (!changed)
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
int sctp_sysctl_net_register(struct net *net)
{
struct ctl_table *table;
--
1.7.11.7
^ permalink raw reply related
* [PATCH] MAINTAINERS: Add myself to list of SCTP maintainers
From: Neil Horman @ 2012-10-24 19:26 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Vlad Yasevich, David S. Miller, linux-sctp
I've been messing with the code for a bit, and I figured Vlad could use a hand
as interest in the protocol has picked up over the last year or so. I've asked
him, and he doesn't seem too upset over the idea :)
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: linux-sctp@vger.kernel.org
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5655bcc..2463a0a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6352,6 +6352,7 @@ F: drivers/scsi/st*
SCTP PROTOCOL
M: Vlad Yasevich <vyasevich@gmail.com>
M: Sridhar Samudrala <sri@us.ibm.com>
+M: Neil Horman <nhorman@tuxdriver.com>
L: linux-sctp@vger.kernel.org
W: http://lksctp.sourceforge.net
S: Maintained
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] gianfar_ptp: use iomem, not ioports resource tree in probe
From: Richard Cochran @ 2012-10-24 19:42 UTC (permalink / raw)
To: Timur Tabi
Cc: Paul Gortmaker, netdev@vger.kernel.org, Wei Yang,
Manoil Claudiu-B08782
In-Reply-To: <50883DB7.4030502@freescale.com>
On Wed, Oct 24, 2012 at 02:12:55PM -0500, Timur Tabi wrote:
> Paul Gortmaker wrote:
> > Even if it makes sense to convert the driver to of_xxx calls,
> > I think the obvious bug should be fixed as a separate commit,
> > so that the -stable folks have something to cherry pick.
>
> Oh, I agree with that. I was just wondering why an OF-enabled driver
> would not use OF calls. I've never seen that before. My instinct is that
> the original developer had no idea what he was doing, but perhaps there is
> a very good reason for the way the driver is written.
Instead of using your instinct, try using your brain instead.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next 1/2] r8169: enable ALDPS for power saving
From: Francois Romieu @ 2012-10-24 20:05 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, linux-kernel
In-Reply-To: <B3B61E0990514F28A8203537EB9D047A@realtek.com.tw>
hayeswang <hayeswang@realtek.com> :
> Francois Romieu [mailto:romieu@fr.zoreil.com]
> [...]
> > It would be nice to state these things in the commit message, namely:
> > - ALDPS should never be enabled for the RTL8105e
> > - none of the firmware-free chipsets support ALDPS
> > - neither do the RTL8168d/8111d
>
> Excuse me. I don't understand why the RTL8105e shouldn't enable ALDPS.
I'd appreciate to see such a statement if ALDPS can be enabled with the
RTL8105e !
You have sent ALDPS related patches for some specific chipsets. Now
would be a sensible time to check if ALDPS is correctly handled for
_all_ supported chipsets. I don't have access to your authoritative
resources. I can only outline something strange in the code wrt
ALDPS and the 8105e.
/me returns to 8169b RxOverflow oddities...
--
Ueimor
^ permalink raw reply
* Re: [PATCH] gianfar_ptp: use iomem, not ioports resource tree in probe
From: Timur Tabi @ 2012-10-24 20:11 UTC (permalink / raw)
To: Richard Cochran
Cc: Paul Gortmaker, netdev@vger.kernel.org, Wei Yang,
Manoil Claudiu-B08782
In-Reply-To: <20121024194207.GA2732@netboy.at.omicron.at>
Richard Cochran wrote:
>> > Oh, I agree with that. I was just wondering why an OF-enabled driver
>> > would not use OF calls. I've never seen that before. My instinct is that
>> > the original developer had no idea what he was doing, but perhaps there is
>> > a very good reason for the way the driver is written.
> Instead of using your instinct, try using your brain instead.
Well, as you are obviously so much smarter than I am, how about
enlightening me? I do not see any explanations in the original commit,
and I do not know why someone would use non-OF calls to get data from the
device tree. I didn't even know that you could use platform_get_irq() to
get the virtual IRQ from a device tree.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] gianfar_ptp: use iomem, not ioports resource tree in probe
From: Richard Cochran @ 2012-10-24 20:50 UTC (permalink / raw)
To: Timur Tabi
Cc: Paul Gortmaker, netdev@vger.kernel.org, Wei Yang,
Manoil Claudiu-B08782
In-Reply-To: <50884B5D.9030009@freescale.com>
On Wed, Oct 24, 2012 at 03:11:09PM -0500, Timur Tabi wrote:
> Richard Cochran wrote:
> >> > Oh, I agree with that. I was just wondering why an OF-enabled driver
> >> > would not use OF calls. I've never seen that before. My instinct is that
> >> > the original developer had no idea what he was doing, but perhaps there is
> >> > a very good reason for the way the driver is written.
>
> > Instead of using your instinct, try using your brain instead.
>
> Well, as you are obviously so much smarter than I am, how about
> enlightening me? I do not see any explanations in the original commit,
> and I do not know why someone would use non-OF calls to get data from the
> device tree. I didn't even know that you could use platform_get_irq() to
> get the virtual IRQ from a device tree.
And now you know.
^ permalink raw reply
* Re: [BUG] checkpatch.pl with commit 058806007450489bb8f457b275e5cb5c946320c1
From: Jeff Kirsher @ 2012-10-24 20:51 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, LKML
In-Reply-To: <1351087936.18179.9.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Wed, 2012-10-24 at 07:12 -0700, Joe Perches wrote:
> On Wed, 2012-10-24 at 04:00 -0700, Jeff Kirsher wrote:
> > With the recent commit to checkpatch.pl:
> >
> > commit 058806007450489bb8f457b275e5cb5c946320c1
> > Author: Joe Perches <joe@perches.com>
> > Date: Thu Oct 4 17:13:35 2012 -0700
> >
> > checkpatch: check networking specific block comment style
> >
> > We are seeing false positive warnings. Here is an example of the
> > code the would generate a false warning:
> >
> > #define foo 0x0000 /* foo comment */
> >
> > checkpatch.pl generates a warnings that the */ should be on a separate
> > line, which in this case is incorrect.
>
> Sorry 'bout that. I believe it's fixed by:
> https://lkml.org/lkml/2012/10/14/267
>
Yes, I confirm that the patch in the link you provided solves the issue
I was seeing. Thanks, has the patch been accepted yet? I see it is not
in Dave's NET tree as of yet.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: switching network namespace midway
From: Eric W. Biederman @ 2012-10-24 21:11 UTC (permalink / raw)
To: rsa; +Cc: netdev
In-Reply-To: <CAFaHj6FjDULMCdta3bhVu2mtJeR9TuJVMmbC0H6jjkfb6A5t-Q@mail.gmail.com>
rsa <ravi.mlists@gmail.com> writes:
> Assuming I have a tunnel interface where two route lookups are done --
> one for innter
> packet and the other for outer -- do you see any issues in switching
> the network
> namespace prior to second route lookup (and restore to the original namespace
> after the second lookup is done)?
>
> If so, are there any other calls other than sk_change_net() needed?
In general sk_change_net is a bad idea.
Most likely what you want to do is simply memorize both struct net's
that you care about and perform the routing lookup as appropriate.
Certainly you don't want to be calling sk_change_net for every packet
that goes through your tunnel.
Eric
^ permalink raw reply
* Re: qmi-wwan bug
From: Bjørn Mork @ 2012-10-24 21:19 UTC (permalink / raw)
To: Shawn J. Goff, netdev
In-Reply-To: <5088385C.1090304@accelecon.com>
"Shawn J. Goff" <shawn.goff@accelecon.com> wrote:
>I've backported qmi-wwan to 2.6.39 (it's here:
>https://bitbucket.org/accelecon/linux-at91/changesets), and it mostly
>works, but I've come across a problem. The modem will sometimes stop
>responding to any qmi data (but the AT commands on the TTY ports keep
>working). This only happens when there is significant traffic flowing
>through the device (downloading a large file) while at the same time,
>AT
>commands are sent to one of the TTY ports (I first noticed with my own
>modem query program, but I can reproduce it using microcom to send
>"ATI\r" in a loop).
Using the tty ports should be completely independent of any qmi activity from the host perspective. I am tempted to claim this indicates a firmware bug.
> I see this problem with different devices from
>different manufacturers.
Which still may use pretty much the same firmware, although a little less likely.
> I've only made it happen on my kernel - I
>tried
>on 3.6.2, but it seems to not happen there.
Good. But I have a feeling that you switched more than just the kernel. Do you see the issue if you run your backport on the same hardware you tested 3.6.2 on?
> I've also tried using a
>similar modem that uses a different driver (sierra-net) and that
>doesn't
>have the same problem.
Well, that is an entirely different firmware application and driver, even if the hardware is similar or even identical.
>When it is in failure, if I try to ping an address, the system sends
>out
>several an ARP requests but gets no response. To get the device to
>respond again, I have to administratively set the wwan interface down,
>then up, use libqmi to get the connection going again, then dhcp to get
>
>an address.
Which sounds like the connection died. Does QMI work at this point, or is that dead too?
>I also have some USB traces of the failure and recovery process. I'm
>not
>familiar with CDC or QMI, so it's not yet clear to me exactly what's
>happening, but it looks like the modem just stops sending anything on
>its QMI endpoint for no reason.
>
>How might I dive further into the issue? So far, my next step is to
>look
>into CDC and QMI and try to decypher the USB traces. If anyone is
>interested, I can share a tcpdump or a USB trace.
I think a test of the backport on the same host hardware you run 3.6.2 on would be the best place to start.
Bjørn
^ permalink raw reply
* Re: [PATCH v3 net-next] r8169: enable ALDPS for power saving
From: Francois Romieu @ 2012-10-24 21:20 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel, jean
In-Reply-To: <1351059843-1464-1-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Enable ALDPS function to save power when link down. Note that the
> feature should be set after the other PHY settings. And the firmware
> is necessary. Don't enable it without loading the firmware.
>
> None of the firmware-free chipsets support ALDPS. Neither do the
> RTL8168d/8111d.
>
> For 8136 series, make sure the ALDPS is disabled before loading the
> firmware. For 8168 series, the ALDPS would be disabled automatically
> when loading firmware. You must not disable it directly.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
^ permalink raw reply
* Re: switching network namespace midway
From: Benjamin LaHaise @ 2012-10-24 21:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: rsa, netdev
In-Reply-To: <878vavshhp.fsf@xmission.com>
On Wed, Oct 24, 2012 at 02:11:14PM -0700, Eric W. Biederman wrote:
> rsa <ravi.mlists@gmail.com> writes:
>
> > Assuming I have a tunnel interface where two route lookups are done --
> > one for innter
> > packet and the other for outer -- do you see any issues in switching
> > the network
> > namespace prior to second route lookup (and restore to the original namespace
> > after the second lookup is done)?
> >
> > If so, are there any other calls other than sk_change_net() needed?
>
> In general sk_change_net is a bad idea.
>
> Most likely what you want to do is simply memorize both struct net's
> that you care about and perform the routing lookup as appropriate.
>
> Certainly you don't want to be calling sk_change_net for every packet
> that goes through your tunnel.
I've actually done this with L2TP. The packets coming into the system from
the tunnel are received on one UDP socket in one "struct net", but the
decapsulated packets are received on a "struct net_device" that is in a
different "struct net". No special coding is required -- just move the
tunnel's net_device into another namespace after creation and it works as
expected. Using sk_change_net() would be full of races and is really not
required for the vast majority of use cases.
-ben
^ permalink raw reply
* Re: [BUG] checkpatch.pl with commit 058806007450489bb8f457b275e5cb5c946320c1
From: Joe Perches @ 2012-10-24 21:26 UTC (permalink / raw)
To: jeffrey.t.kirsher, Andrew Morton; +Cc: netdev, LKML
In-Reply-To: <1351111870.1917.4.camel@jtkirshe-mobl>
On Wed, 2012-10-24 at 13:51 -0700, Jeff Kirsher wrote:
> On Wed, 2012-10-24 at 07:12 -0700, Joe Perches wrote:
> > On Wed, 2012-10-24 at 04:00 -0700, Jeff Kirsher wrote:
> > > With the recent commit to checkpatch.pl:
> > >
> > > commit 058806007450489bb8f457b275e5cb5c946320c1
> > > Author: Joe Perches <joe@perches.com>
> > > Date: Thu Oct 4 17:13:35 2012 -0700
> > >
> > > checkpatch: check networking specific block comment style
> > >
> > > We are seeing false positive warnings. Here is an example of the
> > > code the would generate a false warning:
> > >
> > > #define foo 0x0000 /* foo comment */
> > >
> > > checkpatch.pl generates a warnings that the */ should be on a separate
> > > line, which in this case is incorrect.
> >
> > Sorry 'bout that. I believe it's fixed by:
> > https://lkml.org/lkml/2012/10/14/267
> >
>
> Yes, I confirm that the patch in the link you provided solves the issue
> I was seeing. Thanks, has the patch been accepted yet? I see it is not
> in Dave's NET tree as of yet.
Andrew Morton generally picks up my checkpatch twiddles.
It's in -next as of next-20121024.
commit db64ad0e6f55197bc3794bef007a25f2db4760fb
^ permalink raw reply
* [PATCH] qmi_wwan/cdc_ether: move Novatel 551 and E362 to qmi_wwan
From: Dan Williams @ 2012-10-24 22:10 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, linux-usb, netdev
In-Reply-To: <87objr659w.fsf@nemi.mork.no>
These devices provide QMI and ethernet functionality via a standard CDC
ethernet descriptor. But when driven by cdc_ether, the QMI
functionality is unavailable because only cdc_ether can claim the USB
interface. Thus blacklist the devices in cdc_ether and add their IDs to
qmi_wwan, which enables both QMI and ethernet simultaneously.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
Greg: CC-ed to linux-usb@ for visibility but should probably go through davem
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index a03de71..d012982 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -592,6 +592,32 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* Novatel USB551L and MC551 - handled by qmi_wwan */
+{
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_PRODUCT
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = NOVATEL_VENDOR_ID,
+ .idProduct = 0xB001,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = 0,
+},
+
+/* Novatel E362 - handled by qmi_wwan */
+{
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_PRODUCT
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = NOVATEL_VENDOR_ID,
+ .idProduct = 0x9010,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
@@ -604,21 +630,6 @@ static const struct usb_device_id products [] = {
* because of bugs/quirks in a given product (like Zaurus, above).
*/
{
- /* Novatel USB551L */
- /* This match must come *before* the generic CDC-ETHER match so that
- * we get FLAG_WWAN set on the device, since it's descriptors are
- * generic CDC-ETHER.
- */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0xB001,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
- .driver_info = (unsigned long)&wwan_info,
-}, {
/* ZTE (Vodafone) K3805-Z */
.match_flags = USB_DEVICE_ID_MATCH_VENDOR
| USB_DEVICE_ID_MATCH_PRODUCT
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 6883c37..05fd4a1 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -369,6 +369,20 @@ static const struct usb_device_id products[] = {
USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Novatel USB551L and MC551 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0xb001,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Novatel E362 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0x9010,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
^ permalink raw reply related
* Re: [PATCH] qmi_wwan/cdc_ether: move Novatel 551 and E362 to qmi_wwan
From: Greg KH @ 2012-10-24 22:21 UTC (permalink / raw)
To: Dan Williams
Cc: Bjørn Mork, Aleksander Morgado,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1351116634.16726.6.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
On Wed, Oct 24, 2012 at 05:10:34PM -0500, Dan Williams wrote:
> These devices provide QMI and ethernet functionality via a standard CDC
> ethernet descriptor. But when driven by cdc_ether, the QMI
> functionality is unavailable because only cdc_ether can claim the USB
> interface. Thus blacklist the devices in cdc_ether and add their IDs to
> qmi_wwan, which enables both QMI and ethernet simultaneously.
>
> Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> Greg: CC-ed to linux-usb@ for visibility but should probably go through davem
Yes, it should go through netdev:
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: qmi-wwan bug
From: Shawn J. Goff @ 2012-10-24 22:28 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev
In-Reply-To: <943c3dc1-8bc7-4678-a6fd-adc5051f331c@email.android.com>
On 10/24/2012 05:19 PM, Bjørn Mork wrote:
>
> "Shawn J. Goff" <shawn.goff@accelecon.com> wrote:
>
>> I've backported qmi-wwan to 2.6.39 (it's here:
>> https://bitbucket.org/accelecon/linux-at91/changesets), and it mostly
>> works, but I've come across a problem. The modem will sometimes stop
>> responding to any qmi data (but the AT commands on the TTY ports keep
>> working). This only happens when there is significant traffic flowing
>> through the device (downloading a large file) while at the same time,
>> AT
>> commands are sent to one of the TTY ports (I first noticed with my own
>> modem query program, but I can reproduce it using microcom to send
>> "ATI\r" in a loop).
> Using the tty ports should be completely independent of any qmi activity from the host perspective. I am tempted to claim this indicates a firmware bug.
>
>> I see this problem with different devices from
>> different manufacturers.
> Which still may use pretty much the same firmware, although a little less likely.
>
>> I've only made it happen on my kernel - I
>> tried
>> on 3.6.2, but it seems to not happen there.
> Good. But I have a feeling that you switched more than just the kernel. Do you see the issue if you run your backport on the same hardware you tested 3.6.2 on?
I just tested my 2.6.39 kernel on the same hardware that had 3.6.2; the
problem is absent there.
>
> > I've also tried using a
>> similar modem that uses a different driver (sierra-net) and that
>> doesn't
>> have the same problem.
> Well, that is an entirely different firmware application and driver, even if the hardware is similar or even identical.
Yes - I wanted to eliminate anything lower (such as usb-net? not sure if
qmi-wwan uses that) from being a suspect contributor to the problem.
>
>> When it is in failure, if I try to ping an address, the system sends
>> out
>> several an ARP requests but gets no response. To get the device to
>> respond again, I have to administratively set the wwan interface down,
>> then up, use libqmi to get the connection going again, then dhcp to get
>>
>> an address.
> Which sounds like the connection died. Does QMI work at this point, or is that dead too?
Looks like qmi works. I can do --nas-get-signal-strength and it gives me
good numbers. --wds-get-packet-service-status returns "Connection
status: '2'"
>
>> I also have some USB traces of the failure and recovery process. I'm
>> not
>> familiar with CDC or QMI, so it's not yet clear to me exactly what's
>> happening, but it looks like the modem just stops sending anything on
>> its QMI endpoint for no reason.
>>
>> How might I dive further into the issue? So far, my next step is to
>> look
>> into CDC and QMI and try to decypher the USB traces. If anyone is
>> interested, I can share a tcpdump or a USB trace.
> I think a test of the backport on the same host hardware you run 3.6.2 on would be the best place to start.
>
> Bjørn
Thanks for your help.
^ permalink raw reply
* FW: You're looking a little Honey Boo Boo in the belly lately.
From: zebrina.livingston @ 2012-10-25 1:13 UTC (permalink / raw)
To: marlena.nowak
In regards to --> http://ww.bit.ly/TeCwV9
Hey, purdy lady! I've been so busy lately. I'm pleased to announce finally, after all these years I took your advice and finally got into shape without ever hitting the gym! I couldn't believe it myself, but the research is solid. I saw it on tv, so it must work pretty well! Go ahead, be skeptical, but when you see me in my bikini, you'll KNOW it works lolol! Okay, gotta run! See you soon!
^ permalink raw reply
* Re: switching network namespace midway
From: Eric W. Biederman @ 2012-10-25 1:37 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: rsa, netdev
In-Reply-To: <20121024212116.GG15034@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> On Wed, Oct 24, 2012 at 02:11:14PM -0700, Eric W. Biederman wrote:
>> rsa <ravi.mlists@gmail.com> writes:
>>
>> > Assuming I have a tunnel interface where two route lookups are done --
>> > one for innter
>> > packet and the other for outer -- do you see any issues in switching
>> > the network
>> > namespace prior to second route lookup (and restore to the original namespace
>> > after the second lookup is done)?
>> >
>> > If so, are there any other calls other than sk_change_net() needed?
>>
>> In general sk_change_net is a bad idea.
>>
>> Most likely what you want to do is simply memorize both struct net's
>> that you care about and perform the routing lookup as appropriate.
>>
>> Certainly you don't want to be calling sk_change_net for every packet
>> that goes through your tunnel.
>
> I've actually done this with L2TP. The packets coming into the system from
> the tunnel are received on one UDP socket in one "struct net", but the
> decapsulated packets are received on a "struct net_device" that is in a
> different "struct net". No special coding is required -- just move the
> tunnel's net_device into another namespace after creation and it works as
> expected. Using sk_change_net() would be full of races and is really not
> required for the vast majority of use cases.
Yes. Although L2TP is not an example of code I would copy. Any other
tunnel would be better. I haven't looked closely at L2TP but it keeps
popping up as a poster child for small little network namespace bugs
that I don't want to think about.
Last I looked to use L2TP it required a magic userspace that I couldn't
find and I haven't cared enough to write. Ben would you be interested
in helping flush out the network namespace bugs out of L2TP?
Eric
^ permalink raw reply
* Re: [PATCH] pch_gbe: fix error handling in pch_gbe_up()
From: David Miller @ 2012-10-25 3:04 UTC (permalink / raw)
To: vfalico; +Cc: netdev, richardcochran, tshimizu818, andy.cress, erwan.velu
In-Reply-To: <1351004074-10225-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Tue, 23 Oct 2012 16:54:34 +0200
> If we fail to allocate rx buffers pool by any reason, we'll just return
> with an error, however we've previously successfully requested an irq. Fix
> this by releasing the irq before returning the error.
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: David Miller @ 2012-10-25 3:06 UTC (permalink / raw)
To: thomas.petazzoni
Cc: kernel, netdev, linux-arm-kernel, jason, andrew, gregory.clement,
alior, maen
In-Reply-To: <1351011300-26964-2-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 23 Oct 2012 18:54:57 +0200
> + u32 cause_rx_tx[CONFIG_NR_CPUS];
Please use per-cpu variables instead of explicitly sized
arrays.
^ permalink raw reply
* Re: [PATCH] NET_VENDOR_TI: make available for am33xx as well
From: David Miller @ 2012-10-25 3:07 UTC (permalink / raw)
To: jacmet; +Cc: netdev, mugunthanvnm
In-Reply-To: <1351030315-4156-1-git-send-email-jacmet@sunsite.dk>
From: Peter Korsgaard <jacmet@sunsite.dk>
Date: Wed, 24 Oct 2012 00:11:55 +0200
> The cpsw/davinci mdio ip cores are present on am33xx, so make NET_VENDOR_TI
> visible for it as well.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH V3 02/21] qlcnic: create seperate file for data path routines
From: David Miller @ 2012-10-25 3:10 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1351031472-731-3-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Tue, 23 Oct 2012 18:30:53 -0400
> +static inline bool qlcnic_82xx_check(struct qlcnic_adapter *adapter)
> +{
> + return (adapter->pdev->device == PCI_DEVICE_ID_QLOGIC_QLE824X) ? 1 : 0;
> +}
"bool" is either "true" or "false", so return "true" or "false" rather
than "1" or "0"
^ 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