* Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices
From: Wolfgang Grandegger @ 2012-07-31 13:43 UTC (permalink / raw)
To: Olivier Sobrie; +Cc: Marc Kleine-Budde, linux-can, netdev
In-Reply-To: <20120731130650.GA23541@hposo>
On 07/31/2012 03:06 PM, Olivier Sobrie wrote:
> On Tue, Jul 31, 2012 at 11:56:22AM +0200, Marc Kleine-Budde wrote:
...
>> Please test Bus-Off behaviour:
>> - setup working CAN network
>> - short circuit CAN-H and CAN-L wires
>> - start "candump any,0:0,#FFFFFFFF" on one shell
>> - send one can frame on the other
>>
>> then
>>
>> - remove the short circuit
>> - see if the can frame is transmitted to the other side
>> - it should show up as an echo'ed CAN frame on the sender side
>>
>> Repeat the same test with disconnecting CAN-H and CAN-L from the other
>> CAN station instead of short circuit.
>>
>> Please send the output from candump.
>
> 1) With the short circuit:
>
> I perform the test you described. It showed that the Kvaser passes from
> ERROR-WARNING to ERROR-PASSIVE and then BUS-OFF. But after going to the
> state BUS-OFF it comes back to ERROR-WARNING.
You can use the option "-e" to get a human readable output.
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
A state change (0x10 here) should only be reported once.
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> ...
> can1 200000C8 [8] 00 00 90 00 00 00 00 00 ERRORFRAME <-- bus off
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> ...
> can1 20000088 [8] 00 10 90 00 00 00 00 00 ERRORFRAME
> can1 123 [2] 11 22 <-- short circuit removed
>
> I see the echo and on the other end I see the frame coming in.
> By the way I see that the txerr and rxerr fields of the structure
> kvaser_msg_error_event stay at 0.
If possible, they should be set for any CAN error message.
>
> 2) With CAN-H and CAN-L disconnected:
>
> I never see the bus going in OFF state. It stays in PASSIVE mode.
That is the correct behavior. You should get ACK slot (and not ACK
delimiter), IIRC.
I'm offline for the rest of the week. I will have a closer look next
week (to your next version(s)).
Wolfgang.
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Bjorn Helgaas @ 2012-07-31 13:45 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <20120730181542.GA987@jonmason-lab>
On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
> On Mon, Jul 30, 2012 at 10:50:13AM -0600, Bjorn Helgaas wrote:
>> On Sun, Jul 29, 2012 at 6:26 PM, Jon Mason <jon.mason@intel.com> wrote:
>> > A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
>> > connecting 2 systems, providing electrical isolation between the two subsystems.
>> > A non-transparent bridge is functionally similar to a transparent bridge except
>> > that both sides of the bridge have their own independent address domains. The
>> > host on one side of the bridge will not have the visibility of the complete
>> > memory or I/O space on the other side of the bridge. To communicate across the
>> > non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
>> > the local system. Writes to these apertures are mirrored to memory on the
>> > remote system. Communications can also occur through the use of doorbell
>> > registers that initiate interrupts to the alternate domain, and scratch-pad
>> > registers accessible from both sides.
>> >
>> > The NTB device driver is needed to configure these memory windows, doorbell, and
>> > scratch-pad registers as well as use them in such a way as they can be turned
>> > into a viable communication channel to the remote system. ntb_hw.[ch]
>> > determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
>> > the underlying hardware to provide access and a common interface to the doorbell
>> > registers, scratch pads, and memory windows. These hardware interfaces are
>> > exported so that other, non-mainlined kernel drivers can access these.
>> > ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
>> > communication channel(s) and provide a reliable way of transferring data from
>> > one side to the other, which it then exports so that "client" drivers can access
>> > them. These client drivers are used to provide a standard kernel interface
>> > (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
>> > system to the other in a standard way.
>> >
>> > Signed-off-by: Jon Mason <jon.mason@intel.com>
>> > ---
>> > MAINTAINERS | 6 +
>> > drivers/Kconfig | 2 +
>> > drivers/Makefile | 1 +
>> > drivers/ntb/Kconfig | 13 +
>> > drivers/ntb/Makefile | 3 +
>> > drivers/ntb/ntb_hw.c | 1178 ++++++++++++++++++++++++++++++++++++
>> > drivers/ntb/ntb_hw.h | 206 +++++++
>> > drivers/ntb/ntb_regs.h | 150 +++++
>> > drivers/ntb/ntb_transport.c | 1387 +++++++++++++++++++++++++++++++++++++++++++
>> > include/linux/ntb.h | 92 +++
>>
>> Where will drivers for non-Intel NTBs fit in this hierarchy? It seems
>> a bit presumptuous to claim the generic "ntb" names just for Intel
>> devices.
>
> I've tried to make it all generic enough that non-Intel NTBs should plug in with
> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> redesign of ntb_hw.c might be necessary. But from what I've seen of other
> designs on the internet, they appear to be extremely similar. The transport and
> client drivers were written with the hardware abstracted away as much as
> possible to prevent the need to modify it for different hardware. If there is
> anything which is Intel hardware specific, I'd be happy to change it to make it
> more generic.
That makes sense from a technical point of view, but I think it's
going to cause maintenance issues. For example, assume PLX NTB
support is added. Will PLX be happy about having to convince you to
accept changes? Will Intel be happy about having to release a new
driver for their hardware just to incorporate a PLX bug fix? Will
users of PLX hardware accept a new driver release that only benefits
Intel users?
^ permalink raw reply
* Re: TCP stalls with 802.3ad + bridge + kvm guest
From: Peter Samuelson @ 2012-07-31 14:07 UTC (permalink / raw)
To: Jay Vosburgh, netdev; +Cc: jgoerzen
In-Reply-To: <26496.1343419205@death.nxdomain>
> > ixgbe [10 Gbit port] -- bonding [802.3ad] -- bridge -- KVM guest
> >
> >(There's also a VLAN layer, but I can reproduce this problem without
> >it.) It all works, except that with some flows in the KVM guest - I
> >can reproduce using smbclient - transfers keep stalling, such that I'm
> >averaging well under 1 MB/s. Should be more like 100 MB/s.
> >
> >Oddly, this only occurs when both the 802.3ad and KVM are used:
> >
> > Server Agg Client TCP stalls
> > --------------------------------------------------
> > external none KVM guest no
> > external 802.3ad KVM host no
> > KVM host 802.3ad KVM guest no
> > external 802.3ad KVM guest yes
[Jay Vosburgh]
> Does the "none" for Agg (the first line) mean no bonding at all?
Correct. 'None' is without the bonding driver, putting the eth
interface directly on the bridge. (With or without a VLAN layer.)
> Does the problem happen if the bond is a different mode
> (balance-xor, for example)?
This is taking me longer to test, as I have to also update the switch
port config, which required coordination with coworkers. I'll get that
info as soon as I can.
> Do the various stats on the host and guest show any drops?
> E.g., from "netstat -i" and "tc -s qdisc"
Yes, 'netstat -i' on the KVM host shows a few dropped RX packets on
bond0 - looks like it increments by 2 each time I do a test download of
my 20MB file. 'tc -s qdisc' on the KVM host shows nothing, and I see
no drops on the KVM guest side.
I'll get the switch reconfigured not to do LACP so I can test other
bonding modes, as you suggest. Thanks for the quick response! Sorry
my own followup was delayed....
Peter
^ permalink raw reply
* CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Bernard Pidoux @ 2012-07-31 14:11 UTC (permalink / raw)
To: linux-hams, Linux Netdev List
Hi,
I observe systematically a kernel panic when I try to shutdown rose0
device using ifconfig rose0 down
This is happening on two very different ROSE implementation, one is on a
machine with x86-64 kernel 4.6.3 on an Intel core 2 duo CPU
the other is on a RaspBerry Pi with Raspbian and 3.1.9+ wheezy kernel
recompiled with AX.25 modules (ax25, rose, netrom, 6pack, kiss) enabled.
Here is an image of the screen dump :
http://f6bvp.org/photos/rose_device_event.JPG
It can be noticed that PC is at rose_device_event and
LR is at sock_def_wakeup
One thing to be noticed is that when I close before all ROSE and AX.25
applications, there are still a few populated sockets, probably for one
of the program did not close the sockets properly.
I that case, does rose module should accept to shutdown rose0 device ?
However, I guess that it should not create a kernel panic due to a
kernel NULL pointer.
I don't know what to do in order to debug that issue.
Bernard
^ permalink raw reply
* [PATCH iproute2 1/2] Add missing can.h
From: Rostislav Lisovy @ 2012-07-31 14:46 UTC (permalink / raw)
To: netdev; +Cc: linux-can, pisa, sojkam1, Rostislav Lisovy
Header file used when working with AF_CAN frames -- generated from
linux kernel 3.5+
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
---
include/linux/can.h | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 161 insertions(+)
create mode 100644 include/linux/can.h
diff --git a/include/linux/can.h b/include/linux/can.h
new file mode 100644
index 0000000..018055e
--- /dev/null
+++ b/include/linux/can.h
@@ -0,0 +1,161 @@
+/*
+ * linux/can.h
+ *
+ * Definitions for CAN network layer (socket addr / CAN frame / CAN filter)
+ *
+ * Authors: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Urs Thuermann <urs.thuermann@volkswagen.de>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ */
+
+#ifndef CAN_H
+#define CAN_H
+
+#include <linux/types.h>
+#include <linux/socket.h>
+
+/* controller area network (CAN) kernel definitions */
+
+/* special address description flags for the CAN_ID */
+#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */
+#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */
+#define CAN_ERR_FLAG 0x20000000U /* error message frame */
+
+/* valid bits in CAN ID for frame formats */
+#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */
+#define CAN_EFF_MASK 0x1FFFFFFFU /* extended frame format (EFF) */
+#define CAN_ERR_MASK 0x1FFFFFFFU /* omit EFF, RTR, ERR flags */
+
+/*
+ * Controller Area Network Identifier structure
+ *
+ * bit 0-28 : CAN identifier (11/29 bit)
+ * bit 29 : error message frame flag (0 = data frame, 1 = error message)
+ * bit 30 : remote transmission request flag (1 = rtr frame)
+ * bit 31 : frame format flag (0 = standard 11 bit, 1 = extended 29 bit)
+ */
+typedef __u32 canid_t;
+
+#define CAN_SFF_ID_BITS 11
+#define CAN_EFF_ID_BITS 29
+
+/*
+ * Controller Area Network Error Message Frame Mask structure
+ *
+ * bit 0-28 : error class mask (see include/linux/can/error.h)
+ * bit 29-31 : set to zero
+ */
+typedef __u32 can_err_mask_t;
+
+/* CAN payload length and DLC definitions according to ISO 11898-1 */
+#define CAN_MAX_DLC 8
+#define CAN_MAX_DLEN 8
+
+/* CAN FD payload length and DLC definitions according to ISO 11898-7 */
+#define CANFD_MAX_DLC 15
+#define CANFD_MAX_DLEN 64
+
+/**
+ * struct can_frame - basic CAN frame structure
+ * @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
+ * @can_dlc: frame payload length in byte (0 .. 8) aka data length code
+ * N.B. the DLC field from ISO 11898-1 Chapter 8.4.2.3 has a 1:1
+ * mapping of the 'data length code' to the real payload length
+ * @data: CAN frame payload (up to 8 byte)
+ */
+struct can_frame {
+ canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+ __u8 can_dlc; /* frame payload length in byte (0 .. CAN_MAX_DLEN) */
+ __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
+};
+
+/*
+ * defined bits for canfd_frame.flags
+ *
+ * As the default for CAN FD should be to support the high data rate in the
+ * payload section of the frame (HDR) and to support up to 64 byte in the
+ * data section (EDL) the bits are only set in the non-default case.
+ * Btw. as long as there's no real implementation for CAN FD network driver
+ * these bits are only preliminary.
+ *
+ * RX: NOHDR/NOEDL - info about received CAN FD frame
+ * ESI - bit from originating CAN controller
+ * TX: NOHDR/NOEDL - control per-frame settings if supported by CAN controller
+ * ESI - bit is set by local CAN controller
+ */
+#define CANFD_NOHDR 0x01 /* frame without high data rate */
+#define CANFD_NOEDL 0x02 /* frame without extended data length */
+#define CANFD_ESI 0x04 /* error state indicator */
+
+/**
+ * struct canfd_frame - CAN flexible data rate frame structure
+ * @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
+ * @len: frame payload length in byte (0 .. CANFD_MAX_DLEN)
+ * @flags: additional flags for CAN FD
+ * @__res0: reserved / padding
+ * @__res1: reserved / padding
+ * @data: CAN FD frame payload (up to CANFD_MAX_DLEN byte)
+ */
+struct canfd_frame {
+ canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+ __u8 len; /* frame payload length in byte */
+ __u8 flags; /* additional flags for CAN FD */
+ __u8 __res0; /* reserved / padding */
+ __u8 __res1; /* reserved / padding */
+ __u8 data[CANFD_MAX_DLEN] __attribute__((aligned(8)));
+};
+
+#define CAN_MTU (sizeof(struct can_frame))
+#define CANFD_MTU (sizeof(struct canfd_frame))
+
+/* particular protocols of the protocol family PF_CAN */
+#define CAN_RAW 1 /* RAW sockets */
+#define CAN_BCM 2 /* Broadcast Manager */
+#define CAN_TP16 3 /* VAG Transport Protocol v1.6 */
+#define CAN_TP20 4 /* VAG Transport Protocol v2.0 */
+#define CAN_MCNET 5 /* Bosch MCNet */
+#define CAN_ISOTP 6 /* ISO 15765-2 Transport Protocol */
+#define CAN_NPROTO 7
+
+#define SOL_CAN_BASE 100
+
+/**
+ * struct sockaddr_can - the sockaddr structure for CAN sockets
+ * @can_family: address family number AF_CAN.
+ * @can_ifindex: CAN network interface index.
+ * @can_addr: protocol specific address information
+ */
+struct sockaddr_can {
+ __kernel_sa_family_t can_family;
+ int can_ifindex;
+ union {
+ /* transport protocol class address information (e.g. ISOTP) */
+ struct { canid_t rx_id, tx_id; } tp;
+
+ /* reserved for future CAN protocols address information */
+ } can_addr;
+};
+
+/**
+ * struct can_filter - CAN ID based filter in can_register().
+ * @can_id: relevant bits of CAN ID which are not masked out.
+ * @can_mask: CAN mask (see description)
+ *
+ * Description:
+ * A filter matches, when
+ *
+ * <received_can_id> & mask == can_id & mask
+ *
+ * The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
+ * filter for error message frames (CAN_ERR_FLAG bit set in mask).
+ */
+struct can_filter {
+ canid_t can_id;
+ canid_t can_mask;
+};
+
+#define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */
+
+#endif /* CAN_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 2/2] em_canid: Ematch used to classify CAN frames according to their identifiers
From: Rostislav Lisovy @ 2012-07-31 14:46 UTC (permalink / raw)
To: netdev; +Cc: linux-can, pisa, sojkam1, Rostislav Lisovy
In-Reply-To: <1343745981-14248-1-git-send-email-lisovy@gmail.com>
This ematch enables effective filtering of CAN frames (AF_CAN) based
on CAN identifiers with masking of compared bits. Implementation
utilizes bitmap based classification for standard frame format (SFF)
which is optimized for minimal overhead.
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
---
etc/iproute2/ematch_map | 1 +
include/linux/pkt_cls.h | 6 +-
tc/Makefile | 1 +
tc/em_canid.c | 191 +++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 197 insertions(+), 2 deletions(-)
create mode 100644 tc/em_canid.c
diff --git a/etc/iproute2/ematch_map b/etc/iproute2/ematch_map
index 7c6a281..8d08613 100644
--- a/etc/iproute2/ematch_map
+++ b/etc/iproute2/ematch_map
@@ -3,3 +3,4 @@
2 nbyte
3 u32
4 meta
+7 canid
diff --git a/include/linux/pkt_cls.h b/include/linux/pkt_cls.h
index defbde2..082eafa 100644
--- a/include/linux/pkt_cls.h
+++ b/include/linux/pkt_cls.h
@@ -451,8 +451,10 @@ enum {
#define TCF_EM_U32 3
#define TCF_EM_META 4
#define TCF_EM_TEXT 5
-#define TCF_EM_VLAN 6
-#define TCF_EM_MAX 6
+#define TCF_EM_VLAN 6
+#define TCF_EM_CANID 7
+#define TCF_EM_IPSET 8
+#define TCF_EM_MAX 8
enum {
TCF_EM_PROG_TC
diff --git a/tc/Makefile b/tc/Makefile
index 64d93ad..bfdcf9f 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -45,6 +45,7 @@ TCMODULES += p_udp.o
TCMODULES += em_nbyte.o
TCMODULES += em_cmp.o
TCMODULES += em_u32.o
+TCMODULES += em_canid.o
TCMODULES += em_meta.o
TCMODULES += q_mqprio.o
TCMODULES += q_codel.o
diff --git a/tc/em_canid.c b/tc/em_canid.c
new file mode 100644
index 0000000..16f6ed5
--- /dev/null
+++ b/tc/em_canid.c
@@ -0,0 +1,191 @@
+/*
+ * em_canid.c Ematch rule to match CAN frames according to their CAN identifiers
+ *
+ * This program is free software; you can distribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Idea: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
+ * Copyright: (c) 2011 Czech Technical University in Prague
+ * (c) 2011 Volkswagen Group Research
+ * Authors: Michal Sojka <sojkam1@fel.cvut.cz>
+ * Pavel Pisa <pisa@cmp.felk.cvut.cz>
+ * Rostislav Lisovy <lisovy@gmail.cz>
+ * Funded by: Volkswagen Group Research
+ *
+ * Documentation: http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+#include <errno.h>
+#include <linux/can.h>
+#include <inttypes.h>
+#include "m_ematch.h"
+
+#define EM_CANID_RULES_MAX 400 /* Main reason for this number is Nelink
+ message size limit equal to Single memory page size. When dump()
+ is invoked, there are even some ematch related headers sent from
+ kernel to userspace together with em_canid configuration --
+ 400*sizeof(struct can_filter) should fit without any problems */
+
+extern struct ematch_util canid_ematch_util;
+struct rules {
+ struct can_filter *rules_raw;
+ int rules_capacity; /* Size of array allocated for rules_raw */
+ int rules_cnt; /* Actual number of rules stored in rules_raw */
+};
+
+static void canid_print_usage(FILE *fd)
+{
+ fprintf(fd,
+ "Usage: canid(IDLIST)\n" \
+ "where: IDLIST := IDSPEC [ IDLIST ]\n" \
+ " IDSPEC := { ’sff’ CANID | ’eff’ CANID }\n" \
+ " CANID := ID[:MASK]\n" \
+ " ID, MASK := hexadecimal number (i.e. 0x123)\n" \
+ "Example: canid(sff 0x123 sff 0x124 sff 0x125:0xf)\n");
+}
+
+static int canid_parse_rule(struct rules *rules, struct bstr *a, int iseff)
+{
+ unsigned int can_id = 0;
+ unsigned int can_mask = 0;
+
+ if (sscanf(a->data, "%"SCNx32 ":" "%"SCNx32, &can_id, &can_mask) != 2) {
+ if (sscanf(a->data, "%"SCNx32, &can_id) != 1) {
+ return -1;
+ } else {
+ can_mask = (iseff) ? CAN_EFF_MASK : CAN_SFF_MASK;
+ }
+ }
+
+ /* Stretch rules array up to EM_CANID_RULES_MAX if necessary */
+ if (rules->rules_cnt == rules->rules_capacity) {
+ if (rules->rules_capacity <= EM_CANID_RULES_MAX/2) {
+ rules->rules_capacity *= 2;
+ rules->rules_raw = realloc(rules->rules_raw,
+ sizeof(struct can_filter) * rules->rules_capacity);
+ } else {
+ return -2;
+ }
+ }
+
+ rules->rules_raw[rules->rules_cnt].can_id =
+ can_id | ((iseff) ? CAN_EFF_FLAG : 0);
+ rules->rules_raw[rules->rules_cnt].can_mask =
+ can_mask | CAN_EFF_FLAG;
+
+ rules->rules_cnt++;
+
+ return 0;
+}
+
+static int canid_parse_eopt(struct nlmsghdr *n, struct tcf_ematch_hdr *hdr,
+ struct bstr *args)
+{
+ int iseff = 0;
+ int ret = 0;
+ struct rules rules = {
+ .rules_capacity = 25, /* Denominator of EM_CANID_RULES_MAX
+ Will be multiplied by 2 to calculate the size for realloc() */
+ .rules_cnt = 0
+ };
+
+#define PARSE_ERR(CARG, FMT, ARGS...) \
+ em_parse_error(EINVAL, args, CARG, &canid_ematch_util, FMT, ##ARGS)
+
+ if (args == NULL)
+ return PARSE_ERR(args, "canid: missing arguments");
+
+ rules.rules_raw = malloc(sizeof(struct can_filter) * rules.rules_capacity);
+ memset(rules.rules_raw, 0, sizeof(struct can_filter) * rules.rules_capacity);
+
+ do {
+ if (!bstrcmp(args, "sff")) {
+ iseff = 0;
+ } else if (!bstrcmp(args, "eff")) {
+ iseff = 1;
+ } else {
+ ret = PARSE_ERR(args, "canid: invalid key");
+ goto exit;
+ }
+
+ args = bstr_next(args);
+ if (args == NULL) {
+ ret = PARSE_ERR(args, "canid: missing argument");
+ goto exit;
+ }
+
+ ret = canid_parse_rule(&rules, args, iseff);
+ if (ret == -1) {
+ ret = PARSE_ERR(args, "canid: Improperly formed CAN ID & mask\n");
+ goto exit;
+ } else if (ret == -2) {
+ ret = PARSE_ERR(args, "canid: Too many arguments on input\n");
+ goto exit;
+ }
+ } while ((args = bstr_next(args)) != NULL);
+
+ addraw_l(n, MAX_MSG, hdr, sizeof(*hdr));
+ addraw_l(n, MAX_MSG, rules.rules_raw,
+ sizeof(struct can_filter) * rules.rules_cnt);
+
+#undef PARSE_ERR
+exit:
+ free(rules.rules_raw);
+ return ret;
+}
+
+static int canid_print_eopt(FILE *fd, struct tcf_ematch_hdr *hdr, void *data,
+ int data_len)
+{
+ struct can_filter *conf = data; /* Array with rules */
+ int rules_count;
+ int i;
+
+ rules_count = data_len / sizeof(struct can_filter);
+
+ for (i = 0; i < rules_count; i++) {
+ struct can_filter *pcfltr = &conf[i];
+
+ if (pcfltr->can_id & CAN_EFF_FLAG) {
+ if (pcfltr->can_mask == (CAN_EFF_FLAG | CAN_EFF_MASK))
+ fprintf(fd, "eff 0x%"PRIX32,
+ pcfltr->can_id & CAN_EFF_MASK);
+ else
+ fprintf(fd, "eff 0x%"PRIX32":0x%"PRIX32,
+ pcfltr->can_id & CAN_EFF_MASK,
+ pcfltr->can_mask & CAN_EFF_MASK);
+ } else {
+ if (pcfltr->can_mask == (CAN_EFF_FLAG | CAN_SFF_MASK))
+ fprintf(fd, "sff 0x%"PRIX32,
+ pcfltr->can_id & CAN_SFF_MASK);
+ else
+ fprintf(fd, "sff 0x%"PRIX32":0x%"PRIX32,
+ pcfltr->can_id & CAN_SFF_MASK,
+ pcfltr->can_mask & CAN_SFF_MASK);
+ }
+
+ if ((i + 1) < rules_count)
+ fprintf(fd, " ");
+ }
+
+ return 0;
+}
+
+struct ematch_util canid_ematch_util = {
+ .kind = "canid",
+ .kind_num = TCF_EM_CANID,
+ .parse_eopt = canid_parse_eopt,
+ .print_eopt = canid_print_eopt,
+ .print_usage = canid_print_usage
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ipv4: percpu nh_rth_output cache
From: Eric Dumazet @ 2012-07-31 15:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
From: Eric Dumazet <edumazet@google.com>
Input path is mostly run under RCU and doesnt touch dst refcnt
But output path on forwarding or UDP workloads hits
badly dst refcount, and we have lot of false sharing, for example
in ipv4_mtu() when reading rt->rt_pmtu
Using a percpu cache for nh_rth_output gives a nice performance
increase at a small cost.
24 udpflood test on my 24 cpu machine (dummy0 output device)
(each process sends 1.000.000 udp frames, 24 processes are started)
before : 5.24 s
after : 2.06 s
For reference, time on linux-3.5 : 6.60 s
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
On top on previous "ipv4: Restore old dst_free() behavior" patch
We probably can remove all paddings in struct dst_entry
include/net/ip_fib.h | 3 ++-
net/ipv4/fib_semantics.c | 19 ++++++++++++++++++-
net/ipv4/route.c | 20 +++++++++++++++-----
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index e521a03..a0f003d 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -21,6 +21,7 @@
#include <linux/rcupdate.h>
#include <net/fib_rules.h>
#include <net/inetpeer.h>
+#include <linux/percpu.h>
struct fib_config {
u8 fc_dst_len;
@@ -81,7 +82,7 @@ struct fib_nh {
__be32 nh_gw;
__be32 nh_saddr;
int nh_saddr_genid;
- struct rtable __rcu *nh_rth_output;
+ struct rtable * __percpu *nh_pcpu_rth_output;
struct rtable __rcu *nh_rth_input;
struct fnhe_hash_bucket *nh_exceptions;
};
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 625cf18..c8bf86e 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -176,6 +176,22 @@ static void rt_nexthop_free(struct rtable __rcu **rtp)
dst_free(&rt->dst);
}
+static void rt_nexthop_free_cpus(struct rtable * __percpu *rtp)
+{
+ int cpu;
+
+ if (!rtp)
+ return;
+
+ for_each_possible_cpu(cpu) {
+ struct rtable *rt = *per_cpu_ptr(rtp, cpu);
+
+ if (rt)
+ dst_free(&rt->dst);
+ }
+ free_percpu(rtp);
+}
+
/* Release a nexthop info record */
static void free_fib_info_rcu(struct rcu_head *head)
{
@@ -186,7 +202,7 @@ static void free_fib_info_rcu(struct rcu_head *head)
dev_put(nexthop_nh->nh_dev);
if (nexthop_nh->nh_exceptions)
free_nh_exceptions(nexthop_nh);
- rt_nexthop_free(&nexthop_nh->nh_rth_output);
+ rt_nexthop_free_cpus(nexthop_nh->nh_pcpu_rth_output);
rt_nexthop_free(&nexthop_nh->nh_rth_input);
} endfor_nexthops(fi);
@@ -817,6 +833,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
fi->fib_nhs = nhs;
change_nexthops(fi) {
nexthop_nh->nh_parent = fi;
+ nexthop_nh->nh_pcpu_rth_output = alloc_percpu(struct rtable *);
} endfor_nexthops(fi)
if (cfg->fc_mx) {
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 2bd1074..d5efcfe 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1206,11 +1206,16 @@ static inline void rt_free(struct rtable *rt)
static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
{
- struct rtable *orig, *prev, **p = (struct rtable **)&nh->nh_rth_output;
+ struct rtable *orig, *prev, **p;
- if (rt_is_input_route(rt))
+ if (rt_is_input_route(rt)) {
p = (struct rtable **)&nh->nh_rth_input;
-
+ } else {
+ if (!nh->nh_pcpu_rth_output)
+ goto nocache;
+ p = per_cpu_ptr(nh->nh_pcpu_rth_output,
+ raw_smp_processor_id());
+ }
orig = *p;
prev = cmpxchg(p, orig, rt);
@@ -1223,6 +1228,7 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
* unsuccessful at storing this route into the cache
* we really need to set it.
*/
+nocache:
rt->dst.flags |= DST_NOCACHE;
}
}
@@ -1749,8 +1755,12 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
fnhe = NULL;
if (fi) {
fnhe = find_exception(&FIB_RES_NH(*res), fl4->daddr);
- if (!fnhe) {
- rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_output);
+ if (!fnhe && FIB_RES_NH(*res).nh_pcpu_rth_output) {
+ struct rtable **prth;
+
+ prth = per_cpu_ptr(FIB_RES_NH(*res).nh_pcpu_rth_output,
+ raw_smp_processor_id());
+ rth = rcu_dereference(*(__force __rcu struct rtable **)prth);
if (rt_cache_valid(rth)) {
dst_hold(&rth->dst);
return rth;
^ permalink raw reply related
* Re: CPU: 0 Not tainted (3.1.9+ #1) when ifconfig rose0 down
From: Bernard Pidoux @ 2012-07-31 15:27 UTC (permalink / raw)
To: linux-hams, Linux Netdev List
In-Reply-To: <5017E786.5000102@free.fr>
Here is a complementary observation.
Trying to remove rose module with rmmod rose did not create any kernel
panic.
However, there is an endless message from the kernel saying :
Message from syslogd@raspberrypi at Jul 31 17:22:40 ...
kernel:[ 831.579007] unregister_netdevice: waiting for rose0 to
become free. Usage count = 23
Message from syslogd@raspberrypi at Jul 31 17:22:50 ...
kernel:[ 841.739390] unregister_netdevice: waiting for rose0 to
become free. Usage count = 23
Message from syslogd@raspberrypi at Jul 31 17:23:00 ...
kernel:[ 851.899758] unregister_netdevice: waiting for rose0 to
become free. Usage count = 23
.....
As observed at many occasions, count number seems to be random ! and
the same message keeps going without any change of count number.
At the same time, there is no possibility to recover the command line on
any console.
However I could loggin via ssh and I noticed that rose0 device is
actually no more in the ifconfig list.
If I try to remove rose with rmmod rose I get :
root@raspberrypi:/home/pi# rmmod rose
libkmod: ERROR ../libkmod/libkmod-module.c:753
kmod_module_remove_module: could not remove 'rose': Device or resource busy
Error: could not remove module rose: Device or resource busy
Does this help ?
On 31/07/2012 16:11, Bernard Pidoux wrote:
> Hi,
>
> I observe systematically a kernel panic when I try to shutdown rose0
> device using ifconfig rose0 down
>
> This is happening on two very different ROSE implementation, one is on a
> machine with x86-64 kernel 4.6.3 on an Intel core 2 duo CPU
> the other is on a RaspBerry Pi with Raspbian and 3.1.9+ wheezy kernel
> recompiled with AX.25 modules (ax25, rose, netrom, 6pack, kiss) enabled.
>
> Here is an image of the screen dump :
>
> http://f6bvp.org/photos/rose_device_event.JPG
>
> It can be noticed that PC is at rose_device_event and
> LR is at sock_def_wakeup
>
> One thing to be noticed is that when I close before all ROSE and AX.25
> applications, there are still a few populated sockets, probably for one
> of the program did not close the sockets properly.
>
> I that case, does rose module should accept to shutdown rose0 device ?
> However, I guess that it should not create a kernel panic due to a
> kernel NULL pointer.
>
> I don't know what to do in order to debug that issue.
>
> Bernard
>
^ permalink raw reply
* Re: [PATCH] ipv4: percpu nh_rth_output cache
From: Eric Dumazet @ 2012-07-31 15:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
In-Reply-To: <1343748166.21269.304.camel@edumazet-glaptop>
On Tue, 2012-07-31 at 17:22 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> + p = per_cpu_ptr(nh->nh_pcpu_rth_output,
> + raw_smp_processor_id());
> + }
Note : this can use :
p = __this_cpu_ptr(nh->nh_pcpu_rth_output);
and same thing in __mkroute_output()
prth = __this_cpu_ptr(FIB_RES_NH(*res).nh_pcpu_rth_output);
^ permalink raw reply
* [PATCH v2] ipv4: percpu nh_rth_output cache
From: Eric Dumazet @ 2012-07-31 15:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Alexander Duyck
From: Eric Dumazet <edumazet@google.com>
Input path is mostly run under RCU and doesnt touch dst refcnt
But output path on forwarding or UDP workloads hits
badly dst refcount, and we have lot of false sharing, for example
in ipv4_mtu() when reading rt->rt_pmtu
Using a percpu cache for nh_rth_output gives a nice performance
increase at a small cost.
24 udpflood test on my 24 cpu machine (dummy0 output device)
(each process sends 1.000.000 udp frames, 24 processes are started)
before : 5.24 s
after : 2.06 s
For reference, time on linux-3.5 : 6.60 s
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
v2: use __this_cpu_ptr() and slighly better annotations to avoid
ugly casts
On top on previous "ipv4: Restore old dst_free() behavior" patch
We probably can remove all paddings in struct dst_entry
include/net/ip_fib.h | 3 ++-
net/ipv4/fib_semantics.c | 20 +++++++++++++++++++-
net/ipv4/route.c | 18 +++++++++++++-----
3 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index e521a03..e331746 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -21,6 +21,7 @@
#include <linux/rcupdate.h>
#include <net/fib_rules.h>
#include <net/inetpeer.h>
+#include <linux/percpu.h>
struct fib_config {
u8 fc_dst_len;
@@ -81,7 +82,7 @@ struct fib_nh {
__be32 nh_gw;
__be32 nh_saddr;
int nh_saddr_genid;
- struct rtable __rcu *nh_rth_output;
+ struct rtable __rcu * __percpu *nh_pcpu_rth_output;
struct rtable __rcu *nh_rth_input;
struct fnhe_hash_bucket *nh_exceptions;
};
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 625cf18..fe2ca02 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -176,6 +176,23 @@ static void rt_nexthop_free(struct rtable __rcu **rtp)
dst_free(&rt->dst);
}
+static void rt_nexthop_free_cpus(struct rtable __rcu * __percpu *rtp)
+{
+ int cpu;
+
+ if (!rtp)
+ return;
+
+ for_each_possible_cpu(cpu) {
+ struct rtable *rt;
+
+ rt = rcu_dereference_protected(*per_cpu_ptr(rtp, cpu), 1);
+ if (rt)
+ dst_free(&rt->dst);
+ }
+ free_percpu(rtp);
+}
+
/* Release a nexthop info record */
static void free_fib_info_rcu(struct rcu_head *head)
{
@@ -186,7 +203,7 @@ static void free_fib_info_rcu(struct rcu_head *head)
dev_put(nexthop_nh->nh_dev);
if (nexthop_nh->nh_exceptions)
free_nh_exceptions(nexthop_nh);
- rt_nexthop_free(&nexthop_nh->nh_rth_output);
+ rt_nexthop_free_cpus(nexthop_nh->nh_pcpu_rth_output);
rt_nexthop_free(&nexthop_nh->nh_rth_input);
} endfor_nexthops(fi);
@@ -817,6 +834,7 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
fi->fib_nhs = nhs;
change_nexthops(fi) {
nexthop_nh->nh_parent = fi;
+ nexthop_nh->nh_pcpu_rth_output = alloc_percpu(struct rtable __rcu *);
} endfor_nexthops(fi)
if (cfg->fc_mx) {
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 2bd1074..4f6276c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1206,11 +1206,15 @@ static inline void rt_free(struct rtable *rt)
static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
{
- struct rtable *orig, *prev, **p = (struct rtable **)&nh->nh_rth_output;
+ struct rtable *orig, *prev, **p;
- if (rt_is_input_route(rt))
+ if (rt_is_input_route(rt)) {
p = (struct rtable **)&nh->nh_rth_input;
-
+ } else {
+ if (!nh->nh_pcpu_rth_output)
+ goto nocache;
+ p = (struct rtable **)__this_cpu_ptr(nh->nh_pcpu_rth_output);
+ }
orig = *p;
prev = cmpxchg(p, orig, rt);
@@ -1223,6 +1227,7 @@ static void rt_cache_route(struct fib_nh *nh, struct rtable *rt)
* unsuccessful at storing this route into the cache
* we really need to set it.
*/
+nocache:
rt->dst.flags |= DST_NOCACHE;
}
}
@@ -1749,8 +1754,11 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
fnhe = NULL;
if (fi) {
fnhe = find_exception(&FIB_RES_NH(*res), fl4->daddr);
- if (!fnhe) {
- rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_output);
+ if (!fnhe && FIB_RES_NH(*res).nh_pcpu_rth_output) {
+ struct rtable __rcu **prth;
+
+ prth = __this_cpu_ptr(FIB_RES_NH(*res).nh_pcpu_rth_output);
+ rth = rcu_dereference(*prth);
if (rt_cache_valid(rth)) {
dst_hold(&rth->dst);
return rth;
^ permalink raw reply related
* Re: [PATCH] mac80211: use eth_broadcast_addr
From: Joe Perches @ 2012-07-31 15:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg, netdev
In-Reply-To: <1343744471-5910-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2012-07-31 at 16:21 +0200, Johannes Berg wrote:
> Instead of memset().
Maybe just do them all?
git ls-files net drivers/net |
xargs perl -p -i -e 's/\bmemset\s*\(\s*([^,]+),\s*(?i:0xff|255)\s*\,\s*(ETH_ALEN|6)\s*\)/eth_broadcast_addr\(\1\)/g'
^ permalink raw reply
* [PATCH v2 0/6] mv643xx Ethernet DT support and CSB1724 board support.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
Respin of the previous patch. All comments have been addressed.
Addressed:
* Typos
* Docs
* Automatic clock detection / setup
* PHY addresses are not | 0x80 anymore
- which is a horrid way for the driver to be doing things but hey...
* property added to DT bindings for tx_csum_limit
* GFP_ATOMIC allocations demoted to GFP_KERNEL (cpoypaste error)
* devide order in .dts(i) files fixed
Outstanding:
* Should the tx_csum_limit issue be addressed by:
- a new device name
- detecting the host platform
- a property (present solution).
Ian Molton (6):
Initial csb1724 board support (FDT)
mv643xx.c: Remove magic numbers.
mv643xx.c: Add basic device tree support.
kirkwood: Add a clock setup helper for mv643xx ethernet.
csb1724: Enable device tree based mv643xx ethernet support.
DT: Convert all kirkwood boards with mv643xx that use DT
Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
arch/arm/boot/dts/kirkwood-csb1724.dts | 49 +++++++++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 9 ++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 18 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 8 ++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 10 ++
arch/arm/boot/dts/kirkwood-iconnect.dts | 10 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 17 +++
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 8 +-
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 8 +-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 3 +
arch/arm/boot/dts/kirkwood.dtsi | 33 ++++++
arch/arm/configs/csb1724_defconfig | 92 ++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 ++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-csb1724.c | 60 ++++++++++
arch/arm/mach-kirkwood/board-dnskw.c | 7 +-
arch/arm/mach-kirkwood/board-dreamplug.c | 13 +--
arch/arm/mach-kirkwood/board-dt.c | 11 ++
arch/arm/mach-kirkwood/board-goflexnet.c | 7 +-
arch/arm/mach-kirkwood/board-ib62x0.c | 7 +-
arch/arm/mach-kirkwood/board-iconnect.c | 7 +-
arch/arm/mach-kirkwood/board-lsxl.c | 13 +--
arch/arm/mach-kirkwood/board-ts219.c | 10 +-
arch/arm/mach-kirkwood/common.c | 22 ++++
arch/arm/mach-kirkwood/common.h | 9 ++
drivers/net/ethernet/marvell/mv643xx_eth.c | 122 ++++++++++++++++++---
28 files changed, 565 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/mv643xx.txt
create mode 100644 arch/arm/boot/dts/kirkwood-csb1724.dts
create mode 100644 arch/arm/configs/csb1724_defconfig
create mode 100644 arch/arm/mach-kirkwood/board-csb1724.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 4/6] kirkwood: Add a clock setup helper for mv643xx ethernet.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch adds an ethernet setup helper function allowing the mv643xx
clock to be kept enabled so that the MAC address(es) are not lost.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/mach-kirkwood/board-dt.c | 2 ++
arch/arm/mach-kirkwood/common.c | 22 ++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 3 +++
3 files changed, 27 insertions(+)
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 9816b85..1bcae22 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -97,6 +97,8 @@ static void __init kirkwood_dt_init(void)
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
+
+ kirkwood_eth_clock_fixup();
}
static const char *kirkwood_dt_board_compat[] = {
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index c4b64ad..57b91cf 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -18,6 +18,7 @@
#include <linux/clk-provider.h>
#include <linux/spinlock.h>
#include <linux/mv643xx_i2c.h>
+#include <linux/of.h>
#include <net/dsa.h>
#include <asm/page.h>
#include <asm/timex.h>
@@ -293,6 +294,27 @@ void __init kirkwood_ehci_init(void)
orion_ehci_init(USB_PHYS_BASE, IRQ_KIRKWOOD_USB, EHCI_PHY_NA);
}
+/* Fixup ethernet clocks for DT based kirkwood platforms.
+ * This is required because if the clock is not kept running, the
+ * Interface will forget its MAC address.
+ */
+#ifdef CONFIG_OF
+void __init kirkwood_eth_clock_fixup(void)
+{
+ struct device_node *np;
+
+ np = of_find_node_by_name(NULL, "egiga0");
+ if (np && of_device_is_available(np))
+ clk_prepare_enable(ge0);
+ of_node_put(np);
+
+ np = of_find_node_by_name(NULL, "egiga1");
+ if (np && of_device_is_available(np))
+ clk_prepare_enable(ge1);
+ of_node_put(np);
+
+}
+#endif
/*****************************************************************************
* GE00
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 8aab1ae..7183718 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -36,6 +36,9 @@ void kirkwood_enable_pcie(void);
void kirkwood_pcie_id(u32 *dev, u32 *rev);
void kirkwood_ehci_init(void);
+#ifdef CONFIG_OF
+void kirkwood_eth_clock_fixup(void);
+#endif
void kirkwood_ge00_init(struct mv643xx_eth_platform_data *eth_data);
void kirkwood_ge01_init(struct mv643xx_eth_platform_data *eth_data);
void kirkwood_ge00_switch_init(struct dsa_platform_data *d, int irq);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/6] Initial csb1724 board support (FDT)
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch adds support for the csb1724 SoM.
It includes serial and SATA support.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-csb1724.dts | 30 ++++++++++++++++
arch/arm/configs/csb1724_defconfig | 47 +++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 ++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-csb1724.c | 59 ++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-dt.c | 4 +++
arch/arm/mach-kirkwood/common.h | 6 ++++
8 files changed, 155 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-csb1724.dts
create mode 100644 arch/arm/configs/csb1724_defconfig
create mode 100644 arch/arm/mach-kirkwood/board-csb1724.c
diff --git a/arch/arm/boot/dts/kirkwood-csb1724.dts b/arch/arm/boot/dts/kirkwood-csb1724.dts
new file mode 100644
index 0000000..44dfe9a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-csb1724.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "Cogent CSB1724-88F-628X SoM";
+ compatible = "cogent,csb1724", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ };
+
+ ocp@f1000000 {
+ serial@12000 {
+ clock-frequency = <200000000>;
+ status = "ok";
+ };
+
+ sata@80000 {
+ nr-ports = <2>;
+ status = "ok";
+ };
+ };
+
+};
diff --git a/arch/arm/configs/csb1724_defconfig b/arch/arm/configs/csb1724_defconfig
new file mode 100644
index 0000000..927b269
--- /dev/null
+++ b/arch/arm/configs/csb1724_defconfig
@@ -0,0 +1,47 @@
+CONFIG_ARCH_KIRKWOOD=y
+CONFIG_ARCH_KIRKWOOD_DT=y
+CONFIG_MACH_CSB1724_DT=y
+CONFIG_EMBEDDED=y
+CONFIG_EXPERT=y
+CONFIG_EXPERIMENTAL=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_VFP=y
+CONFIG_AEABI=y
+CONFIG_OABI_COMPAT=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_SATA_MV=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_2=y
+CONFIG_NLS_UTF8=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_FS=y
+CONFIG_TIMER_STATS=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_USER=y
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_DTC=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_EXT4_FS=y
+CONFIG_SYSVIPC=y
+CONFIG_SYSVIPC_SYSCTL=y
+CONFIG_TICK_ONESHOT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
+CONFIG_DYNAMIC_DEBUG=y
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index ca5c15a..6d51c50 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -109,6 +109,13 @@ config MACH_LSXL_DT
Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
Flattened Device Tree.
+config MACH_CSB1724_DT
+ bool "Cogent CSB1724 SoM (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the
+ Cogent CSB1724 SoM, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 055c85a..665ed63 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
+obj-$(CONFIG_MACH_CSB1724_DT) += board-csb1724.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index 2a576ab..899bc80 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -2,6 +2,7 @@
params_phys-y := 0x00000100
initrd_phys-y := 0x00800000
+dtb-$(CONFIG_MACH_CSB1724_DT) += kirkwood-csb1724.dtb
dtb-$(CONFIG_MACH_DREAMPLUG_DT) += kirkwood-dreamplug.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns320.dtb
dtb-$(CONFIG_MACH_DLINK_KIRKWOOD_DT) += kirkwood-dns325.dtb
diff --git a/arch/arm/mach-kirkwood/board-csb1724.c b/arch/arm/mach-kirkwood/board-csb1724.c
new file mode 100644
index 0000000..979112d
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-csb1724.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2012 (C), Ian Molton <ian.molton@codethink.co.uk>
+ *
+ * arch/arm/mach-kirkwood/board-csb1724.c
+ *
+ * Cogent csb1724 Board Init for drivers not converted to
+ * flattened device tree yet.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include "mpp.h"
+
+static unsigned int csb1724_mpp_config[] __initdata = {
+ MPP0_NF_IO2,
+ MPP1_NF_IO3,
+ MPP2_NF_IO4,
+ MPP3_NF_IO5,
+ MPP4_NF_IO6,
+ MPP5_NF_IO7,
+ MPP8_TW0_SDA,
+ MPP9_TW0_SCK,
+ MPP12_SD_CLK,
+ MPP13_SD_CMD,
+ MPP14_SD_D0,
+ MPP15_SD_D1,
+ MPP16_SD_D2,
+ MPP17_SD_D3,
+ MPP18_NF_IO0,
+ MPP19_NF_IO1,
+ MPP20_GE1_TXD0,
+ MPP21_GE1_TXD1,
+ MPP22_GE1_TXD2,
+ MPP23_GE1_TXD3,
+ MPP24_GE1_RXD0,
+ MPP25_GE1_RXD1,
+ MPP26_GE1_RXD2,
+ MPP27_GE1_RXD3,
+ MPP30_GE1_RXCTL,
+ MPP31_GE1_RXCLK,
+ MPP32_GE1_TCLKOUT,
+ MPP33_GE1_TXCTL,
+ MPP34_SATA1_ACTn,
+ MPP35_SATA0_ACTn,
+ MPP36_TW1_SDA,
+ MPP37_TW1_SCK,
+};
+
+void __init csb1724_init(void)
+{
+ /*
+ * Basic setup. Needs to be called early.
+ */
+ kirkwood_mpp_conf(csb1724_mpp_config);
+}
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index e4eb450..7679f7f 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -87,6 +87,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("buffalo,lsxl"))
lsxl_init();
+ if (of_machine_is_compatible("cogent,csb1724"))
+ csb1724_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -100,6 +103,7 @@ static const char *kirkwood_dt_board_compat[] = {
"qnap,ts219",
"seagate,goflexnet",
"buffalo,lsxl",
+ "cogent,csb1724",
NULL
};
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 304dd1a..8aab1ae 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -94,6 +94,12 @@ void lsxl_init(void);
static inline void lsxl_init(void) {};
#endif
+#ifdef CONFIG_MACH_CSB1724_DT
+void csb1724_init(void);
+#else
+static inline void csb1724_init(void) {};
+#endif
+
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch adds basic device tree support to the mv643xx ethernet driver.
It should be enough for most current users of the device, and should allow
a fairly painless migration once proper support for clk devices is available
to those platforms.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
arch/arm/mach-kirkwood/board-dt.c | 5 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 119 ++++++++++++++++++---
3 files changed, 185 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/mv643xx.txt
diff --git a/Documentation/devicetree/bindings/net/mv643xx.txt b/Documentation/devicetree/bindings/net/mv643xx.txt
new file mode 100644
index 0000000..2727f79
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mv643xx.txt
@@ -0,0 +1,75 @@
+mv643xx related nodes.
+
+marvell,mdio-mv643xx:
+
+Required properties:
+
+ - interrupts : <a> where a is the SMI interrupt number.
+ - reg : the base address and size of the controllers register space.
+
+Optional properties:
+ - shared_smi : on some chips, the second PHY is "shared", meaning it is
+ really accessed via the first SMI controller. It is passed in this
+ way due to the present structure of the driver, which requires the
+ base address for the MAC to be passed in via the SMI controllers
+ platform data.
+ - tx_csum_limit : on some devices, this option is required for proper
+ operation wrt. jumbo frames.
+
+
+Example:
+
+smi0: mdio@72000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x72000 0x4000>;
+ interrupts = <46>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+};
+
+smi1: mdio@76000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x76000 0x4000>;
+ interrupts = <47>;
+ shared_smi = <&smi0>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+};
+
+
+
+marvell,mv643xx-eth:
+
+Required properties:
+ - interrupts : the port interrupt number.
+ - mdio : phandle of the smi device as drescribed above
+
+Optional properties:
+ - port_number : the port number on this bus.
+ - phy_addr : the PHY address.
+ - reg : should match the mdio reg this device is attached to.
+ this is a required hack for now due to the way the
+ driver is constructed. This allows the device clock to be
+ kept running so that the MAC is not lost after boot.
+
+
+Example:
+
+egiga0 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x72000 0x4000>;
+ mdio = <&smi0>;
+ port_number = <0>;
+ phy_addr = <0x80>;
+ interrupts = <11>;
+};
+
+egiga1 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x76000 0x4000>;
+ mdio = <&smi1>;
+ port_number = <0>;
+ phy_addr = <0x81>;
+ interrupts = <15>;
+};
+
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 7679f7f..9816b85 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/mv643xx_eth.h>
#include <linux/kexec.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -33,6 +34,10 @@ struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("marvell,orion-wdt", 0xf1020300, "orion_wdt", NULL),
OF_DEV_AUXDATA("marvell,orion-sata", 0xf1080000, "sata_mv.0", NULL),
OF_DEV_AUXDATA("marvell,orion-nand", 0xf4000000, "orion_nand", NULL),
+ OF_DEV_AUXDATA("marvell,mv643xx", 0xf1072000, MV643XX_ETH_NAME ".0",
+ NULL),
+ OF_DEV_AUXDATA("marvell,mv643xx", 0xf1076000, MV643XX_ETH_NAME ".1",
+ NULL),
{},
};
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 92497eb..733c69f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -48,6 +48,9 @@
#include <linux/ethtool.h>
#include <linux/platform_device.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_irq.h>
#include <linux/kernel.h>
#include <linux/spinlock.h>
#include <linux/workqueue.h>
@@ -2601,11 +2604,11 @@ static void infer_hw_params(struct mv643xx_eth_shared_private *msp)
static int mv643xx_eth_shared_probe(struct platform_device *pdev)
{
static int mv643xx_eth_version_printed;
- struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
+ struct mv643xx_eth_shared_platform_data *pd;
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
- int ret;
+ int ret, irq = -1;
if (!mv643xx_eth_version_printed++)
pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
@@ -2625,6 +2628,26 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
if (msp->base == NULL)
goto out_free;
+ if (pdev->dev.of_node) {
+ struct device_node *np = NULL;
+
+ /* when all users of this driver use FDT, we can remove this */
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_dbg(&pdev->dev, "Could not allocate platform data\n");
+ goto out_free;
+ }
+
+ of_property_read_u32(pdev->dev.of_node,
+ "tx_csum_limit", &pd->tx_csum_limit);
+
+ np = of_parse_phandle(pdev->dev.of_node, "shared_smi", 0);
+ if (np)
+ pd->shared_smi = of_find_device_by_node(np);
+
+ } else {
+ pd = pdev->dev.platform_data;
+ }
/*
* Set up and register SMI bus.
*/
@@ -2654,15 +2677,22 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
/*
* Check whether the error interrupt is hooked up.
*/
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res != NULL) {
+ if (pdev->dev.of_node) {
+ irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (res)
+ irq = res->start;
+ }
+
+ if (irq != -1) {
int err;
- err = request_irq(res->start, mv643xx_eth_err_irq,
+ err = request_irq(irq, mv643xx_eth_err_irq,
IRQF_SHARED, "mv643xx_eth", msp);
if (!err) {
writel(ERR_INT_SMI_DONE, msp->base + ERR_INT_MASK);
- msp->err_interrupt = res->start;
+ msp->err_interrupt = irq;
}
}
@@ -2675,6 +2705,10 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
pd->tx_csum_limit : 9 * 1024;
+
+ if (pdev->dev.of_node)
+ kfree(pd); /* If we created a fake pd, free it now */
+
infer_hw_params(msp);
platform_set_drvdata(pdev, msp);
@@ -2708,12 +2742,21 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id mv_mdio_dt_ids[] __devinitdata = {
+ { .compatible = "marvell,mdio-mv643xx", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mv_mdio_dt_ids);
+#endif
+
static struct platform_driver mv643xx_eth_shared_driver = {
.probe = mv643xx_eth_shared_probe,
.remove = mv643xx_eth_shared_remove,
.driver = {
.name = MV643XX_ETH_SHARED_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mv_mdio_dt_ids),
},
};
@@ -2873,7 +2916,36 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
struct resource *res;
int err;
- pd = pdev->dev.platform_data;
+ if (pdev->dev.of_node) {
+ struct device_node *np = NULL;
+
+ /* when all users of this driver use FDT, we can remove this */
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_dbg(&pdev->dev, "Could not allocate platform data\n");
+ return -ENOMEM;
+ }
+
+ of_property_read_u32(pdev->dev.of_node,
+ "port_number", &pd->port_number);
+
+ if(!of_property_read_u32(pdev->dev.of_node,
+ "phy_addr", &pd->phy_addr))
+ pd->phy_addr = MV643XX_ETH_PHY_ADDR(pd->phy_addr);
+ else
+ pd->phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT;
+
+ np = of_parse_phandle(pdev->dev.of_node, "mdio", 0);
+ if (np) {
+ pd->shared = of_find_device_by_node(np);
+ } else {
+ kfree(pd);
+ return -ENODEV;
+ }
+ } else {
+ pd = pdev->dev.platform_data;
+ }
+
if (pd == NULL) {
dev_err(&pdev->dev, "no mv643xx_eth_platform_data\n");
return -ENODEV;
@@ -2881,12 +2953,15 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
if (pd->shared == NULL) {
dev_err(&pdev->dev, "no mv643xx_eth_platform_data->shared\n");
- return -ENODEV;
+ err = -ENODEV;
+ goto out_free_pd;
}
dev = alloc_etherdev_mq(sizeof(struct mv643xx_eth_private), 8);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ err = -ENOMEM;
+ goto out_free_pd;
+ }
mp = netdev_priv(dev);
platform_set_drvdata(pdev, mp);
@@ -2923,6 +2998,8 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
init_pscr(mp, pd->speed, pd->duplex);
+ if (pdev->dev.of_node)
+ kfree(pd); /* If we created a fake pd, free it now */
mib_counters_clear(mp);
@@ -2942,10 +3019,13 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
mp->rx_oom.data = (unsigned long)mp;
mp->rx_oom.function = oom_timer_wrapper;
-
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- BUG_ON(!res);
- dev->irq = res->start;
+ if (pdev->dev.of_node) {
+ dev->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ BUG_ON(!res);
+ dev->irq = res->start;
+ }
dev->netdev_ops = &mv643xx_eth_netdev_ops;
@@ -2991,6 +3071,8 @@ out:
}
#endif
free_netdev(dev);
+out_free_pd:
+ kfree(pd);
return err;
}
@@ -3030,6 +3112,14 @@ static void mv643xx_eth_shutdown(struct platform_device *pdev)
port_reset(mp);
}
+#ifdef CONFIG_OF
+static struct of_device_id mv_eth_dt_ids[] __devinitdata = {
+ { .compatible = "marvell,mv643xx-eth", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mv_eth_dt_ids);
+#endif
+
static struct platform_driver mv643xx_eth_driver = {
.probe = mv643xx_eth_probe,
.remove = mv643xx_eth_remove,
@@ -3037,6 +3127,7 @@ static struct platform_driver mv643xx_eth_driver = {
.driver = {
.name = MV643XX_ETH_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mv_eth_dt_ids),
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 5/6] csb1724: Enable device tree based mv643xx ethernet support.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch enables mv643xx based ethernet built into the SoM on the
csb1724, via flattened device tree.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-csb1724.dts | 19 ++++++++++++++
arch/arm/boot/dts/kirkwood.dtsi | 33 +++++++++++++++++++++++
arch/arm/configs/csb1724_defconfig | 45 ++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/board-csb1724.c | 1 +
4 files changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/kirkwood-csb1724.dts b/arch/arm/boot/dts/kirkwood-csb1724.dts
index 44dfe9a..f43f8dd 100644
--- a/arch/arm/boot/dts/kirkwood-csb1724.dts
+++ b/arch/arm/boot/dts/kirkwood-csb1724.dts
@@ -25,6 +25,25 @@
nr-ports = <2>;
status = "ok";
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <1>;
+ status = "ok";
+ };
+
};
};
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index cef9616..f5f1f92 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -76,6 +76,39 @@
status = "okay";
};
+ smi0: mdio@72000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x72000 0x4000>;
+ interrupts = <46>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+ };
+
+ egiga0 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x72000 0x4000>;
+ mdio = <&smi0>;
+ interrupts = <11>;
+ status = "disabled";
+ };
+
+ smi1: mdio@76000 {
+ compatible = "marvell,mdio-mv643xx";
+ reg = <0x76000 0x4000>;
+ interrupts = <47>;
+ shared_smi = <&smi0>;
+ tx_csum_limit = <1600>;
+ status = "disabled";
+ };
+
+ egiga1 {
+ compatible = "marvell,mv643xx-eth";
+ reg = <0x76000 0x4000>;
+ mdio = <&smi1>;
+ interrupts = <15>;
+ status = "disabled";
+ };
+
sata@80000 {
compatible = "marvell,orion-sata";
reg = <0x80000 0x5000>;
diff --git a/arch/arm/configs/csb1724_defconfig b/arch/arm/configs/csb1724_defconfig
index 927b269..fbea657 100644
--- a/arch/arm/configs/csb1724_defconfig
+++ b/arch/arm/configs/csb1724_defconfig
@@ -45,3 +45,48 @@ CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_DYNAMIC_DEBUG=y
+CONFIG_NET=y
+CONFIG_INET=y
+CONFIG_NETDEVICES=y
+CONFIG_MV643XX_ETH=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_IPV6=n
+CONFIG_NET_VENDOR_3COM=n
+CONFIG_NET_VENDOR_ADAPTEC=n
+CONFIG_NET_VENDOR_ALTEON=n
+CONFIG_NET_VENDOR_AMD=n
+CONFIG_NET_VENDOR_ATHEROS=n
+CONFIG_NET_VENDOR_BROADCOM=n
+CONFIG_NET_VENDOR_BROCADE=n
+CONFIG_NET_VENDOR_CHELSIO=n
+CONFIG_NET_VENDOR_CIRRUS=n
+CONFIG_NET_VENDOR_CISCO=n
+CONFIG_NET_VENDOR_DEC=n
+CONFIG_NET_VENDOR_HP=n
+CONFIG_NET_VENDOR_DLINK=n
+CONFIG_NET_VENDOR_EMULEX=n
+CONFIG_NET_VENDOR_EXAR=n
+CONFIG_NET_VENDOR_FARADAY=n
+CONFIG_NET_VENDOR_INTEL=n
+CONFIG_NET_VENDOR_MELLANOX=n
+CONFIG_NET_VENDOR_MICREL=n
+CONFIG_NET_VENDOR_MYRI=n
+CONFIG_NET_VENDOR_NATSEMI=n
+CONFIG_NET_VENDOR_NVIDIA=n
+CONFIG_NET_VENDOR_OKI=n
+CONFIG_NET_PACKET_ENGINE=n
+CONFIG_NET_VENDOR_QLOGIC=n
+CONFIG_NET_VENDOR_REALTEK=n
+CONFIG_NET_VENDOR_RDC=n
+CONFIG_NET_VENDOR_SEEQ=n
+CONFIG_NET_VENDOR_SILAN=n
+CONFIG_NET_VENDOR_SIS=n
+CONFIG_NET_VENDOR_SMSC=n
+CONFIG_NET_VENDOR_STMICRO=n
+CONFIG_NET_VENDOR_SUN=n
+CONFIG_NET_VENDOR_TEHUTI=n
+CONFIG_NET_VENDOR_TI=n
+CONFIG_NET_VENDOR_VIA=n
+CONFIG_NET_VENDOR_WIZNET=n
+
diff --git a/arch/arm/mach-kirkwood/board-csb1724.c b/arch/arm/mach-kirkwood/board-csb1724.c
index 979112d..9c58b92 100644
--- a/arch/arm/mach-kirkwood/board-csb1724.c
+++ b/arch/arm/mach-kirkwood/board-csb1724.c
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
+#include "common.h"
#include "mpp.h"
static unsigned int csb1724_mpp_config[] __initdata = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/6] mv643xx.c: Remove magic numbers.
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
replace magic number with RX_CSUM_WITH_HEADER.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 4fbba57..92497eb 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -86,6 +86,7 @@ static char mv643xx_eth_driver_version[] = "1.4";
* port #0, 0x0800 for port #1, and 0x0c00 for port #2.
*/
#define PORT_CONFIG 0x0000
+#define RX_CSUM_WITH_HEADER 0x02000000
#define UNICAST_PROMISCUOUS_MODE 0x00000001
#define PORT_CONFIG_EXT 0x0004
#define MAC_ADDR_LOW 0x0014
@@ -1607,7 +1608,7 @@ mv643xx_eth_set_features(struct net_device *dev, netdev_features_t features)
struct mv643xx_eth_private *mp = netdev_priv(dev);
bool rx_csum = features & NETIF_F_RXCSUM;
- wrlp(mp, PORT_CONFIG, rx_csum ? 0x02000000 : 0x00000000);
+ wrlp(mp, PORT_CONFIG, rx_csum ? RX_CSUM_WITH_HEADER : 0x00000000);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 6/6] DT: Convert all kirkwood boards with mv643xx that use DT
From: Ian Molton @ 2012-07-31 15:45 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: andrew, thomas.petazzoni, ben.dooks, arnd, netdev
In-Reply-To: <1343749529-17571-1-git-send-email-ian.molton@codethink.co.uk>
This patch converts all present DT capable kirkwood board configurations
to use DT to configure the mv643xx ethernet controller.
Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
---
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 9 +++++++++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 8 ++++++++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-iconnect.dts | 10 ++++++++++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/kirkwood-ts219-6281.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219-6282.dts | 8 +++++++-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 3 +++
arch/arm/mach-kirkwood/board-dnskw.c | 7 +------
arch/arm/mach-kirkwood/board-dreamplug.c | 13 ++-----------
arch/arm/mach-kirkwood/board-goflexnet.c | 7 +------
arch/arm/mach-kirkwood/board-ib62x0.c | 7 +------
arch/arm/mach-kirkwood/board-iconnect.c | 7 +------
arch/arm/mach-kirkwood/board-lsxl.c | 13 ++-----------
arch/arm/mach-kirkwood/board-ts219.c | 10 +---------
16 files changed, 98 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 7408655..214fe0b 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -65,5 +65,14 @@
reg = <0x7b00000 0x500000>;
};
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 26e281f..c27ed1c 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -53,6 +53,24 @@
status = "okay";
nr-ports = <1>;
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <1>;
+ status = "ok";
+ };
};
gpio-leds {
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index 7c8238f..f03dbd0 100644
--- a/arch/arm/boot/dts/kirkwood-goflexnet.dts
+++ b/arch/arm/boot/dts/kirkwood-goflexnet.dts
@@ -50,6 +50,14 @@
nr-ports = <2>;
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-ib62x0.dts b/arch/arm/boot/dts/kirkwood-ib62x0.dts
index 66794ed..8c462a1 100644
--- a/arch/arm/boot/dts/kirkwood-ib62x0.dts
+++ b/arch/arm/boot/dts/kirkwood-ib62x0.dts
@@ -45,6 +45,16 @@
};
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-iconnect.dts b/arch/arm/boot/dts/kirkwood-iconnect.dts
index 52d9470..9fc82be 100644
--- a/arch/arm/boot/dts/kirkwood-iconnect.dts
+++ b/arch/arm/boot/dts/kirkwood-iconnect.dts
@@ -30,6 +30,16 @@
clock-frequency = <200000000>;
status = "ok";
};
+
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <b>;
+ status = "ok";
+ };
+
};
gpio-leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 8ac51c0..2f47661 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -40,6 +40,23 @@
};
};
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
+
+ smi1: mdio@76000 {
+ status = "ok";
+ };
+
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+
+ egiga1 {
+ phy_addr = <8>;
+ status = "ok";
+ };
};
gpio_keys {
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6281.dts b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
index ccbf327..4ca49b5 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6281.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6281.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp@f1000000 {
+ egiga0 {
+ phy_addr = <8>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio0 16 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219-6282.dts b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
index fbe9932..40f3c61 100644
--- a/arch/arm/boot/dts/kirkwood-ts219-6282.dts
+++ b/arch/arm/boot/dts/kirkwood-ts219-6282.dts
@@ -3,6 +3,12 @@
/include/ "kirkwood-ts219.dtsi"
/ {
+ ocp@f1000000 {
+ egiga0 {
+ phy_addr = <0>;
+ status = "ok";
+ };
+ };
gpio_keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -18,4 +24,4 @@
gpios = <&gpio1 5 1>;
};
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/kirkwood-ts219.dtsi b/arch/arm/boot/dts/kirkwood-ts219.dtsi
index 64ea27c..06caf41 100644
--- a/arch/arm/boot/dts/kirkwood-ts219.dtsi
+++ b/arch/arm/boot/dts/kirkwood-ts219.dtsi
@@ -74,5 +74,8 @@
status = "okay";
nr-ports = <2>;
};
+ smi0: mdio@72000 {
+ status = "ok";
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c b/arch/arm/mach-kirkwood/board-dnskw.c
index 4ab3506..4d8216b 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/gpio.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dnskw_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int dnskw_mpp_config[] __initdata = {
MPP13_UART1_TXD, /* Custom ... */
MPP14_UART1_RXD, /* ... Controller (DNS-320 only) */
@@ -112,7 +107,7 @@ void __init dnskw_init(void)
kirkwood_mpp_conf(dnskw_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dnskw_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&dnskw_fan_device);
diff --git a/arch/arm/mach-kirkwood/board-dreamplug.c b/arch/arm/mach-kirkwood/board-dreamplug.c
index aeb234d..b97a112 100644
--- a/arch/arm/mach-kirkwood/board-dreamplug.c
+++ b/arch/arm/mach-kirkwood/board-dreamplug.c
@@ -15,7 +15,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -34,14 +33,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data dreamplug_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(1),
-};
-
static struct mvsdio_platform_data dreamplug_mvsdio_data = {
/* unfortunately the CD signal has not been connected */
};
@@ -65,7 +56,7 @@ void __init dreamplug_init(void)
kirkwood_mpp_conf(dreamplug_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&dreamplug_ge00_data);
- kirkwood_ge01_init(&dreamplug_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
kirkwood_sdio_init(&dreamplug_mvsdio_data);
}
diff --git a/arch/arm/mach-kirkwood/board-goflexnet.c b/arch/arm/mach-kirkwood/board-goflexnet.c
index 413e2c8..be7437d 100644
--- a/arch/arm/mach-kirkwood/board-goflexnet.c
+++ b/arch/arm/mach-kirkwood/board-goflexnet.c
@@ -20,7 +20,6 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_fdt.h>
@@ -36,10 +35,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data goflexnet_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
static unsigned int goflexnet_mpp_config[] __initdata = {
MPP29_GPIO, /* USB Power Enable */
MPP47_GPIO, /* LED Orange */
@@ -67,5 +62,5 @@ void __init goflexnet_init(void)
pr_err("can't setup GPIO 29 (USB Power Enable)\n");
kirkwood_ehci_init();
- kirkwood_ge00_init(&goflexnet_ge00_data);
+ kirkwood_ge00_init(NULL);
}
diff --git a/arch/arm/mach-kirkwood/board-ib62x0.c b/arch/arm/mach-kirkwood/board-ib62x0.c
index cfc47f8..0a29183 100644
--- a/arch/arm/mach-kirkwood/board-ib62x0.c
+++ b/arch/arm/mach-kirkwood/board-ib62x0.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
#include <linux/ata_platform.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <asm/mach-types.h>
@@ -27,10 +26,6 @@
#define IB62X0_GPIO_POWER_OFF 24
-static struct mv643xx_eth_platform_data ib62x0_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int ib62x0_mpp_config[] __initdata = {
MPP0_NF_IO2,
MPP1_NF_IO3,
@@ -62,7 +57,7 @@ void __init ib62x0_init(void)
kirkwood_mpp_conf(ib62x0_mpp_config);
kirkwood_ehci_init();
- kirkwood_ge00_init(&ib62x0_ge00_data);
+ kirkwood_ge00_init(NULL);
if (gpio_request(IB62X0_GPIO_POWER_OFF, "ib62x0:power:off") == 0 &&
gpio_direction_output(IB62X0_GPIO_POWER_OFF, 0) == 0)
pm_power_off = ib62x0_power_off;
diff --git a/arch/arm/mach-kirkwood/board-iconnect.c b/arch/arm/mach-kirkwood/board-iconnect.c
index d7a9198..220f0d4 100644
--- a/arch/arm/mach-kirkwood/board-iconnect.c
+++ b/arch/arm/mach-kirkwood/board-iconnect.c
@@ -17,7 +17,6 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/mtd/partitions.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/input.h>
#include <linux/gpio_keys.h>
@@ -26,10 +25,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data iconnect_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(11),
-};
-
static unsigned int iconnect_mpp_config[] __initdata = {
MPP12_GPIO,
MPP35_GPIO,
@@ -92,7 +87,7 @@ void __init iconnect_init(void)
kirkwood_nand_init(ARRAY_AND_SIZE(iconnect_nand_parts), 25);
kirkwood_ehci_init();
- kirkwood_ge00_init(&iconnect_ge00_data);
+ kirkwood_ge00_init(NULL);
platform_device_register(&iconnect_button_device);
}
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 83d8975..60331d1 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -18,7 +18,6 @@
#include <linux/ata_platform.h>
#include <linux/spi/flash.h>
#include <linux/spi/spi.h>
-#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/gpio-fan.h>
#include <linux/input.h>
@@ -28,14 +27,6 @@
#include "common.h"
#include "mpp.h"
-static struct mv643xx_eth_platform_data lsxl_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(0),
-};
-
-static struct mv643xx_eth_platform_data lsxl_ge01_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int lsxl_mpp_config[] __initdata = {
MPP10_GPO, /* HDD Power Enable */
MPP11_GPIO, /* USB Vbus Enable */
@@ -126,8 +117,8 @@ void __init lsxl_init(void)
gpio_set_value(LSXL_GPIO_HDD_POWER, 1);
kirkwood_ehci_init();
- kirkwood_ge00_init(&lsxl_ge00_data);
- kirkwood_ge01_init(&lsxl_ge01_data);
+ kirkwood_ge00_init(NULL);
+ kirkwood_ge01_init(NULL);
platform_device_register(&lsxl_fan_device);
/* register power-off method */
diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index 1750e68..7e7fe6c 100644
--- a/arch/arm/mach-kirkwood/board-ts219.c
+++ b/arch/arm/mach-kirkwood/board-ts219.c
@@ -18,7 +18,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mv643xx_eth.h>
#include <linux/ata_platform.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
@@ -29,10 +28,6 @@
#include "mpp.h"
#include "tsx1x-common.h"
-static struct mv643xx_eth_platform_data qnap_ts219_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR(8),
-};
-
static unsigned int qnap_ts219_mpp_config[] __initdata = {
MPP0_SPI_SCn,
MPP1_SPI_MOSI,
@@ -62,10 +57,7 @@ void __init qnap_dt_ts219_init(void)
kirkwood_mpp_conf(qnap_ts219_mpp_config);
kirkwood_pcie_id(&dev, &rev);
- if (dev == MV88F6282_DEV_ID)
- qnap_ts219_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
-
- kirkwood_ge00_init(&qnap_ts219_ge00_data);
+ kirkwood_ge00_init(NULL);
kirkwood_ehci_init();
pm_power_off = qnap_tsx1x_power_off;
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 16:02 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Jon Mason, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAErSpo6gjMf4C3RMn5YLNg5JtJ8CjHvTw1iqsKPa6YuRqPe90g@mail.gmail.com>
On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
>>
>> I've tried to make it all generic enough that non-Intel NTBs should plug in with
>> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
>> redesign of ntb_hw.c might be necessary. But from what I've seen of other
>> designs on the internet, they appear to be extremely similar. The transport and
>> client drivers were written with the hardware abstracted away as much as
>> possible to prevent the need to modify it for different hardware. If there is
>> anything which is Intel hardware specific, I'd be happy to change it to make it
>> more generic.
>
> That makes sense from a technical point of view, but I think it's
> going to cause maintenance issues. For example, assume PLX NTB
> support is added. Will PLX be happy about having to convince you to
> accept changes? Will Intel be happy about having to release a new
Do you mean convince Intel? Well, if we think of ntb as the class
driver then the onus is on the community to vet the changes and NOT
intel.
And since this is the first NTB part for which the support is
introduced the class driver design could be a moving target. As
someone else mentioned, the async/sync tx-dma is another hook that
could change the class driver's design.
> driver for their hardware just to incorporate a PLX bug fix? Will
> users of PLX hardware accept a new driver release that only benefits
> Intel users?
May be till the class driver is stable, the client(intel/PLX) drivers
might have to be modified. This is a cue for other vendors to
chime-in and review this design?
Just thinking if this could sit in staging for some time(so that
others get a chance to review/suggest changes as well) and then get
promoted out of staging.
Chetan Loke
^ permalink raw reply
* 802.15.4 Issues
From: Alan Ott @ 2012-07-31 16:04 UTC (permalink / raw)
To: netdev, linux-zigbee-devel, Alexander Smirnov, Tony Cheneau
Hello,
I'm trying to follow the directions at linux-wsn[1] and am not having
much luck. Since I don't have the at91sam9g20ek board, I'm trying this
on my desktop PC with an Econotag[2] (using the serial.c driver I pulled
from [3]) and on a BeagleBone with an MRF24J40 (using a driver I made [4]).
I know this sounds like a big mess, and it is, but let me first start by
staying that all this worked with the code in the linux-zigbee repo at
[3]. With the code in that repo I could run the steps at [5] and
communicate between devices using izchat. (Yes, I know that izchat and
the workflow at [5] are not supported in the -next code yet, which is
why I'm using [1])
Currently, I'm trying to follow the steps at [1] to start using the
latest mainline functionality and I'm not having very much success. I'm
using linux-next, which in looking at the log should currently be the
same as net-next with respect to ieee802154 and 6lowpan.
On the destkop PC, there are several issues. The first is that I'm
getting __schedule_bug errors caused by lowpan_header_create() calling
kzalloc(..., GFP_KERNEL) from interrupt context (see [schedule_log]
below). Replacing kzalloc() calls in lowpan_header_create() and in
ieee802154_header_create() with stack arrays (since they were small
static lengths anyway), I'm able to run the commands at [1] without
stack dumps in the log. This is good, I suppose. The issue now is, once
I've set up the lowpan0 device on the Econotag, when I issue a ping, I
don't see its .xmit() function getting called at all
(ieee802154_serial_xmit() in this case).
I can certainly investigate further, but before doing so, I'd like to
know if what I'm doing, the way I'm doing it, is even _expected_ to
work, or if there's something fundamental that I'm missing.
Also, the instructions at [1] say:
"no platform data merged to the mainline, please apply the last patch
from wpan series manually"
Those instructions[1] were updated July 4, which is before the most
recent 802.15.4 related commits made it into -next. Is that sentence
still valid? If so, where is this wpan series of which it speaks? I'm
assuming platform data may mean for the at91sam9g20ek and that it
doesn't affect me since I'm not using that hardware. Please correct me
if I'm wrong.
Also, interestingly, on my embedded configuration (Beagle Bone +
MRF24J40), ping6 _will_ cause packets to get sent. The kernel I have on
that system is mainline (linux.git) still, and I haven't moved it to
-next yet because of the issues on the desktop PC.
Like I said, I feel like there's something fundamental I'm doing wrong.
Please let me know if you see it.
Alan.
[1] http://code.google.com/p/linux-wsn/wiki/Mainline
[2] http://www.redwirellc.com/store/node/1
[3]
http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary
[4] http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1135
[5] http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2
[schedule_log]
[ 87.605763] Call Trace:
[ 87.605764] <IRQ> [<ffffffff81084992>] __schedule_bug+0x52/0x60
[ 87.605772] [<ffffffff815e303d>] __schedule+0x6cd/0x7c0
[ 87.605774] [<ffffffff8108875a>] __cond_resched+0x2a/0x40
[ 87.605776] [<ffffffff815e31c0>] _cond_resched+0x30/0x40
[ 87.605779] [<ffffffff81159740>] __kmalloc+0x60/0x170
[ 87.605781] [<ffffffffa02fe28f>] ? kzalloc+0xf/0x20 [6lowpan]
[ 87.605783] [<ffffffffa02fe28f>] kzalloc+0xf/0x20 [6lowpan]
[ 87.605785] [<ffffffffa02fe50e>] lowpan_header_create+0x7e/0x570
[6lowpan]
[ 87.605788] [<ffffffff814de84b>] ? __kmalloc_reserve+0x3b/0xa0
[ 87.605790] [<ffffffff811597d5>] ? __kmalloc+0xf5/0x170
[ 87.605792] [<ffffffff814f711d>] neigh_connected_output+0xad/0x110
[ 87.605795] [<ffffffff8158438d>] ip6_finish_output2+0xfd/0x310
[ 87.605797] [<ffffffff8159041b>] ? rt6_bind_peer+0x4b/0x90
[ 87.605799] [<ffffffff81584638>] ip6_finish_output+0x98/0xc0
[ 87.605801] [<ffffffff815846d8>] ip6_output+0x78/0xb0
[ 87.605803] [<ffffffff8159843e>] ndisc_send_skb+0x1be/0x1f0
[ 87.605805] [<ffffffff815984d1>] __ndisc_send+0x61/0x80
[ 87.605807] [<ffffffff81598d89>] ndisc_send_rs+0x39/0x40
[ 87.605809] [<ffffffff81589df3>] ? ipv6_ifa_notify+0x43/0x50
[ 87.605810] [<ffffffff81589ea0>] addrconf_dad_completed+0xa0/0xf0
[ 87.605812] [<ffffffff8158a08f>] addrconf_dad_timer+0x19f/0x1c0
[ 87.605814] [<ffffffff81064338>] run_timer_softirq+0x178/0x3a0
[ 87.605816] [<ffffffff81589ef0>] ? addrconf_dad_completed+0xf0/0xf0
[ 87.605818] [<ffffffff8101a639>] ? read_tsc+0x9/0x20
[ 87.605819] [<ffffffff8105bfff>] __do_softirq+0xcf/0x250
[ 87.605822] [<ffffffff810a6b34>] ? clockevents_program_event+0x74/0xf0
[ 87.605824] [<ffffffff8107be9e>] ? hrtimer_interrupt+0x13e/0x240
[ 87.605826] [<ffffffff815ed5bc>] call_softirq+0x1c/0x30
[ 87.605829] [<ffffffff810152d5>] do_softirq+0x65/0xa0
[ 87.605830] [<ffffffff8105bded>] irq_exit+0xbd/0xe0
[ 87.605832] [<ffffffff815edefe>] smp_apic_timer_interrupt+0x6e/0x99
[ 87.605833] [<ffffffff815ececa>] apic_timer_interrupt+0x6a/0x70
[ 87.605834] <EOI> [<ffffffff81041436>] ? native_safe_halt+0x6/0x10
[ 87.605838] [<ffffffff8101c54d>] default_idle+0x5d/0x1b0
[ 87.605840] [<ffffffff8101bb98>] cpu_idle+0xd8/0x120
[ 87.605842] [<ffffffff815dcc1e>] start_secondary+0x1cf/0x1d6
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: chetan loke @ 2012-07-31 16:14 UTC (permalink / raw)
To: Jon Mason; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <1343607994-32415-2-git-send-email-jon.mason@intel.com>
On Sun, Jul 29, 2012 at 8:26 PM, Jon Mason <jon.mason@intel.com> wrote:
<snip>
> +static void ntb_tx_copy_task(struct ntb_transport_qp *qp,
> + struct ntb_queue_entry *entry,
> + void *offset)
> +{
> + struct ntb_payload_header *hdr = offset;
> +
> + offset += sizeof(struct ntb_payload_header);
> + memcpy_toio(offset, entry->buf, entry->len);
> +
> + hdr->len = entry->len;
> + hdr->ver = qp->tx_pkts;
> +
> + /* Ensure that the data is fully copied out before setting the flag */
> + wmb();
> + hdr->flags = entry->flags | DESC_DONE_FLAG;
> +
> + ntb_ring_sdb(qp->ndev, qp->qp_num);
> +
> + /* The entry length can only be zero if the packet is intended to be a
> + * "link down" or similar. Since no payload is being sent in these
> + * cases, there is nothing to add to the completion queue.
> + */
> + if (entry->len > 0) {
> + qp->tx_bytes += entry->len;
> +
> + /* Add fully transmitted data to completion queue */
> + ntb_list_add_tail(&qp->ntb_tx_comp_q_lock, &entry->entry,
> + &qp->tx_comp_q);
> +
> + if (qp->tx_handler)
> + qp->tx_handler(qp->cb_data, qp);
> + } else
> + ntb_list_add_tail(&qp->ntb_tx_free_q_lock, &entry->entry,
> + &qp->tx_free_q);
> +}
I know you talked about a fixed array. But it's not here yet. So at
all the call-sites, for [r/t]x_free_q , add the 'entry' to the head -
change to ntb_list_add_head here and else where.
Chetan Loke
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-07-31 16:33 UTC (permalink / raw)
To: Jianbin Kang; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAF8raN6M0_TWyCCzjyXZcFYP=vgFaqQg4hNmNpBxSM+D0C_Bpg@mail.gmail.com>
On Tue, Jul 31, 2012 at 11:35:33AM +0800, Jianbin Kang wrote:
> > I've tried to make it all generic enough that non-Intel NTBs should plug in with
> > minimal changes to ntb_hw.c. If their design is too divergent, then a slight
> > redesign of ntb_hw.c might be necessary. But from what I've seen of other
> > designs on the internet, they appear to be extremely similar. The transport and
> > client drivers were written with the hardware abstracted away as much as
> > possible to prevent the need to modify it for different hardware. If there is
> > anything which is Intel hardware specific, I'd be happy to change it to make it
> > more generic.
> In ntb_process_tx(), ntb uses hard-coding 'memcpy_toio' to copy data
> to remote.
> Is it better to provide a function pointer like 'tx()' and call qp->tx().
> memcpy_toio is a slow operation. Some hardware can setup a dma
> transfer and wait.
>
> IMHO, the best way is to handle tx in async mode. But it requires
> lots of modification.
Actually this is what I'm working on now, using async_tx to replace the
memcpy. I believe the changes shouldn't be that significant.
Is the "hardware that can setup dma" you refer to something that does
not use this interface?
Thanks,
Jon
^ permalink raw reply
* Re: [PATCH v2 1/6] Initial csb1724 board support (FDT)
From: Andrew Lunn @ 2012-07-31 16:43 UTC (permalink / raw)
To: Ian Molton
Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <1343749529-17571-2-git-send-email-ian.molton@codethink.co.uk>
On Tue, Jul 31, 2012 at 04:45:24PM +0100, Ian Molton wrote:
> This patch adds support for the csb1724 SoM.
>
> It includes serial and SATA support.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> arch/arm/boot/dts/kirkwood-csb1724.dts | 30 ++++++++++++++++
> arch/arm/configs/csb1724_defconfig | 47 +++++++++++++++++++++++++
I'm unlikely to accept csb1724_defconfig. Please keep it for yourself.
If there is anything you want adding to kirkwood_defconfig, please let
me know.
Jason planned to rework kirkwood_defconfig, but he got sidetracked. I
hope we can get to this soon and enable the building of all DT
platforms by default.
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Andrew Lunn @ 2012-07-31 16:46 UTC (permalink / raw)
To: Ian Molton
Cc: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <1343749529-17571-4-git-send-email-ian.molton@codethink.co.uk>
On Tue, Jul 31, 2012 at 04:45:26PM +0100, Ian Molton wrote:
> This patch adds basic device tree support to the mv643xx ethernet driver.
>
> It should be enough for most current users of the device, and should allow
> a fairly painless migration once proper support for clk devices is available
> to those platforms.
>
> Signed-off-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> Documentation/devicetree/bindings/net/mv643xx.txt | 75 +++++++++++++
> arch/arm/mach-kirkwood/board-dt.c | 5 +
Hi Ian
Probably the driver change will get upstream by netdev. The rest will
go via the Orion maintainers into arm-soc. So you should probably move
this board-dt.c change into a patch of its own, or make it part of:
csb1724: Enable device tree based mv643xx ethernet support.
Thanks
Andrew
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Bjorn Helgaas @ 2012-07-31 17:03 UTC (permalink / raw)
To: chetan loke; +Cc: Jon Mason, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAAsGZS5kOyQ5FQ7Jg3HxOmmPNYS+F6XcB-_3tm=rcgDV7wAvRQ@mail.gmail.com>
On Tue, Jul 31, 2012 at 10:02 AM, chetan loke <loke.chetan@gmail.com> wrote:
> On Tue, Jul 31, 2012 at 9:45 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> On Mon, Jul 30, 2012 at 12:15 PM, Jon Mason <jon.mason@intel.com> wrote:
>>>
>>> I've tried to make it all generic enough that non-Intel NTBs should plug in with
>>> minimal changes to ntb_hw.c. If their design is too divergent, then a slight
>>> redesign of ntb_hw.c might be necessary. But from what I've seen of other
>>> designs on the internet, they appear to be extremely similar. The transport and
>>> client drivers were written with the hardware abstracted away as much as
>>> possible to prevent the need to modify it for different hardware. If there is
>>> anything which is Intel hardware specific, I'd be happy to change it to make it
>>> more generic.
>>
>> That makes sense from a technical point of view, but I think it's
>> going to cause maintenance issues. For example, assume PLX NTB
>> support is added. Will PLX be happy about having to convince you to
>> accept changes? Will Intel be happy about having to release a new
>
> Do you mean convince Intel? Well, if we think of ntb as the class
> driver then the onus is on the community to vet the changes and NOT
> intel.
No, I said convince "you," meaning *Jon*. Intel doesn't apply
patches. "The community" doesn't apply patches. Jon applies patches.
This has nothing to do with the fact that Jon is employed by Intel.
The point is that when you have multiple organizations involved, they
have different goals, markets, customers, and schedules. If one
module contains both Intel-specific and PLX-specific things, that's a
place where these organizational differences may cause issues,
regardless of who is applying the patches.
Obviously it's not a problem now, and maybe it will never be. But I
think there's a possibility. Since I have no direct interest in any
of these devices, I'm only raising that possibility, not trying to
force any particular direction.
^ 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