* [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
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