18 Oct, 2010

1 commit

  • Since commit e446630c960946b5c1762e4eadb618becef599e7, i.e. v2.6.35-rc1,
    the mcp251x chip model can be selected via the modalias member in the
    struct spi_board_info. The driver stores the actual model in the
    struct mcp251x_platform_data.

    From the driver point of view the platform_data should be read only.
    Since all in-tree users of the mcp251x have already been converted to
    the modalias method, this patch moves the "model" member from the
    struct mcp251x_platform_data to the driver's private data structure.

    Signed-off-by: Marc Kleine-Budde
    Cc: Christian Pellegrin
    Cc: Marc Zyngier

    Marc Kleine-Budde
     

23 Jul, 2010

1 commit

  • This core is found on some Freescale SoCs and also some Coldfire
    SoCs. Support for Coldfire is missing though at the moment as
    they have an older revision of the core which does not have RX FIFO
    support.

    Signed-off-by: Sascha Hauer
    Signed-off-by: Marc Kleine-Budde
    Acked-by: Wolfgang Grandegger
    Signed-off-by: Marc Kleine-Budde

    Marc Kleine-Budde
     

18 May, 2010

1 commit

  • The member "clock" of struct "sja1000_platform_data" is documented as
    "CAN bus oscillator frequency in Hz" but it's actually used as the CAN
    clock frequency, which is half of it. To avoid further confusion, this
    patch fixes it by renaming the member to "osc_freq". That way, also
    non mainline users will notice the change. The platform code for the
    relevant boards is updated accordingly. Furthermore, pre-defined
    values are now used for the members "ocr" and "cdr".

    Signed-off-by: Wolfgang Grandegger
    Acked-by: Marc Kleine-Budde
    Signed-off-by: David S. Miller

    Wolfgang Grandegger
     

13 Apr, 2010

1 commit


31 Mar, 2010

1 commit

  • Chip model can now be selected directly by matching the modalias name
    (instead of filling the .model field in platform_data), and allows the
    module to be auto-loaded. Previous behaviour is of course still supported.

    Convert the two in-tree users to this feature (icontrol & zeus).
    Tested on an Zeus platform (mcp2515).

    Signed-off-by: Marc Zyngier
    Acked-by: Christian Pellegrin
    Cc: Edwin Peer
    Acked-by: Wolfgang Grandegger
    Signed-off-by: David S. Miller

    Marc Zyngier
     

26 Feb, 2010

2 commits


15 Jan, 2010

1 commit


12 Jan, 2010

1 commit

  • To prevent the CAN drivers to operate on invalid socketbuffers the skbs are
    now checked and silently dropped at the xmit-function consistently.

    Also the netdev stats are consistently using the CAN data length code (dlc)
    for [rx|tx]_bytes now.

    Signed-off-by: Oliver Hartkopp
    Acked-by: Wolfgang Grandegger
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     

04 Jan, 2010

1 commit

  • This patch adds the flag CAN_CTRLMODE_ONE_SHOT. It is used as mask
    or flag in the "struct can_ctrlmode".

    It allows userspace via netlink to set a CAN controller into the special
    "one-shot" mode. In this mode, if supported by the CAN controller, it
    tries only once to deliver a CAN frame and aborts it if an error
    (e.g.: arbitration lost) happens.

    Signed-off-by: Marc Kleine-Budde
    Acked-by: Wolfgang Grandegger
    Signed-off-by: David S. Miller

    Marc Kleine-Budde
     

14 Dec, 2009

1 commit

  • A valid CAN dataframe can have a data length code (DLC) of 0 .. 8 data bytes.

    When reading the CAN controllers register the 4-bit value may contain values
    from 0 .. 15 which may exceed the reserved space in the socket buffer!

    The ISO 11898-1 Chapter 8.4.2.3 (DLC field) says that register values > 8
    should be reduced to 8 without any error reporting or frame drop.

    This patch introduces a new helper macro to cast a given 4-bit data length
    code (dlc) to __u8 and ensure the DLC value to be max. 8 bytes.

    The different handlings in the rx path of the CAN netdevice drivers are fixed.

    Signed-off-by: Oliver Hartkopp
    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     

08 Nov, 2009

1 commit


06 Nov, 2009

1 commit

  • struct can_proto had a capability field which wasn't ever used. It is
    dropped entirely.

    struct inet_protosw had a capability field which can be more clearly
    expressed in the code by just checking if sock->type = SOCK_RAW.

    Signed-off-by: Eric Paris
    Acked-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Eric Paris
     

20 Oct, 2009

1 commit

  • This patch makes the private functions alloc_can_skb() and
    alloc_can_err_skb() of the at91_can driver public and adapts all
    drivers to use these. While making the patch I realized, that
    the skb's are *not* setup consistently. It's now done as shown
    below:

    skb->protocol = htons(ETH_P_CAN);
    skb->pkt_type = PACKET_BROADCAST;
    skb->ip_summed = CHECKSUM_UNNECESSARY;
    *cf = (struct can_frame *)skb_put(skb, sizeof(struct can_frame));
    memset(*cf, 0, sizeof(struct can_frame));

    The frame is zeroed out to avoid uninitialized data to be passed to
    user space. Some drivers or library code did not set "pkt_type" or
    "ip_summed". Also, "__constant_htons()" should not be used for
    runtime invocations, as pointed out by David Miller.

    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: David S. Miller

    Wolfgang Grandegger
     

13 Oct, 2009

1 commit

  • This patch allows the CAN controller driver to define the number of echo
    skb's used for the local loopback (echo), as suggested by Kurt Van
    Dijck, with the function:

    struct net_device *alloc_candev(int sizeof_priv,
    unsigned int echo_skb_max);

    The CAN drivers have been adapted accordingly. For the ems_usb driver,
    as suggested by Sebastian Haas, the number of echo skb's has been
    increased to 10, which improves the transmission performance a lot.

    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: Kurt Van Dijck
    Signed-off-by: David S. Miller

    Wolfgang Grandegger
     

08 Oct, 2009

1 commit

  • TI HECC (High End CAN Controller) module is found on many TI devices. It
    has 32 hardware mailboxes with full implementation of CAN protocol 2.0B
    with bus speeds up to 1Mbps. Specifications of the module are available
    on TI web

    Signed-off-by: Anant Gole
    Signed-off-by: David S. Miller

    Anant Gole
     

04 Sep, 2009

1 commit


01 Jun, 2009

1 commit

  • This patch adds a generic driver for SJA1000 chips on the OpenFirmware
    platform bus found on embedded PowerPC systems. You need a SJA1000 node
    definition in your flattened device tree source (DTS) file similar to:

    can@3,100 {
    compatible = "nxp,sja1000";
    reg = ;
    interrupts = ;
    interrupt-parent = ;
    nxp,external-clock-frequency = ;
    };

    See also Documentation/powerpc/dts-bindings/can/sja1000.txt.

    CC: devicetree-discuss@ozlabs.org
    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: David S. Miller

    Wolfgang Grandegger
     

19 May, 2009

2 commits

  • This driver adds support for the SJA1000 chips connected to the
    "platform bus", which can be found on various embedded systems.

    Signed-off-by: Sascha Hauer
    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: Marc Kleine-Budde
    Signed-off-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Wolfgang Grandegger
     
  • The CAN network device driver interface provides a generic interface to
    setup, configure and monitor CAN network devices. It exports a set of
    common data structures and functions, which all real CAN network device
    drivers should use. Please have a look to the SJA1000 or MSCAN driver
    to understand how to use them. The name of the module is can-dev.ko.

    Furthermore, it adds a Netlink interface allowing to configure the CAN
    device using the program "ip" from the iproute2 utility suite.

    For further information please check "Documentation/networking/can.txt"

    Signed-off-by: Wolfgang Grandegger
    Signed-off-by: Oliver Hartkopp
    Signed-off-by: David S. Miller

    Wolfgang Grandegger
     

30 Jan, 2009

1 commit


07 Jan, 2009

1 commit

  • The AF_CAN core delivered always cloned sk_buffs to the AF_CAN
    protocols, although this was _only_ needed by the can-raw protocol.
    With this (additionally documented) change, the AF_CAN core calls the
    callback functions of the registered AF_CAN protocols with the original
    (uncloned) sk_buff pointer and let's the can-raw protocol do the
    skb_clone() itself which omits all unneeded skb_clone() calls for other
    AF_CAN protocols.

    Signed-off-by: Oliver Hartkopp
    Signed-off-by: Urs Thuermann
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     

04 Dec, 2008

1 commit

  • Due to a wrong safety check in af_can.c it was not possible to filter
    for SFF frames with a specific CAN identifier without getting the
    same selected CAN identifier from a received EFF frame also.

    This fix has a minimum (but user visible) impact on the CAN filter
    API and therefore the CAN version is set to a new date.

    Indeed the 'old' API is still working as-is. But when now setting
    CAN_(EFF|RTR)_FLAG in can_filter.can_mask you might get less traffic
    than before - but still the stuff that you expected to get for your
    defined filter ...

    Thanks to Kurt Van Dijck for pointing at this issue and for the review.

    Signed-off-by: Oliver Hartkopp
    Acked-by: Kurt Van Dijck
    Signed-off-by: David S. Miller

    Oliver Hartkopp
     

29 Jan, 2008

5 commits