* [PATCH 2/4] ARM: dts: imx6q: Add ENET PTP clock pin and clock source
From: Frank Li @ 2012-10-31 4:24 UTC (permalink / raw)
To: lznua, richardcochran, shawn.guo, linux-arm-kernel, netdev, davem
Cc: Frank Li
Add ENET 1588 clock input pin
MX6Q_PAD_GPIO_16__ENET_ANATOP_ETHERNET_REF_OUT
and anatop PLL8 clock source for ENET
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
arch/arm/boot/dts/imx6q.dtsi | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f3990b0..3290e61 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -580,6 +580,7 @@
66 0x1b0b0 /* MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2 */
70 0x1b0b0 /* MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3 */
48 0x1b0b0 /* MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL */
+ 1033 0x4001b0a8 /* MX6Q_PAD_GPIO_16__ENET_ANATOP_ETHERNET_REF_OUT*/
>;
};
@@ -833,8 +834,8 @@
compatible = "fsl,imx6q-fec";
reg = <0x02188000 0x4000>;
interrupts = <0 118 0x04 0 119 0x04>;
- clocks = <&clks 117>, <&clks 117>;
- clock-names = "ipg", "ahb";
+ clocks = <&clks 117>, <&clks 117>, <&clks 177>;
+ clock-names = "ipg", "ahb", "ptp";
status = "disabled";
};
--
1.7.1
^ permalink raw reply related
* [PATCH 1/4] net: fec: move fec_enet_private to header file
From: Frank Li @ 2012-10-31 4:24 UTC (permalink / raw)
To: lznua, richardcochran, shawn.guo, linux-arm-kernel, netdev, davem
Cc: Frank Li
A new file fec_ptp.c will use fec_enet_private to support 1588 PTP
move such structure to common header file fec.h
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec.c | 73 ------------------------------
drivers/net/ethernet/freescale/fec.h | 81 ++++++++++++++++++++++++++++++++++
2 files changed, 81 insertions(+), 73 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index fffd205..d0e1b33 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -140,21 +140,6 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#endif
#endif /* CONFIG_M5272 */
-/* The number of Tx and Rx buffers. These are allocated from the page
- * pool. The code may assume these are power of two, so it it best
- * to keep them that size.
- * We don't need to allocate pages for the transmitter. We just use
- * the skbuffer directly.
- */
-#define FEC_ENET_RX_PAGES 8
-#define FEC_ENET_RX_FRSIZE 2048
-#define FEC_ENET_RX_FRPPG (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
-#define RX_RING_SIZE (FEC_ENET_RX_FRPPG * FEC_ENET_RX_PAGES)
-#define FEC_ENET_TX_FRSIZE 2048
-#define FEC_ENET_TX_FRPPG (PAGE_SIZE / FEC_ENET_TX_FRSIZE)
-#define TX_RING_SIZE 16 /* Must be power of two */
-#define TX_RING_MOD_MASK 15 /* for this to work */
-
#if (((RX_RING_SIZE + TX_RING_SIZE) * 8) > PAGE_SIZE)
#error "FEC: descriptor ring size constants too large"
#endif
@@ -179,9 +164,6 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#define PKT_MINBUF_SIZE 64
#define PKT_MAXBLR_SIZE 1520
-/* This device has up to three irqs on some platforms */
-#define FEC_IRQ_NUM 3
-
/*
* The 5270/5271/5280/5282/532x RX control register also contains maximum frame
* size bits. Other FEC hardware does not, so we need to take that into
@@ -194,61 +176,6 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#define OPT_FRAME_SIZE 0
#endif
-/* The FEC buffer descriptors track the ring buffers. The rx_bd_base and
- * tx_bd_base always point to the base of the buffer descriptors. The
- * cur_rx and cur_tx point to the currently available buffer.
- * The dirty_tx tracks the current buffer that is being sent by the
- * controller. The cur_tx and dirty_tx are equal under both completely
- * empty and completely full conditions. The empty/ready indicator in
- * the buffer descriptor determines the actual condition.
- */
-struct fec_enet_private {
- /* Hardware registers of the FEC device */
- void __iomem *hwp;
-
- struct net_device *netdev;
-
- struct clk *clk_ipg;
- struct clk *clk_ahb;
-
- /* The saved address of a sent-in-place packet/buffer, for skfree(). */
- unsigned char *tx_bounce[TX_RING_SIZE];
- struct sk_buff* tx_skbuff[TX_RING_SIZE];
- struct sk_buff* rx_skbuff[RX_RING_SIZE];
- ushort skb_cur;
- ushort skb_dirty;
-
- /* CPM dual port RAM relative addresses */
- dma_addr_t bd_dma;
- /* Address of Rx and Tx buffers */
- struct bufdesc *rx_bd_base;
- struct bufdesc *tx_bd_base;
- /* The next free ring entry */
- struct bufdesc *cur_rx, *cur_tx;
- /* The ring entries to be free()ed */
- struct bufdesc *dirty_tx;
-
- uint tx_full;
- /* hold while accessing the HW like ringbuffer for tx/rx but not MAC */
- spinlock_t hw_lock;
-
- struct platform_device *pdev;
-
- int opened;
- int dev_id;
-
- /* Phylib and MDIO interface */
- struct mii_bus *mii_bus;
- struct phy_device *phy_dev;
- int mii_timeout;
- uint phy_speed;
- phy_interface_t phy_interface;
- int link;
- int full_duplex;
- struct completion mdio_done;
- int irq[FEC_IRQ_NUM];
-};
-
/* FEC MII MMFR bits definition */
#define FEC_MMFR_ST (1 << 30)
#define FEC_MMFR_OP_READ (2 << 28)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 8408c62..e803812 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -147,6 +147,87 @@ struct bufdesc {
#define BD_ENET_TX_CSL ((ushort)0x0001)
#define BD_ENET_TX_STATS ((ushort)0x03ff) /* All status bits */
+/*enhanced buffer desciptor control/status used by Ethernet transmit*/
+#define BD_ENET_TX_INT 0x40000000
+#define BD_ENET_TX_TS 0x20000000
+
+
+/* This device has up to three irqs on some platforms */
+#define FEC_IRQ_NUM 3
+
+/* The number of Tx and Rx buffers. These are allocated from the page
+ * pool. The code may assume these are power of two, so it it best
+ * to keep them that size.
+ * We don't need to allocate pages for the transmitter. We just use
+ * the skbuffer directly.
+ */
+
+#define FEC_ENET_RX_PAGES 8
+#define FEC_ENET_RX_FRSIZE 2048
+#define FEC_ENET_RX_FRPPG (PAGE_SIZE / FEC_ENET_RX_FRSIZE)
+#define RX_RING_SIZE (FEC_ENET_RX_FRPPG * FEC_ENET_RX_PAGES)
+#define FEC_ENET_TX_FRSIZE 2048
+#define FEC_ENET_TX_FRPPG (PAGE_SIZE / FEC_ENET_TX_FRSIZE)
+#define TX_RING_SIZE 16 /* Must be power of two */
+#define TX_RING_MOD_MASK 15 /* for this to work */
+
+#define BD_ENET_RX_INT 0x00800000
+#define BD_ENET_RX_PTP ((ushort)0x0400)
+
+/* The FEC buffer descriptors track the ring buffers. The rx_bd_base and
+ * tx_bd_base always point to the base of the buffer descriptors. The
+ * cur_rx and cur_tx point to the currently available buffer.
+ * The dirty_tx tracks the current buffer that is being sent by the
+ * controller. The cur_tx and dirty_tx are equal under both completely
+ * empty and completely full conditions. The empty/ready indicator in
+ * the buffer descriptor determines the actual condition.
+ */
+struct fec_enet_private {
+ /* Hardware registers of the FEC device */
+ void __iomem *hwp;
+
+ struct net_device *netdev;
+
+ struct clk *clk_ipg;
+ struct clk *clk_ahb;
+
+ /* The saved address of a sent-in-place packet/buffer, for skfree(). */
+ unsigned char *tx_bounce[TX_RING_SIZE];
+ struct sk_buff *tx_skbuff[TX_RING_SIZE];
+ struct sk_buff *rx_skbuff[RX_RING_SIZE];
+ ushort skb_cur;
+ ushort skb_dirty;
+
+ /* CPM dual port RAM relative addresses */
+ dma_addr_t bd_dma;
+ /* Address of Rx and Tx buffers */
+ struct bufdesc *rx_bd_base;
+ struct bufdesc *tx_bd_base;
+ /* The next free ring entry */
+ struct bufdesc *cur_rx, *cur_tx;
+ /* The ring entries to be free()ed */
+ struct bufdesc *dirty_tx;
+
+ uint tx_full;
+ /* hold while accessing the HW like ringbuffer for tx/rx but not MAC */
+ spinlock_t hw_lock;
+
+ struct platform_device *pdev;
+
+ int opened;
+ int dev_id;
+
+ /* Phylib and MDIO interface */
+ struct mii_bus *mii_bus;
+ struct phy_device *phy_dev;
+ int mii_timeout;
+ uint phy_speed;
+ phy_interface_t phy_interface;
+ int link;
+ int full_duplex;
+ struct completion mdio_done;
+ int irq[FEC_IRQ_NUM];
+};
/****************************************************************************/
#endif /* FEC_H */
--
1.7.1
^ permalink raw reply related
* [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: Frank Li @ 2012-10-31 4:24 UTC (permalink / raw)
To: lznua, richardcochran, shawn.guo, linux-arm-kernel, netdev, davem
Cc: Frank Li
This patch series enables hardware time stamping and a PTP hardware clock
for mx6 ENET controller.
Frank Li (4):
net: fec: move fec_enet_private to header file
ARM: dts: imx6q: Add ENET PTP clock pin and clock source
ARM: imx6q: Set enet tx reference clk from anatop to support 1588
FEC: Add time stamping code and a PTP hardware clock
arch/arm/boot/dts/imx6q.dtsi | 5 +-
arch/arm/mach-imx/mach-imx6q.c | 12 +
drivers/net/ethernet/freescale/Kconfig | 9 +
drivers/net/ethernet/freescale/Makefile | 1 +
drivers/net/ethernet/freescale/fec.c | 161 +++++++------
drivers/net/ethernet/freescale/fec.h | 119 +++++++++
drivers/net/ethernet/freescale/fec_ptp.c | 386 ++++++++++++++++++++++++++++++
7 files changed, 617 insertions(+), 76 deletions(-)
create mode 100644 drivers/net/ethernet/freescale/fec_ptp.c
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 3:48 UTC (permalink / raw)
To: Al Viro
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, Steven Rostedt,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w, Sasha Levin,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20121031032431.GG2616-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
On Tue, Oct 30, 2012 at 8:24 PM, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
>
> Oh, well... there go my blackmail plans ;-) Seriously, though, I'm at loss
> regarding several embedded architectures - arch/score, in particular,
> seems to be completely orphaned.
Don't worry about it. Do a best-effort, and if nobody ever reacts
about some odd-ball architecture, whatever.
We won't start deleting architectures over something like this, but it
might be another sign down the road that some arch code can be removed
entirely.
So it's not arch/score I'd worry about. It's all the *other* architectures..
Linus
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Al Viro @ 2012-10-31 3:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Sasha Levin, Tejun Heo,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mingo-X9Un+BFzKDI,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <CA+55aFyU30Z2JS9XJ4KTordbAw-2EBVD7xF4K3eAhKVRCJw8YA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Oct 30, 2012 at 07:48:19PM -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2012 at 7:24 PM, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org> wrote:
> >
> > BTW, how serious have you been back at KS when you were talking about
> > pull requests killing a thousand of lines of code being acceptable
> > at any point in the cycle?
>
> Well... I'm absolutely a lot more open to pull requests that kill code
> than not, but I have to admit to being a bit more worried about stuff
> like your execve/fork patches that touch very low-level code.
>
> So I think I'll punt that for 3.8 anyway.
Oh, well... there go my blackmail plans ;-) Seriously, though, I'm at loss
regarding several embedded architectures - arch/score, in particular,
seems to be completely orphaned. As far as I can see, it's
* abandoned by hw vendor (seems like they were planning to push
it game consoles, but that was just before the recession, and...)
* abandoned by primary maintainer, who isn't employed by said
hw vendor anymore, so his old address had been bouncy for several years.
He had bothered to update it in gcc tree, but hadn't been active there
either for almost as long. And new address in gcc tree is of form
<name>+gcc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, so using it for kernel-related mail would seem to
be a lousy idea.
* the second maintainer seems to be nearly MIA as well - all I can
find is Acked-by on one commit. Cc'ed on the kernel_execve() thread, but...
no signs of life whatsoever.
* a lot of asm glue is in "apparently never worked" state, starting
with ptrace hookup (it's clearly started its life as a mips clone, but uses
different registers for passing return value, etc. TIF_SYSCALL_TRACE side of
that thing still assumes MIPS ABI *and* is suffering obvious bitrot)
Sigh...
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-31 3:05 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <CACVXFVMRJPfPSC_4ZamqfYUSYNsMEVYXMFmcs26T=4MdB_Kntw@mail.gmail.com>
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
>
> Yes, it is probable, and sounds like similar with 'root_wait' problem, see
> prepare_namespace(): init/do_mounts.c, so looks no good solution
> for the problem, and maybe we have to set the flag always before resetting
> usb device.
The below idea may help the problem which 'memalloc_noio' flag isn't set during
usb_reset_device().
- for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
inside usb_stor_probe2() and uas_probe(), and call
pm_runtime_set_memalloc_noio(false) inside uas_disconnect()
and usb_stor_disconnect().
- for usb network device, register_netdev() is always called inside usb
interface's probe(), looks no such problem.
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 2:48 UTC (permalink / raw)
To: Al Viro
Cc: Steven Rostedt, Sasha Levin, Tejun Heo, akpm, linux-kernel,
linux-mm, paul.gortmaker, davem, mingo, ebiederm, aarcange,
ericvh, netdev, josh, eric.dumazet, mathieu.desnoyers, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <20121031022418.GE2616@ZenIV.linux.org.uk>
On Tue, Oct 30, 2012 at 7:24 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> BTW, how serious have you been back at KS when you were talking about
> pull requests killing a thousand of lines of code being acceptable
> at any point in the cycle?
Well... I'm absolutely a lot more open to pull requests that kill code
than not, but I have to admit to being a bit more worried about stuff
like your execve/fork patches that touch very low-level code.
So I think I'll punt that for 3.8 anyway.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next 3/8] bridge: implement BPDU blocking
From: Cong Wang @ 2012-10-31 2:38 UTC (permalink / raw)
To: netdev
In-Reply-To: <20121030005835.462418417@vyatta.com>
On Tue, 30 Oct 2012 at 00:57 GMT, Stephen Hemminger <shemminger@vyatta.com> wrote:
> --- a/net/bridge/br_stp_bpdu.c 2012-10-29 17:07:08.005982838 -0700
> +++ b/net/bridge/br_stp_bpdu.c 2012-10-29 17:31:14.327457434 -0700
> @@ -170,6 +170,13 @@ void br_stp_rcv(const struct stp_proto *
> if (!ether_addr_equal(dest, br->group_addr))
> goto out;
>
> + if (p->flags & BR_BPDU_GUARD) {
> + br_notice(br, "BPDU received on blocked port %u(%s)\n",
> + (unsigned int) p->port_no, p->dev->name);
net_ratelimit() ?
^ permalink raw reply
* [PATCH] veth: allow changing the mac address while interface is up
From: Hannes Frederic Sowa @ 2012-10-31 2:22 UTC (permalink / raw)
To: netdev
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
drivers/net/veth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 5852361..9f87718 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -264,6 +264,7 @@ static void veth_setup(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
dev->netdev_ops = &veth_netdev_ops;
dev->ethtool_ops = &veth_ethtool_ops;
^ permalink raw reply related
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Al Viro @ 2012-10-31 2:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Sasha Levin, Tejun Heo, akpm, linux-kernel,
linux-mm, paul.gortmaker, davem, mingo, ebiederm, aarcange,
ericvh, netdev, josh, eric.dumazet, mathieu.desnoyers, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <CA+55aFzFMrOUwdHHJ5-YUtEzTHGvdRosQc+K+trjub0K-w-D3A@mail.gmail.com>
On Tue, Oct 30, 2012 at 06:25:46PM -0700, Linus Torvalds wrote:
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-next.
BTW, how serious have you been back at KS when you were talking about
pull requests killing a thousand of lines of code being acceptable
at any point in the cycle? Because right now I'm sitting on a pile that
removes 2-3 times as much (~-2KLoC for stuff that got considerable
testing for most of the architectures, -3KLoC if I include fork/clone/vfork
unification series) and seeing how maintainers of a bunch of embedded
architectures seem to be MIA... The idea of saying "screw them" and sending
a pull request becomes more and more tempting every day ;-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 2:23 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, Steven Rostedt,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+1xoqd8vAn+N1JuhpXRjSr74OPtnnw_1UBhf8=c4WDC3jOirw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Oct 30, 2012 at 6:36 PM, Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I can either rebase that on top of mainline, or we can ask maintainers
> to take it to their own trees if you take only 01/16 into mainline.
> What would you prefer?
I don't really care deeply. The only reason to merge it now would be
to avoid any pain with it during the next merge window. Just taking
01/16 might be the sanest way to do that, then the rest can trickle in
independently at their own leisure.
Linus
^ permalink raw reply
* Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-31 2:08 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <2504263.kbM6W9JoH9@linux-lqwf.site>
On Wed, Oct 31, 2012 at 12:30 AM, Oliver Neukum <oneukum@suse.de> wrote:
>> If the USB mass-storage device is being reseted, the flag should be set
>> already generally. If the flag is still unset, that means the disk/network
>> device isn't added into system(or removed just now), so memory allocation
>> with block I/O should be allowed during the reset. Looks it isn't one problem,
>> isn't it?
>
> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
Yes, it is probable, and sounds like similar with 'root_wait' problem, see
prepare_namespace(): init/do_mounts.c, so looks no good solution
for the problem, and maybe we have to set the flag always before resetting
usb device.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-10-31 1:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sasha Levin, Tejun Heo, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mingo-X9Un+BFzKDI,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <CA+55aFzFMrOUwdHHJ5-YUtEzTHGvdRosQc+K+trjub0K-w-D3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2012-10-30 at 18:25 -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
> >
> > ({ \
> > sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
> > })
> >
> > Is the better way to go. We are C programmers, we like to see the ?: on
> > a single line if possible. The way you have it, looks like three
> > statements run consecutively.
>
> If we're C programmers, why use the non-standard statement-expression
> at all? And split it onto three lines when it's just a single one?
I like the blue color over the pink. Anyway, I was just expressing an
opinion and really didn't care if it was changed or not.
>
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-next.
I would think this change is a bit too big for an -rc4 release, but
you're the boss. I've already given my ack for my code that this set
touches. Let it go to Stephen's repo then.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-10-31 1:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Tejun Heo, akpm, linux-kernel, linux-mm,
paul.gortmaker, davem, mingo, ebiederm, aarcange, ericvh, netdev,
josh, eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel,
neilb, ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec,
jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs,
dev, rds-devel, lw
In-Reply-To: <CA+55aFzFMrOUwdHHJ5-YUtEzTHGvdRosQc+K+trjub0K-w-D3A@mail.gmail.com>
Hi Linus,
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-next.
Yup, I switched to using -next because I've been running my
trinity/KVM tools tests with it.
I can either rebase that on top of mainline, or we can ask maintainers
to take it to their own trees if you take only 01/16 into mainline.
What would you prefer?
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 1:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sasha Levin, Tejun Heo, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mingo-X9Un+BFzKDI,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1351646186.4004.41.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
>
> ({ \
> sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
> })
>
> Is the better way to go. We are C programmers, we like to see the ?: on
> a single line if possible. The way you have it, looks like three
> statements run consecutively.
If we're C programmers, why use the non-standard statement-expression
at all? And split it onto three lines when it's just a single one?
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-10-31 1:16 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+1xoqeCKS2E4TWCUCELjDqV2pWS4v6EyV6K-=w-GRi_K6quiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2012-10-30 at 20:33 -0400, Sasha Levin wrote:
> On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > Hello,
> >
> > Just some nitpicks.
> >
> > On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> >> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> >> +#define hash_min(val, bits) \
> >> +({ \
> >> + sizeof(val) <= 4 ? \
> >> + hash_32(val, bits) : \
> >> + hash_long(val, bits); \
> >> +})
> >
> > Doesn't the above fit in 80 column. Why is it broken into multiple
> > lines? Also, you probably want () around at least @val. In general,
> > it's a good idea to add () around any macro argument to avoid nasty
> > surprises.
>
> It was broken to multiple lines because it looks nicer that way (IMO).
>
> If we wrap it with () it's going to go over 80, so it's going to stay
> broken down either way :)
({ \
sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
})
Is the better way to go. We are C programmers, we like to see the ?: on
a single line if possible. The way you have it, looks like three
statements run consecutively.
-- Steve
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-10-31 1:15 UTC (permalink / raw)
To: Jim Rees
Cc: Tejun Heo, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <20121031005128.GA30251-63aXycvo3TyHXe+LvDLADg@public.gmane.org>
On Tue, Oct 30, 2012 at 8:51 PM, Jim Rees <rees-63aXycvo3TyHXe+LvDLADg@public.gmane.org> wrote:
> Sasha Levin wrote:
>
> On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > Hello,
> >
> > Just some nitpicks.
> >
> > On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> >> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> >> +#define hash_min(val, bits) \
> >> +({ \
> >> + sizeof(val) <= 4 ? \
> >> + hash_32(val, bits) : \
> >> + hash_long(val, bits); \
> >> +})
> >
> > Doesn't the above fit in 80 column. Why is it broken into multiple
> > lines? Also, you probably want () around at least @val. In general,
> > it's a good idea to add () around any macro argument to avoid nasty
> > surprises.
>
> It was broken to multiple lines because it looks nicer that way (IMO).
>
> If we wrap it with () it's going to go over 80, so it's going to stay
> broken down either way :)
>
> I would prefer the body be all on one line too. But shouldn't this be a
> static inline function?
We want sizeof(val), which wouldn't work in a static inline. We can
either wrap a static inline __hash_min() with a macro and pass that
size to it, but that's quite an overkill here, or we can add a size
parameter to hash_min(), but it would look awkward considering how
hash_32()/hash_64()/hash_long() look like.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Jim Rees @ 2012-10-31 0:51 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+1xoqeCKS2E4TWCUCELjDqV2pWS4v6EyV6K-=w-GRi_K6quiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) \
>> +({ \
>> + sizeof(val) <= 4 ? \
>> + hash_32(val, bits) : \
>> + hash_long(val, bits); \
>> +})
>
> Doesn't the above fit in 80 column. Why is it broken into multiple
> lines? Also, you probably want () around at least @val. In general,
> it's a good idea to add () around any macro argument to avoid nasty
> surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
I would prefer the body be all on one line too. But shouldn't this be a
static inline function?
^ permalink raw reply
* Re: [PATCH 1/1] net: fix compile warning in af_unix.c
From: jing wang @ 2012-10-31 0:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Eric Dumazet, Al Viro, Pavel Emelyanov, netdev
In-Reply-To: <20121030070040.5bdf0f0a@nehalam.linuxnetplumber.net>
于 2012年10月30日 22:00, Stephen Hemminger 写道:
> On Tue, 30 Oct 2012 15:16:36 +0800
> Jing Wang <windsdaemon@gmail.com> wrote:
>
>> This patch fix some compile warning as follows:
>> net/unix/af_unix.c: In function 'unix_bind':
>> net/unix/af_unix.c:895: warning: 'path.dentry' may be used uninitialized in this function
>> net/unix/af_unix.c:895: warning: 'path.mnt' may be used uninitialized in this function
>>
>> Signed-off-by: Jing Wang <windsdaemon@gmail.com>
>> ---
>> net/unix/af_unix.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 5b5c876..9f710ac 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -895,6 +895,8 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
>> struct path path;
>> umode_t mode = S_IFSOCK |
>> (SOCK_INODE(sock)->i_mode & ~current_umask());
>> + path.mnt = NULL;
>> + path.dentry = NULL;
>> err = unix_mknod(sun_path, mode, &path);
>> if (err) {
>> if (err == -EEXIST)
> I appreciate the effort to silence warnings. But this warning is a false
> positive that only occurs on some versions of Gcc. With gcc 4.7 the
> warning does not occur.
>
> The general consensus has been NOT to do initializations or other changes
> if the problem is due to Gcc bug.
>
Thanks for you review, you're right, the version of my gcc is 4.4.6 !
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-10-31 0:33 UTC (permalink / raw)
To: Tejun Heo
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <20121030214257.GB2681@htj.dyndns.org>
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) \
>> +({ \
>> + sizeof(val) <= 4 ? \
>> + hash_32(val, bits) : \
>> + hash_long(val, bits); \
>> +})
>
> Doesn't the above fit in 80 column. Why is it broken into multiple
> lines? Also, you probably want () around at least @val. In general,
> it's a good idea to add () around any macro argument to avoid nasty
> surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
Thanks,
Sasha
> Looks good to me otherwise.
>
> Reviewed-by: Tejun Heo <tj@kernel.org>
>
> Thanks.
>
> --
> tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next v4 0/7] Multiqueue support in tuntap
From: Stephen Hemminger @ 2012-10-30 23:52 UTC (permalink / raw)
To: Jason Wang
Cc: davem, netdev, linux-kernel, mst, maxk, haixiao, ernesto.martin,
krkumar2, edumazet
In-Reply-To: <1351488964-11109-1-git-send-email-jasowang@redhat.com>
I am testing BQL for tuntap.
It wouldn't be hard to do BQL in the multi-queue version.
^ permalink raw reply
* Payment Sent!!
From: Western Union Transfer @ 2012-10-30 22:05 UTC (permalink / raw)
To: netdev
We write to inform you that we have transferred $400,000 dollars. deposited for transfer to you by one MR Bernard Harry from BLACKBERRY MOBILE COMPANY for transfer as a winning prize from the promotion lottery held by the communication company to encourage usage and appreciate already users of their product.
The money is available for pick up by receiver(you) to be cashed on daily installment of $10,000 for 40days. We tried calling to give you the information over the phone but we could not reach you so we decided to email you the information to pick up the first $10,000 already transferred to you. for you to be able to pick the first payment,
You will have to pay $250 to get it re-activated in your name for you to start picking up your money because we de-activate the transaction for security reason, by making the status to display pick up.
Use this link to track the below information
https://wumt.westernunion.com/asp/orderStatus.asp?country=global
Sender's Fist name: Ronald
Sender's Last Name: Mundy
MTCN: 6605740058
Question: Who Is Great
Answer: God
Amount: $10,000.00USD
Thanks
Best Regards
Mr.Mcferrin Phoenix .
+60169162934
western union Office,
MALAYSIA OFFICE.
Western Union® Money Transfer
^ permalink raw reply
* [PATCH net] tcp: Fix double sizeof in new tcp_metrics code
From: Julian Anastasov @ 2012-10-30 22:03 UTC (permalink / raw)
To: netdev
Fix double sizeof when parsing IPv6 address from
user space because it breaks get/del by specific IPv6 address.
Problem noticed by David Binderman:
https://bugzilla.kernel.org/show_bug.cgi?id=49171
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/tcp_metrics.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 4c752a6..53bc584 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -864,7 +864,7 @@ static int parse_nl_addr(struct genl_info *info, struct inetpeer_addr *addr,
}
a = info->attrs[TCP_METRICS_ATTR_ADDR_IPV6];
if (a) {
- if (nla_len(a) != sizeof(sizeof(struct in6_addr)))
+ if (nla_len(a) != sizeof(struct in6_addr))
return -EINVAL;
addr->family = AF_INET6;
memcpy(addr->addr.a6, nla_data(a), sizeof(addr->addr.a6));
--
1.7.3.4
^ permalink raw reply related
* [PATCH] ethtool: Support et131x registers in -d
From: Mark Einon @ 2012-10-30 21:57 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, Mark Einon
The et131x register set contains useful details of RX/TX queues for
the device. This dumps them with the -d option.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
Makefile.am | 2 +-
et131x.c | 120 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ethtool.c | 1 +
internal.h | 3 ++
4 files changed, 125 insertions(+), 1 deletion(-)
create mode 100644 et131x.c
diff --git a/Makefile.am b/Makefile.am
index 1b96b98..e33f71f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,7 @@ EXTRA_DIST = LICENSE ethtool.8 ethtool.spec.in aclocal.m4 ChangeLog autogen.sh
sbin_PROGRAMS = ethtool
ethtool_SOURCES = ethtool.c ethtool-copy.h internal.h net_tstamp-copy.h \
- amd8111e.c de2104x.c e100.c e1000.c igb.c \
+ amd8111e.c de2104x.c e100.c e1000.c et131x.c igb.c \
fec_8xx.c ibm_emac.c ixgb.c ixgbe.c natsemi.c \
pcnet32.c realtek.c tg3.c marvell.c vioc.c \
smsc911x.c at76c50x-usb.c sfc.c stmmac.c \
diff --git a/et131x.c b/et131x.c
new file mode 100644
index 0000000..46aaa71
--- /dev/null
+++ b/et131x.c
@@ -0,0 +1,120 @@
+#include <stdio.h>
+#include <string.h>
+#include "internal.h"
+
+int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ u32 *reg = (u32 *)regs->data;
+
+ fprintf(stdout, "PHY Registers\n");
+ fprintf(stdout, "0x0, Basic Control Reg = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, Basic Status Reg = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, PHY identifier 1 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, PHY identifier 2 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, Auto Neg Advertisement = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, Auto Neg L Partner Ability = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, Auto Neg Expansion = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, 1000T Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, 1000T Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xB, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xC, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xD, MMD Access Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xE, MMD access Data = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xF, Extended Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x10, Phy Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x11, Phy Data = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x12, MPhy Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x13, Phy Loopback Control1 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x14, Phy Loopback Control2 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x15, Register Management = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x16, Phy Config = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x17, Phy Phy Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x18, Phy Interrupt Mask = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x19, Phy Interrupt Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1A, Phy Phy Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1B, Phy LED1 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1C, Phy LED2 = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "JAGCore Global Registers\n");
+ fprintf(stdout, "0x0, TXQ Start Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, TXQ End Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, RXQ Start Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, RXQ End Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, Power Management Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, Interrupt Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, Interrupt Mask = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, Int Alias Clear Mask = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Int Status Alias = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, Software Reset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, SLV Timer = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xB, MSI Config = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xC, Loopback = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xD, Watchdog Timer = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "TXDMA Registers\n");
+ fprintf(stdout, "0x0, Control Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, Packet Ring Base Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, Packet Ring Base Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, Packet Ring Num Descrs = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, TX Queue Write Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, TX Queue Write Address Ext = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, TX Queue Read Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, Status Writeback Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Status Writeback Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, Service Request = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, Service Complete = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xB, Cache Read Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xC, Cache Write Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xD, TXDMA Error = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xE, Descriptor Abort Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xF, Payload Abort Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x10, Writeback Abort Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x11, Descriptor Timeout Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x12, Payload Timeout Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x13, Writeback Timeout Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x14, Descriptor Error Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x15, Payload Error Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x16, Writeback Error Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x17, Dropped TLP Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x18, New service Complete = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1A, Ethernet Packet Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "RXDMA Registers\n");
+ fprintf(stdout, "0x0, Control Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, Writeback Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, Writeback Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, Num Packets Done = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, Max Packet Time = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, RX Queue Read Addr = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, RX Queue Read Address Ext = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, RX Queue Write Addr = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Packet Ring Base Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, Packet Ring Base Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, Packet Ring Num Descrs = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xE, Packet Ring Avail Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xF, Packet Ring Full Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x10, Packet Ring Access Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x11, Packet Ring Min Descrip = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x12, FBR0 Address (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x13, FBR0 Address (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x14, FBR0 Num Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x15, FBR0 Available Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x16, FBR0 Full Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x17, FBR0 Read Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x18, FBR0 Minimum Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x19, FBR1 Address (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1A, FBR1 Address (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1B, FBR1 Num Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1C, FBR1 Available Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1D, FBR1 Full Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1E, FBR1 Read Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1F, FBR1 Minimum Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+ return 0;
+}
+
diff --git a/ethtool.c b/ethtool.c
index f3649e2..7c1bd22 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -888,6 +888,7 @@ static const struct {
{ "sfc", sfc_dump_regs },
{ "st_mac100", st_mac100_dump_regs },
{ "st_gmac", st_gmac_dump_regs },
+ { "et131x", et131x_dump_regs },
};
void dump_hex(FILE *file, const u8 *data, int len, int offset)
diff --git a/internal.h b/internal.h
index deb7868..4f96fd5 100644
--- a/internal.h
+++ b/internal.h
@@ -238,6 +238,9 @@ int st_mac100_dump_regs(struct ethtool_drvinfo *info,
struct ethtool_regs *regs);
int st_gmac_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+/* Et131x ethernet controller */
+int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
/* Rx flow classification */
int rxclass_parse_ruleopts(struct cmd_context *ctx,
struct ethtool_rx_flow_spec *fsp);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-10-30 21:42 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <1351622772-16400-1-git-send-email-levinsasha928@gmail.com>
Hello,
Just some nitpicks.
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> +#define hash_min(val, bits) \
> +({ \
> + sizeof(val) <= 4 ? \
> + hash_32(val, bits) : \
> + hash_long(val, bits); \
> +})
Doesn't the above fit in 80 column. Why is it broken into multiple
lines? Also, you probably want () around at least @val. In general,
it's a good idea to add () around any macro argument to avoid nasty
surprises.
Looks good to me otherwise.
Reviewed-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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