Netdev List
 help / color / mirror / Atom feed
* [PATCHv2 7/9] macb: support statistics for GEM devices
From: Jamie Iles @ 2011-03-15 10:14 UTC (permalink / raw)
  To: netdev, linux-arm-kernel; +Cc: nicolas.ferre, plagnioj, Jamie Iles
In-Reply-To: <1300184096-13937-1-git-send-email-jamie@jamieiles.com>

GEM devices have a different number of statistics registers and they
are at a different offset to MACB devices.  Make the statistics
collection method dependent on device type.

Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
 drivers/net/macb.c |   57 +++++++++++++++++++++++++++++++++++++++++++++++++--
 drivers/net/macb.h |   54 ++++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 107 insertions(+), 4 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index f3da878..0598373 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -282,8 +282,8 @@ err_out:
 static void macb_update_stats(struct macb *bp)
 {
 	u32 __iomem *reg = bp->regs + MACB_PFR;
-	u32 *p = &bp->hw_stats.rx_pause_frames;
-	u32 *end = &bp->hw_stats.tx_pause_frames + 1;
+	u32 *p = &bp->hw_stats.macb.rx_pause_frames;
+	u32 *end = &bp->hw_stats.macb.tx_pause_frames + 1;
 
 	WARN_ON((unsigned long)(end - p - 1) != (MACB_TPF - MACB_PFR) / 4);
 
@@ -1029,11 +1029,62 @@ static int macb_close(struct net_device *dev)
 	return 0;
 }
 
+static void gem_update_stats(struct macb *bp)
+{
+	u32 __iomem *reg = bp->regs + GEM_OTX;
+	u32 *p = &bp->hw_stats.gem.tx_octets_31_0;
+	u32 *end = &bp->hw_stats.gem.rx_udp_checksum_errors + 1;
+
+	for (; p < end; p++, reg++)
+		*p += __raw_readl(reg);
+}
+
+static struct net_device_stats *gem_get_stats(struct macb *bp)
+{
+	struct gem_stats *hwstat = &bp->hw_stats.gem;
+	struct net_device_stats *nstat = &bp->stats;
+
+	gem_update_stats(bp);
+
+	nstat->rx_errors = (hwstat->rx_frame_check_sequence_errors +
+			    hwstat->rx_alignment_errors +
+			    hwstat->rx_resource_errors +
+			    hwstat->rx_overruns +
+			    hwstat->rx_oversize_frames +
+			    hwstat->rx_jabbers +
+			    hwstat->rx_undersized_frames +
+			    hwstat->rx_length_field_frame_errors);
+	nstat->tx_errors = (hwstat->tx_late_collisions +
+			    hwstat->tx_excessive_collisions +
+			    hwstat->tx_underrun +
+			    hwstat->tx_carrier_sense_errors);
+	nstat->multicast = hwstat->rx_multicast_frames;
+	nstat->collisions = (hwstat->tx_single_collision_frames +
+			     hwstat->tx_multiple_collision_frames +
+			     hwstat->tx_excessive_collisions);
+	nstat->rx_length_errors = (hwstat->rx_oversize_frames +
+				   hwstat->rx_jabbers +
+				   hwstat->rx_undersized_frames +
+				   hwstat->rx_length_field_frame_errors);
+	nstat->rx_over_errors = hwstat->rx_resource_errors;
+	nstat->rx_crc_errors = hwstat->rx_frame_check_sequence_errors;
+	nstat->rx_frame_errors = hwstat->rx_alignment_errors;
+	nstat->rx_fifo_errors = hwstat->rx_overruns;
+	nstat->tx_aborted_errors = hwstat->tx_excessive_collisions;
+	nstat->tx_carrier_errors = hwstat->tx_carrier_sense_errors;
+	nstat->tx_fifo_errors = hwstat->tx_underrun;
+
+	return nstat;
+}
+
 static struct net_device_stats *macb_get_stats(struct net_device *dev)
 {
 	struct macb *bp = netdev_priv(dev);
 	struct net_device_stats *nstat = &bp->stats;
-	struct macb_stats *hwstat = &bp->hw_stats;
+	struct macb_stats *hwstat = &bp->hw_stats.macb;
+
+	if (bp->is_gem)
+		return gem_get_stats(bp);
 
 	/* read stats from hardware */
 	macb_update_stats(bp);
diff --git a/drivers/net/macb.h b/drivers/net/macb.h
index 65abd8a..a2074f5 100644
--- a/drivers/net/macb.h
+++ b/drivers/net/macb.h
@@ -68,6 +68,7 @@
 #define GEM_HRT					0x0084
 #define GEM_SA1B				0x0088
 #define GEM_SA1T				0x008C
+#define GEM_OTX					0x0100
 
 /* Bitfields in NCR */
 #define MACB_LB_OFFSET				0
@@ -425,6 +426,54 @@ struct macb_stats {
 	u32	tx_pause_frames;
 };
 
+struct gem_stats {
+	u32	tx_octets_31_0;
+	u32	tx_octets_47_32;
+	u32	tx_frames;
+	u32	tx_broadcast_frames;
+	u32	tx_multicast_frames;
+	u32	tx_pause_frames;
+	u32	tx_64_byte_frames;
+	u32	tx_65_127_byte_frames;
+	u32	tx_128_255_byte_frames;
+	u32	tx_256_511_byte_frames;
+	u32	tx_512_1023_byte_frames;
+	u32	tx_1024_1518_byte_frames;
+	u32	tx_greater_than_1518_byte_frames;
+	u32	tx_underrun;
+	u32	tx_single_collision_frames;
+	u32	tx_multiple_collision_frames;
+	u32	tx_excessive_collisions;
+	u32	tx_late_collisions;
+	u32	tx_deferred_frames;
+	u32	tx_carrier_sense_errors;
+	u32	rx_octets_31_0;
+	u32	rx_octets_47_32;
+	u32	rx_frames;
+	u32	rx_broadcast_frames;
+	u32	rx_multicast_frames;
+	u32	rx_pause_frames;
+	u32	rx_64_byte_frames;
+	u32	rx_65_127_byte_frames;
+	u32	rx_128_255_byte_frames;
+	u32	rx_256_511_byte_frames;
+	u32	rx_512_1023_byte_frames;
+	u32	rx_1024_1518_byte_frames;
+	u32	rx_greater_than_1518_byte_frames;
+	u32	rx_undersized_frames;
+	u32	rx_oversize_frames;
+	u32	rx_jabbers;
+	u32	rx_frame_check_sequence_errors;
+	u32	rx_length_field_frame_errors;
+	u32	rx_symbol_errors;
+	u32	rx_alignment_errors;
+	u32	rx_resource_errors;
+	u32	rx_overruns;
+	u32	rx_ip_header_checksum_errors;
+	u32	rx_tcp_checksum_errors;
+	u32	rx_udp_checksum_errors;
+};
+
 struct macb {
 	void __iomem		*regs;
 	int			is_gem;
@@ -444,7 +493,10 @@ struct macb {
 	struct net_device	*dev;
 	struct napi_struct	napi;
 	struct net_device_stats	stats;
-	struct macb_stats	hw_stats;
+	union {
+		struct macb_stats	macb;
+		struct gem_stats	gem;
+	}			hw_stats;
 
 	dma_addr_t		rx_ring_dma;
 	dma_addr_t		tx_ring_dma;
-- 
1.7.4


^ permalink raw reply related

* [PATCHv2 8/9] macb: support DMA bus widths > 32 bits
From: Jamie Iles @ 2011-03-15 10:14 UTC (permalink / raw)
  To: netdev, linux-arm-kernel; +Cc: nicolas.ferre, plagnioj, Jamie Iles
In-Reply-To: <1300184096-13937-1-git-send-email-jamie@jamieiles.com>

Some GEM implementations may support DMA bus widths up to 128 bits.  We
can get the maximum supported DMA bus width from the design
configuration register so use that to program the device up.

Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
 drivers/net/macb.c |   23 +++++++++++++++++++++++
 drivers/net/macb.h |   19 +++++++++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 0598373..db9f403 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -822,6 +822,27 @@ static u32 macb_mdc_clk_div(struct macb *bp)
 	return config;
 }
 
+/*
+ * Get the DMA bus width field of the network configuration register that we
+ * should program.  We find the width from decoding the design configuration
+ * register to find the maximum supported data bus width.
+ */
+static u32 macb_dbw(struct macb *bp)
+{
+	if (!bp->is_gem)
+		return 0;
+
+	switch (GEM_BFEXT(DBWDEF, gem_readl(bp, DCFG1))) {
+	case 4:
+		return GEM_BF(DBW, GEM_DBW128);
+	case 2:
+		return GEM_BF(DBW, GEM_DBW64);
+	case 1:
+	default:
+		return GEM_BF(DBW, GEM_DBW32);
+	}
+}
+
 static void macb_init_hw(struct macb *bp)
 {
 	u32 config;
@@ -837,6 +858,7 @@ static void macb_init_hw(struct macb *bp)
 		config |= MACB_BIT(CAF);	/* Copy All Frames */
 	if (!(bp->dev->flags & IFF_BROADCAST))
 		config |= MACB_BIT(NBC);	/* No BroadCast */
+	config |= macb_dbw(bp);
 	macb_writel(bp, NCFGR, config);
 
 	/* Initialize TX and RX buffers */
@@ -1267,6 +1289,7 @@ static int __init macb_probe(struct platform_device *pdev)
 
 	/* Set MII management clock divider */
 	config = macb_mdc_clk_div(bp);
+	config |= macb_dbw(bp);
 	macb_writel(bp, NCFGR, config);
 
 	macb_get_hwaddr(bp);
diff --git a/drivers/net/macb.h b/drivers/net/macb.h
index a2074f5..5f93bab 100644
--- a/drivers/net/macb.h
+++ b/drivers/net/macb.h
@@ -69,6 +69,13 @@
 #define GEM_SA1B				0x0088
 #define GEM_SA1T				0x008C
 #define GEM_OTX					0x0100
+#define GEM_DCFG1				0x0280
+#define GEM_DCFG2				0x0284
+#define GEM_DCFG3				0x0288
+#define GEM_DCFG4				0x028c
+#define GEM_DCFG5				0x0290
+#define GEM_DCFG6				0x0294
+#define GEM_DCFG7				0x0298
 
 /* Bitfields in NCR */
 #define MACB_LB_OFFSET				0
@@ -139,6 +146,14 @@
 /* GEM specific NCFGR bitfields. */
 #define GEM_CLK_OFFSET				18
 #define GEM_CLK_SIZE				3
+#define GEM_DBW_OFFSET				21
+#define GEM_DBW_SIZE				2
+
+/* Constants for data bus width. */
+#define GEM_DBW32				0
+#define GEM_DBW64				1
+#define GEM_DBW128				2
+
 /* Bitfields in NSR */
 #define MACB_NSR_LINK_OFFSET			0
 #define MACB_NSR_LINK_SIZE			1
@@ -247,6 +262,10 @@
 #define MACB_REV_OFFSET				0
 #define MACB_REV_SIZE				16
 
+/* Bitfields in DCFG1. */
+#define GEM_DBWDEF_OFFSET			25
+#define GEM_DBWDEF_SIZE				3
+
 /* Constants for CLK */
 #define MACB_CLK_DIV8				0
 #define MACB_CLK_DIV16				1
-- 
1.7.4


^ permalink raw reply related

* [PATCHv2 9/9] macb: allow GEM to have configurable receive buffer size
From: Jamie Iles @ 2011-03-15 10:14 UTC (permalink / raw)
  To: netdev, linux-arm-kernel; +Cc: nicolas.ferre, plagnioj, Jamie Iles
In-Reply-To: <1300184096-13937-1-git-send-email-jamie@jamieiles.com>

GEM has configurable receive buffer sizes so requires this to be
programmed up.  Any size < 2048 and a multiple of 64 bytes is permitted.

Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
 drivers/net/macb.c |   17 +++++++++++++++++
 drivers/net/macb.h |    5 +++++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index db9f403..52ad367 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -843,6 +843,21 @@ static u32 macb_dbw(struct macb *bp)
 	}
 }
 
+/*
+ * Configure the receive DMA engine to use the correct receive buffer size.
+ * This is a configurable parameter for GEM.
+ */
+static void macb_configure_dma(struct macb *bp)
+{
+	u32 dmacfg;
+
+	if (bp->is_gem) {
+		dmacfg = gem_readl(bp, DMACFG) & ~GEM_BF(RXBS, -1L);
+		dmacfg |= GEM_BF(RXBS, RX_BUFFER_SIZE / 64);
+		gem_writel(bp, DMACFG, dmacfg);
+	}
+}
+
 static void macb_init_hw(struct macb *bp)
 {
 	u32 config;
@@ -861,6 +876,8 @@ static void macb_init_hw(struct macb *bp)
 	config |= macb_dbw(bp);
 	macb_writel(bp, NCFGR, config);
 
+	macb_configure_dma(bp);
+
 	/* Initialize TX and RX buffers */
 	macb_writel(bp, RBQP, bp->rx_ring_dma);
 	macb_writel(bp, TBQP, bp->tx_ring_dma);
diff --git a/drivers/net/macb.h b/drivers/net/macb.h
index 5f93bab..d743d3e 100644
--- a/drivers/net/macb.h
+++ b/drivers/net/macb.h
@@ -64,6 +64,7 @@
 /* GEM register offsets. */
 #define GEM_NCFGR				0x0004
 #define GEM_USRIO				0x000c
+#define GEM_DMACFG				0x0010
 #define GEM_HRB					0x0080
 #define GEM_HRT					0x0084
 #define GEM_SA1B				0x0088
@@ -154,6 +155,10 @@
 #define GEM_DBW64				1
 #define GEM_DBW128				2
 
+/* Bitfields in DMACFG. */
+#define GEM_RXBS_OFFSET				16
+#define GEM_RXBS_SIZE				8
+
 /* Bitfields in NSR */
 #define MACB_NSR_LINK_OFFSET			0
 #define MACB_NSR_LINK_SIZE			1
-- 
1.7.4


^ permalink raw reply related

* [PATCHv2 0/9] macb: add support for Cadence GEM
From: Jamie Iles @ 2011-03-15 10:14 UTC (permalink / raw)
  To: netdev, linux-arm-kernel; +Cc: nicolas.ferre, plagnioj, Jamie Iles

This patch series extends the Atmel MACB driver to support the Cadence
GEM (Gigabit Ethernet MAC) to support 10/100 operation.  The GEM is
based on the MACB block but has a few moved registers and bitfields.
This patch series attempts to use the MACB accessors where block
functionallity is identical and only overrides to GEM specific
acccessors when needed.

This has been runtested on a board with a Cadence GEM and compile tested
for all at91 configurations and a number of avr32 configurations.

Changes since v1:
	- AT91 now provides a fake "hclk" and "macb_clk" has been
	renamed to "pclk" to be consistent with AVR32.
	- Configurable GEM receive buffer size support has been added.
	- pr_foo() and dev_foo() have been converted to netdev_foo()
	where appropriate.
	- New conditional accessors (macb_or_gem_{read,write}l) have
	been introduced that do the conditional accesses dependent on
	macb/gem type.
	- GEM is now dynamically detected from the module ID rather than
	platform device name.

Jean-Christophe, I haven't based this on your conditional clock patch as
I wasn't sure what decision had been made on that and whether the
at91/avr32 detection is reliable.

Jamie Iles (9):
  at91: provide macb clks with "pclk" and "hclk" name
  macb: remove conditional clk handling
  macb: unify at91 and avr32 platform data
  macb: convert printk to netdev_ and friends
  macb: initial support for Cadence GEM
  macb: support higher rate GEM MDIO clock divisors
  macb: support statistics for GEM devices
  macb: support DMA bus widths > 32 bits
  macb: allow GEM to have configurable receive buffer size

 arch/arm/mach-at91/at572d940hf.c            |    8 +-
 arch/arm/mach-at91/at572d940hf_devices.c    |    6 +-
 arch/arm/mach-at91/at91cap9.c               |    8 +-
 arch/arm/mach-at91/at91cap9_devices.c       |    6 +-
 arch/arm/mach-at91/at91rm9200_devices.c     |    6 +-
 arch/arm/mach-at91/at91sam9260.c            |    8 +-
 arch/arm/mach-at91/at91sam9260_devices.c    |    6 +-
 arch/arm/mach-at91/at91sam9263.c            |    8 +-
 arch/arm/mach-at91/at91sam9263_devices.c    |    6 +-
 arch/arm/mach-at91/at91sam9g45.c            |    8 +-
 arch/arm/mach-at91/at91sam9g45_devices.c    |    6 +-
 arch/arm/mach-at91/board-1arm.c             |    2 +-
 arch/arm/mach-at91/board-afeb-9260v1.c      |    2 +-
 arch/arm/mach-at91/board-at572d940hf_ek.c   |    2 +-
 arch/arm/mach-at91/board-cam60.c            |    2 +-
 arch/arm/mach-at91/board-cap9adk.c          |    2 +-
 arch/arm/mach-at91/board-carmeva.c          |    2 +-
 arch/arm/mach-at91/board-cpu9krea.c         |    2 +-
 arch/arm/mach-at91/board-cpuat91.c          |    2 +-
 arch/arm/mach-at91/board-csb337.c           |    2 +-
 arch/arm/mach-at91/board-csb637.c           |    2 +-
 arch/arm/mach-at91/board-eb9200.c           |    2 +-
 arch/arm/mach-at91/board-ecbat91.c          |    2 +-
 arch/arm/mach-at91/board-eco920.c           |    2 +-
 arch/arm/mach-at91/board-foxg20.c           |    2 +-
 arch/arm/mach-at91/board-gsia18s.c          |    2 +-
 arch/arm/mach-at91/board-kafa.c             |    2 +-
 arch/arm/mach-at91/board-kb9202.c           |    2 +-
 arch/arm/mach-at91/board-neocore926.c       |    2 +-
 arch/arm/mach-at91/board-pcontrol-g20.c     |    2 +-
 arch/arm/mach-at91/board-picotux200.c       |    2 +-
 arch/arm/mach-at91/board-qil-a9260.c        |    2 +-
 arch/arm/mach-at91/board-rm9200dk.c         |    2 +-
 arch/arm/mach-at91/board-rm9200ek.c         |    2 +-
 arch/arm/mach-at91/board-sam9-l9260.c       |    2 +-
 arch/arm/mach-at91/board-sam9260ek.c        |    2 +-
 arch/arm/mach-at91/board-sam9263ek.c        |    2 +-
 arch/arm/mach-at91/board-sam9g20ek.c        |    2 +-
 arch/arm/mach-at91/board-sam9m10g45ek.c     |    2 +-
 arch/arm/mach-at91/board-snapper9260.c      |    2 +-
 arch/arm/mach-at91/board-stamp9g20.c        |    2 +-
 arch/arm/mach-at91/board-usb-a9260.c        |    2 +-
 arch/arm/mach-at91/board-usb-a9263.c        |    2 +-
 arch/arm/mach-at91/board-yl-9200.c          |    2 +-
 arch/arm/mach-at91/include/mach/board.h     |   14 +-
 arch/avr32/mach-at32ap/include/mach/board.h |    5 +-
 drivers/net/Kconfig                         |    8 +-
 drivers/net/macb.c                          |  331 ++++++++++++++++++---------
 drivers/net/macb.h                          |  146 ++++++++++++-
 include/linux/platform_data/macb.h          |   10 +
 50 files changed, 466 insertions(+), 190 deletions(-)
 create mode 100644 include/linux/platform_data/macb.h

-- 
1.7.4


^ permalink raw reply

* Re: [PATCH] tcp: avoid cwnd moderation in undo
From: Carsten Wolff @ 2011-03-15 10:20 UTC (permalink / raw)
  To: John Heffner
  Cc: Yuchung Cheng, David Miller, Ilpo Jarvinen, Nandita Dukkipati,
	netdev
In-Reply-To: <AANLkTi=qi2GOprXEWCf6v=j=L98SQMdHb1OaHcdALepf@mail.gmail.com>

On Monday 14 March 2011, John Heffner wrote:
> On Mon, Mar 14, 2011 at 3:10 PM, Yuchung Cheng <ycheng@google.com> wrote:
> > On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@wolffcarsten.de> 
wrote:
> >> The moderation is in place to avoid gigantic segment bursts, which could
> >> cause unnecessary pressure on buffers. In my eyes it's already
> >> suboptimal that the moderation is weakened in the presence of
> >> (detected) reordering, let alone removing it completely.
> > 
> > In the presence of reordering, cwnd is already moderated in Disorder
> > state before
> >  entering the (false) recovery.
> 
> I've always been somewhat skeptical of the usefulness of cwnd
> moderation.  First, I don't know that its behavior is well defined.
> When *should* tcp_moderate_cwnd() actually be called, and why?
> 
> Second, I've never liked the idea in general.  Reducing cwnd has an
> effect lasting many RTTs, so reducing it in response to a transient
> event like reordering seems dubious.  And it does not address many
> causes of bursts, such as ack compression or stretch acks.

I think the undo operations are a special case where it absolutely makes 
sense, because the cwnd _already_ has been reduced (down to 1 segment by RTO 
recovery, or, with its special mixture of ratehalving and newreno, Linux 
sometimes reduces cwnd far below half of it even in fast recovery.). The undo 
re-opens the window all at once, which may allow _really huge_ bursts. I don't 
know enough about the other causes of TCPs burstiness, I'm just concerned 
about allowing this special cause.

Carsten
-- 
           /\-´-/\
          (  @ @  )
________o0O___^___O0o________

^ permalink raw reply

* Re: linux-next: build failure after merge of the net tree
From: Thomas Gleixner @ 2011-03-15 10:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, bhutchings, netdev, linux-next, linux-kernel, mingo,
	hpa, peterz
In-Reply-To: <20110315172558.a11642e7.sfr@canb.auug.org.au>

On Tue, 15 Mar 2011, Stephen Rothwell wrote:

> Hi Dave,
> 
> On Mon, 14 Mar 2011 21:07:12 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 15 Mar 2011 11:30:49 +1100
> > 
> > > So, if you merge the commit 1fb0ef31f428 ("genirq: Fix affinity notifier
> > > fallout") from the tip tree, you will get exactly one new commit and will
> > > fix your tree properly with no adverse effect on anyone else.
> > 
> > Thomas, how would you like me to do this?  Do you want to put that
> > commit on a branch for me to pull from or should I apply it
> > directly?
> 
> That commit is already the head of the irq/numa branch in the tip tree
> (it is also on the irq/core branch).
> 
> Please merge that rather than cherry-picking the commit as that will
> minimise the possibility of conflicts.  Pulling the irq/numa branch will
> get you just that one fixup commit (as you have already merged up to the
> immediately preceding commit).
> 
> I assume this makes sense, Thomas?  I just did a merge of the actual
> fixup commit after merging the net tree.

Yes. irq/numa should do the trick.

Thanks,

	tglx

^ permalink raw reply

* [PATCH net-next-2.6] be2net: Fix UDP packet detected status in RX compl
From: Padmanabh Ratnakar @ 2011-03-15 10:29 UTC (permalink / raw)
  To: netdev, davem; +Cc: Padmanabh Ratnakar, Sathya Perla

Status of UDP packet detection not getting populated in RX completion
structure. This is required in csum_passed() routine.

Signed-off-by: Padmanabh Ratnakar <padmanabh.ratnakar@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
 drivers/net/benet/be_main.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 3cb5f4e..5e15006 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1088,6 +1088,7 @@ static void be_parse_rx_compl_v1(struct be_adapter *adapter,
 	rxcp->vlanf = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtp, compl);
 	rxcp->err = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, err, compl);
 	rxcp->tcpf = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, tcpf, compl);
+	rxcp->udpf = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, udpf, compl);
 	rxcp->ip_csum =
 		AMAP_GET_BITS(struct amap_eth_rx_compl_v1, ipcksm, compl);
 	rxcp->l4_csum =
@@ -1113,6 +1114,7 @@ static void be_parse_rx_compl_v0(struct be_adapter *adapter,
 	rxcp->vlanf = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtp, compl);
 	rxcp->err = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, err, compl);
 	rxcp->tcpf = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, tcpf, compl);
+	rxcp->udpf = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, udpf, compl);
 	rxcp->ip_csum =
 		AMAP_GET_BITS(struct amap_eth_rx_compl_v0, ipcksm, compl);
 	rxcp->l4_csum =
-- 
1.6.0.2


^ permalink raw reply related

* Re: [PATCH] tcp: avoid cwnd moderation in undo
From: John Heffner @ 2011-03-15 10:50 UTC (permalink / raw)
  To: Carsten Wolff
  Cc: Yuchung Cheng, David Miller, Ilpo Jarvinen, Nandita Dukkipati,
	netdev
In-Reply-To: <201103151120.55388.carsten@wolffcarsten.de>

Anecdotally, I've seen more harm than good from cwnd moderation but I
don't have any data to back that up.  It's hard to categorically say
anything.  But I don't know what makes the cases where cwnd moderation
is applied special.

Some other sources of bursts include
- Send-limited applications that stall for some time but less than an
RTO and do a large write
- Receive-limited applications that stall for some time but less than
an RTO and do a large read
- "Ack compression," when acks are queued somewhere in the network and
flood out at line rate
- "Stretch acks," when the receiving TCP does not ack every segment
(for efficiency, etc.), or acks are lost in the network.

Since all of these may occur in the Open state, cwnd moderation is not applied.

While I'm adding to my wish list ;-), I will also say that the undo
logic seems unnecessarily complicated.  If you expect you might have
to undo what you just did, why not wait a bit?  Something like rfc4653
seems like it might be a better approach and might make the cwnd
moderation discussion moot.

Thanks,
  -John


On Tue, Mar 15, 2011 at 6:20 AM, Carsten Wolff <carsten@wolffcarsten.de> wrote:
> On Monday 14 March 2011, John Heffner wrote:
>> On Mon, Mar 14, 2011 at 3:10 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> > On Mon, Mar 14, 2011 at 3:06 AM, Carsten Wolff <carsten@wolffcarsten.de>
> wrote:
>> >> The moderation is in place to avoid gigantic segment bursts, which could
>> >> cause unnecessary pressure on buffers. In my eyes it's already
>> >> suboptimal that the moderation is weakened in the presence of
>> >> (detected) reordering, let alone removing it completely.
>> >
>> > In the presence of reordering, cwnd is already moderated in Disorder
>> > state before
>> >  entering the (false) recovery.
>>
>> I've always been somewhat skeptical of the usefulness of cwnd
>> moderation.  First, I don't know that its behavior is well defined.
>> When *should* tcp_moderate_cwnd() actually be called, and why?
>>
>> Second, I've never liked the idea in general.  Reducing cwnd has an
>> effect lasting many RTTs, so reducing it in response to a transient
>> event like reordering seems dubious.  And it does not address many
>> causes of bursts, such as ack compression or stretch acks.
>
> I think the undo operations are a special case where it absolutely makes
> sense, because the cwnd _already_ has been reduced (down to 1 segment by RTO
> recovery, or, with its special mixture of ratehalving and newreno, Linux
> sometimes reduces cwnd far below half of it even in fast recovery.). The undo
> re-opens the window all at once, which may allow _really huge_ bursts. I don't
> know enough about the other causes of TCPs burstiness, I'm just concerned
> about allowing this special cause.
>
> Carsten
> --
>           /\-´-/\
>          (  @ @  )
> ________o0O___^___O0o________
>

^ permalink raw reply

* Re: [PATCH 17/17] net,act_police,rcu: remove rcu_barrier()
From: Eric Dumazet @ 2011-03-15 11:04 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Randy Dunlap, linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	Trond Myklebust, linux-sctp-u79uwXL29TY76Z2rM5mHXA,
	Pavel Emelyanov, Pekka Savola (ipv6), Uwe Kleine-König,
	Alexey Kuznetsov, Ingo Molnar, Paul E. McKenney,
	Sridhar Samudrala, Vlad Yasevich, Hagen Paul Pfeifer,
	John W. Linville, Al Viro, Johannes Berg, Jens Axboe,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA, Jiri Pirko
In-Reply-To: <4D7F3B62.6000005-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>

Le mardi 15 mars 2011 à 18:11 +0800, Lai Jiangshan a écrit :
> 
> There is no callback of this module maybe queued
> since we use kfree_rcu(), we can safely remove the rcu_barrier().
> 
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
>  net/sched/act_police.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/net/sched/act_police.c b/net/sched/act_police.c
> index 083b091..22e3f9b 100644
> --- a/net/sched/act_police.c
> +++ b/net/sched/act_police.c
> @@ -397,7 +397,6 @@ static void __exit
>  police_cleanup_module(void)
>  {
>  	tcf_unregister_action(&act_police_ops);
> -	rcu_barrier(); /* Wait for completion of call_rcu()'s (tcf_police_free_rcu) */
>  }
>  
>  module_init(police_init_module);


Why is it a separate patch, and not included in patch 5/17 ?





_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

^ permalink raw reply

* Re: [PATCHv2 3/9] macb: unify at91 and avr32 platform data
From: Peter Korsgaard @ 2011-03-15 11:14 UTC (permalink / raw)
  To: Jamie Iles; +Cc: netdev, plagnioj, nicolas.ferre, linux-arm-kernel
In-Reply-To: <1300184096-13937-4-git-send-email-jamie@jamieiles.com>

>>>>> "Jamie" == Jamie Iles <jamie@jamieiles.com> writes:

Hi,

 Jamie> Both at91 and avr32 defines its own platform data structure for
 Jamie> the macb driver and both share common structures though at91
 Jamie> includes a currently unused phy_irq_pin.  Create a common
 Jamie> eth_platform_data for macb that both at91 and avr32 can use.  In
 Jamie> future we can use this to support other architectures that use the
 Jamie> same IP block with the macb driver.

Nice!

 Jamie> Signed-off-by: Jamie Iles <jamie@jamieiles.com>

 Jamie> +++ b/include/linux/platform_data/macb.h
 Jamie> @@ -0,0 +1,17 @@
 Jamie> +/*
 Jamie> + * Copyright (C) 2004-2006 Atmel Corporation
 Jamie> + *
 Jamie> + * This program is free software; you can redistribute it and/or modify
 Jamie> + * it under the terms of the GNU General Public License version 2 as
 Jamie> + * published by the Free Software Foundation.
 Jamie> + */
 Jamie> +#ifndef __MACB_PDATA_H__
 Jamie> +#define __MACB_PDATA_H__
 Jamie> +
 Jamie> +struct eth_platform_data {

How about at the same time renaming it to something a bit less generic
like macb_platform_data?

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCHv2 3/9] macb: unify at91 and avr32 platform data
From: Jamie Iles @ 2011-03-15 11:34 UTC (permalink / raw)
  To: Peter Korsgaard
  Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre, plagnioj
In-Reply-To: <87vczkmy94.fsf@macbook.be.48ers.dk>

Hi Peter,

On Tue, Mar 15, 2011 at 12:14:31PM +0100, Peter Korsgaard wrote:
> >>>>> "Jamie" == Jamie Iles <jamie@jamieiles.com> writes:
>  Jamie> +++ b/include/linux/platform_data/macb.h
>  Jamie> @@ -0,0 +1,17 @@
>  Jamie> +/*
>  Jamie> + * Copyright (C) 2004-2006 Atmel Corporation
>  Jamie> + *
>  Jamie> + * This program is free software; you can redistribute it and/or modify
>  Jamie> + * it under the terms of the GNU General Public License version 2 as
>  Jamie> + * published by the Free Software Foundation.
>  Jamie> + */
>  Jamie> +#ifndef __MACB_PDATA_H__
>  Jamie> +#define __MACB_PDATA_H__
>  Jamie> +
>  Jamie> +struct eth_platform_data {
> 
> How about at the same time renaming it to something a bit less generic
> like macb_platform_data?

Yes, that's a fair point.

Jamie

^ permalink raw reply

* Re: [GIT PULL nf-next-2.6] IPVS
From: Patrick McHardy @ 2011-03-15 12:16 UTC (permalink / raw)
  To: Simon Horman
  Cc: netdev, netfilter-devel, netfilter, lvs-devel, Eric Dumazet,
	Julian Anastasov, Hans Schillstrom
In-Reply-To: <1300166852-725-1-git-send-email-horms@verge.net.au>

On 15.03.2011 06:27, Simon Horman wrote:
> Hi Patrick,
> 
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
> to get the changes listed below.

Pulled, thanks Simon.

> This replaces the pull requests that I sent yesterday, sorry for messing
> that up.
> 
> Also, sorry for letting the number of patches grow so much, Julian and I
> were working on patches that conflicted with each other. But regardless, I
> should have done something about getting a request to you earlier.

No problem, the individual patches are quite small after all.

^ permalink raw reply

* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Patrick McHardy @ 2011-03-15 12:21 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Changli Gao, David S. Miller, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1103150302310.27019@obet.zrqbmnf.qr>

On 15.03.2011 03:05, Jan Engelhardt wrote:
> On Tuesday 2011-03-15 02:30, Changli Gao wrote:
> 
>> On Tue, Mar 15, 2011 at 9:16 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>>>
>>>
>>> The original tuple may not be updated, but the reply tuple is.
>>> And we are taking the reply tuple in
>>>
>>>        tuple_ptr = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
>>>
>>> which is subsequently copied to conn->tuple on the first invocation.
>>>
>>> Afterwards, SNAT will update ct->tuplehash[reply].tuple, and so
>>> conn->tuple is outdated. Calling nf_conntrack_find_get(conn->tuple)
>>> in count_them would then fail, would it not?
>>>
>>
>> After my patch, tuple is only used to look up the corresponding
>> conntrack.
> 
> Ok, the patch may be applied. Somehow I was under the impression
> addr was extracted from tuple_ptr, but it is, in fact, not.
> 

OK, thanks, I'll apply patches 1-4.

^ permalink raw reply

* Re: [PATCH 1/4] netfilter: xt_connlimit: fix daddr connlimit in SNAT scenario
From: Patrick McHardy @ 2011-03-15 12:24 UTC (permalink / raw)
  To: Changli Gao; +Cc: David S. Miller, netfilter-devel, netdev
In-Reply-To: <1300085414-27275-1-git-send-email-xiaosuo@gmail.com>

On 14.03.2011 07:50, Changli Gao wrote:
> We use the reply tuples when limiting the connections by the destination
> addresses, however, in SNAT scenario, the final reply tuples won't be
> ready until SNAT is done in POSTROUING or INPUT chain, and the following
> nf_conntrack_find_get() in count_tem() will get nothing, so connlimit
> can't work as expected.
> 
> In this patch, the original tuples are always used, and an additional
> member addr is appended to save the address in either end.

Applied, thanks.


^ permalink raw reply

* Re: [PATCH 2/4] netfilter: xt_connlimit: use kmalloc() instead of kzalloc()
From: Patrick McHardy @ 2011-03-15 12:25 UTC (permalink / raw)
  To: Changli Gao; +Cc: David S. Miller, netfilter-devel, netdev
In-Reply-To: <1300085414-27275-2-git-send-email-xiaosuo@gmail.com>

On 14.03.2011 07:50, Changli Gao wrote:
> All the members are initialized after kzalloc().

Applied.

^ permalink raw reply

* Re: [PATCH 3/4] netfilter: xt_connlimit: use hlist instead
From: Patrick McHardy @ 2011-03-15 12:26 UTC (permalink / raw)
  To: Changli Gao; +Cc: David S. Miller, netfilter-devel, netdev
In-Reply-To: <1300085414-27275-3-git-send-email-xiaosuo@gmail.com>

On 14.03.2011 07:50, Changli Gao wrote:
> The header of hlist is smaller than list.

Applied.

^ permalink raw reply

* Re: [PATCH 4/4] netfilter: xt_connlimit: remove connlimit_rnd_inited
From: Patrick McHardy @ 2011-03-15 12:26 UTC (permalink / raw)
  To: Changli Gao; +Cc: David S. Miller, netfilter-devel, netdev
In-Reply-To: <1300085414-27275-4-git-send-email-xiaosuo@gmail.com>

On 14.03.2011 07:50, Changli Gao wrote:
> A potential race condition when generating connlimit_rnd is also fixed.

Also applied, thanks Changli.

^ permalink raw reply

* Re: [PATCH] ipv4: netfilter: ipt_CLUSTERIP: fix buffer overflow
From: Patrick McHardy @ 2011-03-15 12:33 UTC (permalink / raw)
  To: Changli Gao
  Cc: Vasiliy Kulikov, linux-kernel, security, David S. Miller,
	Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
	netfilter-devel, netfilter, coreteam, netdev
In-Reply-To: <AANLkTimPZJoCzz386e-4m0Y4khWGZirZguGFmuFYCrry@mail.gmail.com>

On 13.03.2011 15:00, Changli Gao wrote:
> On Fri, Mar 11, 2011 at 2:12 AM, Vasiliy Kulikov <segoon@openwall.com> wrote:
>> buffer string is copied from userspace.  It is not checked whether it is
>> zero terminated.  This may lead to overflow inside of simple_strtoul().
>>
>> It was introduced before the git epoch.  Files "ipt_CLUSTERIP/*" are
>> root writable only by default, however, on some setups permissions might be
>> relaxed to e.g. network admin user.
>>
>> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
>> ---
>>  Compile tested.
>>
>>  net/ipv4/netfilter/ipt_CLUSTERIP.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
>> index 403ca57..7aabf9a 100644
>> --- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
>> +++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
>> @@ -666,6 +666,7 @@ static ssize_t clusterip_proc_write(struct file *file, const char __user *input,
>>
>>        if (copy_from_user(buffer, input, PROC_WRITELEN))
> 
> I think size should be used instead of PROC_WRITELEN.
> 
> if (size > PROC_WRITELEN)
>      return -EIO;
> if (copy_from_user(buffer, input, size))
>     return -EFAULT;
> buffer[size] = '\0';

I agree, otherwise we might have the situation that the userspace
copy is crossing page boundaries into unmapped memory.




^ permalink raw reply

* Re: [PATCHv2 1/9] at91: provide macb clks with "pclk" and "hclk" name
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-15 12:35 UTC (permalink / raw)
  To: Jamie Iles; +Cc: netdev, nicolas.ferre, linux-arm-kernel
In-Reply-To: <1300184096-13937-2-git-send-email-jamie@jamieiles.com>

On 10:14 Tue 15 Mar     , Jamie Iles wrote:
> The macb driver expects clocks with the names "pclk" and "hclk".  We
> currently provide "macb_clk" but to fit in line with other
> architectures (namely AVR32), provide "pclk" and a fake "hclk".
> 
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> ---
>  arch/arm/mach-at91/at572d940hf.c |    8 +++++++-
>  arch/arm/mach-at91/at91cap9.c    |    8 +++++++-
>  arch/arm/mach-at91/at91sam9260.c |    8 +++++++-
>  arch/arm/mach-at91/at91sam9263.c |    8 +++++++-
>  arch/arm/mach-at91/at91sam9g45.c |    8 +++++++-
>  5 files changed, 35 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/at572d940hf.c b/arch/arm/mach-at91/at572d940hf.c
> index a6b9c68..9b3a37e 100644
> --- a/arch/arm/mach-at91/at572d940hf.c
> +++ b/arch/arm/mach-at91/at572d940hf.c
> @@ -71,10 +71,15 @@ static struct clk pioC_clk = {
>  	.type		= CLK_TYPE_PERIPHERAL,
>  };
>  static struct clk macb_clk = {
> -	.name		= "macb_clk",
> +	.name		= "pclk",
>  	.pmc_mask	= 1 << AT572D940HF_ID_EMAC,
>  	.type		= CLK_TYPE_PERIPHERAL,
>  };
> +static struct clk macb_hclk = {
> +	.name		= "hclk",
> +	.pmc_mask	= 0,
> +	.type		= CLK_TYPE_PERIPHERAL,
> +};
for the fake clock you must specify the parent as macb_clk

take a look on the tcb1_clk for the 9g45

Best Regards,
J.

^ permalink raw reply

* Re: [PATCH] ipv4: netfilter: arp_tables: fix infoleak to userspace
From: Patrick McHardy @ 2011-03-15 12:35 UTC (permalink / raw)
  To: Vasiliy Kulikov
  Cc: linux-kernel, security, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter,
	coreteam, netdev
In-Reply-To: <1299780728-32565-1-git-send-email-segoon@openwall.com>

On 10.03.2011 19:12, Vasiliy Kulikov wrote:
> Structures ipt_replace, compat_ipt_replace, and xt_get_revision are
> copied from userspace.  Fields of these structs that are
> zero-terminated strings are not checked.  When they are used as argument
> to a format string containing "%s" in request_module(), some sensitive
> information is leaked to userspace via argument of spawned modprobe
> process.
> 
> The first bug was introduced before the git epoch;  the second is
> introduced by 6b7d31fc (v2.6.15-rc1);  the third is introduced by
> 6b7d31fc (v2.6.15-rc1).  To trigger the bug one should have
> CAP_NET_ADMIN.
> 

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] ipv4: netfilter: ip_tables: fix infoleak to userspace
From: Patrick McHardy @ 2011-03-15 12:36 UTC (permalink / raw)
  To: Vasiliy Kulikov
  Cc: linux-kernel, security, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter,
	coreteam, netdev
In-Reply-To: <1299780735-32607-1-git-send-email-segoon@openwall.com>

On 10.03.2011 19:12, Vasiliy Kulikov wrote:
> Structures ipt_replace, compat_ipt_replace, and xt_get_revision are
> copied from userspace.  Fields of these structs that are
> zero-terminated strings are not checked.  When they are used as argument
> to a format string containing "%s" in request_module(), some sensitive
> information is leaked to userspace via argument of spawned modprobe
> process.
> 
> The first and the third bugs were introduced before the git epoch; the
> second was introduced in 2722971c (v2.6.17-rc1).  To trigger the bug
> one should have CAP_NET_ADMIN.

Applied, thanks.

^ permalink raw reply

* Re: [PATCHv2 4/9] macb: convert printk to netdev_ and friends
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-15 12:36 UTC (permalink / raw)
  To: Jamie Iles; +Cc: netdev, nicolas.ferre, linux-arm-kernel
In-Reply-To: <1300184096-13937-5-git-send-email-jamie@jamieiles.com>

On 10:14 Tue 15 Mar     , Jamie Iles wrote:
> macb is already using the dev_dbg() and friends helpers so use netdev_()
> along with a pr_fmt() definition to make the printing a little cleaner.
> 
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
looks fine

Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

Best Regards,
J.

^ permalink raw reply

* Re: [PATCH] ipv6: netfilter: ip6_tables: fix infoleak to userspace
From: Patrick McHardy @ 2011-03-15 12:37 UTC (permalink / raw)
  To: Vasiliy Kulikov
  Cc: linux-kernel, security, David S. Miller, Alexey Kuznetsov,
	James Morris, Hideaki YOSHIFUJI, netfilter-devel, netfilter,
	coreteam, netdev
In-Reply-To: <1299780827-344-1-git-send-email-segoon@openwall.com>

On 10.03.2011 19:13, Vasiliy Kulikov wrote:
> Structures ip6t_replace, compat_ip6t_replace, and xt_get_revision are
> copied from userspace.  Fields of these structs that are
> zero-terminated strings are not checked.  When they are used as argument
> to a format string containing "%s" in request_module(), some sensitive
> information is leaked to userspace via argument of spawned modprobe
> process.
> 
> The first bug was introduced before the git epoch;  the second was
> introduced in 3bc3fe5e (v2.6.25-rc1);  the third is introduced by
> 6b7d31fc (v2.6.15-rc1).  To trigger the bug one should have
> CAP_NET_ADMIN.

Also applied, thanks Vasiliy.

^ permalink raw reply

* Re: [PATCHv2 3/9] macb: unify at91 and avr32 platform data
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-03-15 12:36 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <87vczkmy94.fsf@macbook.be.48ers.dk>

On 12:14 Tue 15 Mar     , Peter Korsgaard wrote:
> >>>>> "Jamie" == Jamie Iles <jamie@jamieiles.com> writes:
> 
> Hi,
> 
>  Jamie> Both at91 and avr32 defines its own platform data structure for
>  Jamie> the macb driver and both share common structures though at91
>  Jamie> includes a currently unused phy_irq_pin.  Create a common
>  Jamie> eth_platform_data for macb that both at91 and avr32 can use.  In
>  Jamie> future we can use this to support other architectures that use the
>  Jamie> same IP block with the macb driver.
> 
> Nice!
> 
>  Jamie> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> 
>  Jamie> +++ b/include/linux/platform_data/macb.h
>  Jamie> @@ -0,0 +1,17 @@
>  Jamie> +/*
>  Jamie> + * Copyright (C) 2004-2006 Atmel Corporation
>  Jamie> + *
>  Jamie> + * This program is free software; you can redistribute it and/or modify
>  Jamie> + * it under the terms of the GNU General Public License version 2 as
>  Jamie> + * published by the Free Software Foundation.
>  Jamie> + */
>  Jamie> +#ifndef __MACB_PDATA_H__
>  Jamie> +#define __MACB_PDATA_H__
>  Jamie> +
>  Jamie> +struct eth_platform_data {
> 
> How about at the same time renaming it to something a bit less generic
> like macb_platform_data?
agreed

Best Regards,
J.
> 
> -- 
> Bye, Peter Korsgaard

^ permalink raw reply

* Re: [PATCHv2 1/9] at91: provide macb clks with "pclk" and "hclk" name
From: Jamie Iles @ 2011-03-15 12:44 UTC (permalink / raw)
  To: Jean-Christophe PLAGNIOL-VILLARD
  Cc: Jamie Iles, netdev, linux-arm-kernel, nicolas.ferre
In-Reply-To: <20110315123539.GD14548@game.jcrosoft.org>

On Tue, Mar 15, 2011 at 01:35:39PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:14 Tue 15 Mar     , Jamie Iles wrote:
> > The macb driver expects clocks with the names "pclk" and "hclk".  We
> > currently provide "macb_clk" but to fit in line with other
> > architectures (namely AVR32), provide "pclk" and a fake "hclk".
> > 
> > Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> > ---
> >  arch/arm/mach-at91/at572d940hf.c |    8 +++++++-
> >  arch/arm/mach-at91/at91cap9.c    |    8 +++++++-
> >  arch/arm/mach-at91/at91sam9260.c |    8 +++++++-
> >  arch/arm/mach-at91/at91sam9263.c |    8 +++++++-
> >  arch/arm/mach-at91/at91sam9g45.c |    8 +++++++-
> >  5 files changed, 35 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-at91/at572d940hf.c b/arch/arm/mach-at91/at572d940hf.c
> > index a6b9c68..9b3a37e 100644
> > --- a/arch/arm/mach-at91/at572d940hf.c
> > +++ b/arch/arm/mach-at91/at572d940hf.c
> > @@ -71,10 +71,15 @@ static struct clk pioC_clk = {
> >  	.type		= CLK_TYPE_PERIPHERAL,
> >  };
> >  static struct clk macb_clk = {
> > -	.name		= "macb_clk",
> > +	.name		= "pclk",
> >  	.pmc_mask	= 1 << AT572D940HF_ID_EMAC,
> >  	.type		= CLK_TYPE_PERIPHERAL,
> >  };
> > +static struct clk macb_hclk = {
> > +	.name		= "hclk",
> > +	.pmc_mask	= 0,
> > +	.type		= CLK_TYPE_PERIPHERAL,
> > +};
> for the fake clock you must specify the parent as macb_clk
> 
> take a look on the tcb1_clk for the 9g45

Ok, will do.  Thanks for the pointer!

Jamie

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox