1. 05 3月, 2015 32 次提交
  2. 04 3月, 2015 8 次提交
    • A
      bfin_can: Merge header file from arch dependent location · 400aff5d
      Aaron Wu 提交于
      Header file was in arch dependent location arch/blackfin/include/asm/bfin_can.h,
      Now move and merge the useful contents of header file into driver code, note
      the original header file is reserved for full registers set access test by other
      code so it survives.
      Signed-off-by: NAaron Wu <Aaron.wu@analog.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      400aff5d
    • A
      bfin_can: introduce ioremap to comply to archs with MMU · dead8389
      Aaron Wu 提交于
      Blackfin was built without MMU, old driver code access the IO space by
      physical address, introduce the ioremap approach to be compitable with
      the common style supporting MMU enabled arch.
      Signed-off-by: NAaron Wu <Aaron.wu@analog.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      dead8389
    • A
      bfin_can: rewrite the blackfin style of read/write to common ones · e4936e01
      Aaron Wu 提交于
      Replace the blackfin arch dependent style of bfin_read/bfin_write with
      common readw/writew
      Signed-off-by: NAaron Wu <Aaron.wu@analog.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      e4936e01
    • D
      Merge branch 'basic-mpls-support' · 27db730c
      David S. Miller 提交于
      Eric W. Biederman says:
      
      ====================
      Basic MPLS support take 2
      
      On top of my two pending neighbour table prep patches here is the mpls
      support refactored to use them, and edited to not drop routes when
      an interface goes down.  Additionally the addition of RTA_LLGATEWAY
      has been replaced with the addtion of RTA_VIA.  RTA_VIA being an
      attribute that includes the address family as well as the address
      of the next hop.
      
      MPLS is at it's heart simple and I have endeavoured to maintain that
      simplicity in my implemenation.
      
      This is an implementation of a RFC3032 forwarding engine, and basic MPLS
      egress logic.  Which should make linux sufficient to be a mpls
      forwarding node or to be a LSA (Label Switched Router) as it says in all
      of the MPLS documents.  The ingress support will follow but it deserves
      it's own discussion so I am pushing it separately.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27db730c
    • E
      mpls: Multicast route table change notifications · 8de147dc
      Eric W. Biederman 提交于
      Unlike IPv4 this code notifies on all cases where mpls routes
      are added or removed and it never automatically removes routes.
      Avoiding both the userspace confusion that is caused by omitting
      route updates and the possibility of a flood of netlink traffic
      when an interface goes doew.
      
      For now reserved labels are handled automatically and userspace
      is not notified.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8de147dc
    • E
      mpls: Netlink commands to add, remove, and dump routes · 03c05665
      Eric W. Biederman 提交于
      This change adds two new netlink routing attributes:
      RTA_VIA and RTA_NEWDST.
      
      RTA_VIA specifies the specifies the next machine to send a packet to
      like RTA_GATEWAY.  RTA_VIA differs from RTA_GATEWAY in that it
      includes the address family of the address of the next machine to send
      a packet to.  Currently the MPLS code supports addresses in AF_INET,
      AF_INET6 and AF_PACKET.  For AF_INET and AF_INET6 the destination mac
      address is acquired from the neighbour table.  For AF_PACKET the
      destination mac_address is specified in the netlink configuration.
      
      I think raw destination mac address support with the family AF_PACKET
      will prove useful.  There is MPLS-TP which is defined to operate
      on machines that do not support internet packets of any flavor.  Further
      seem to be corner cases where it can be useful.  At this point
      I don't care much either way.
      
      RTA_NEWDST specifies the destination address to forward the packet
      with.  MPLS typically changes it's destination address at every hop.
      For a swap operation RTA_NEWDST is specified with a length of one label.
      For a push operation RTA_NEWDST is specified with two or more labels.
      For a pop operation RTA_NEWDST is not specified or equivalently an emtpy
      RTAN_NEWDST is specified.
      
      Those new netlink attributes are used to implement handling of rt-netlink
      RTM_NEWROUTE, RTM_DELROUTE, and RTM_GETROUTE messages, to maintain the
      MPLS label table.
      
      rtm_to_route_config parses a netlink RTM_NEWROUTE or RTM_DELROUTE message,
      verify no unhandled attributes or unhandled values are present and sets
      up the data structures for mpls_route_add and mpls_route_del.
      
      I did my best to match up with the existing conventions with the caveats
      that MPLS addresses are all destination-specific-addresses, and so
      don't properly have a scope.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03c05665
    • E
      mpls: Functions for reading and wrinting mpls labels over netlink · 966bae33
      Eric W. Biederman 提交于
      Reading and writing addresses in network byte order in netlink is
      traditional and I see no reason to change that.  MPLS is interesting
      as effectively it has variabely length addresses (the MPLS label
      stack).  To represent these variable length addresses in netlink
      I use a valid MPLS label stack (complete with stop bit).
      
      This achieves two things: a well defined existing format is used,
      and the data can be interpreted without looking at it's length.
      
      Not needed to look at the length to decode the variable length
      network representation allows existing userspace functions
      such as inet_ntop to be used without needed to change their
      prototype.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      966bae33
    • E
      mpls: Basic support for adding and removing routes · a2519929
      Eric W. Biederman 提交于
      mpls_route_add and mpls_route_del implement the basic logic for adding
      and removing Next Hop Label Forwarding Entries from the MPLS input
      label map.  The addition and subtraction is done in a way that is
      consistent with how the existing routing table in Linux are
      maintained.  Thus all of the work to deal with NLM_F_APPEND,
      NLM_F_EXCL, NLM_F_REPLACE, and NLM_F_CREATE.
      
      Cases that are not clearly defined such as changing the interpretation
      of the mpls reserved labels is not allowed.
      
      Because it seems like the right thing to do adding an MPLS route without
      specifying an input label and allowing the kernel to pick a free label
      table entry is supported.   The implementation is currently less than optimal
      but that can be changed.
      
      As I don't have anything else to test with only ethernet and the loopback
      device are the only two device types currently supported for forwarding
      MPLS over.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2519929