1. 09 12月, 2014 5 次提交
  2. 03 12月, 2014 2 次提交
  3. 30 11月, 2014 4 次提交
    • M
      sh_eth: Fix sleeping function called from invalid context · 7fa2955f
      Mitsuhiro Kimura 提交于
      This resolves the following bug which can be reproduced by building the
      kernel with CONFIG_DEBUG_ATOMIC_SLEEP=y and reading network statistics
      while the network interface is down.
      
      e.g.:
      
      ifconfig eth0 down
      cat /sys/class/net/eth0/statistics/tx_errors
      
      ----
      [ 1238.161349] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:952
      [ 1238.188279] in_atomic(): 1, irqs_disabled(): 0, pid: 1388, name: cat
      [ 1238.207425] CPU: 0 PID: 1388 Comm: cat Not tainted 3.10.31-ltsi-00046-gefa0b46 #1087
      [ 1238.230737] Backtrace:
      [ 1238.238123] [<c0012e64>] (dump_backtrace+0x0/0x10c) from [<c0013000>] (show_stack+0x18/0x1c)
      [ 1238.263499]  r6:000003b8 r5:c06160c0 r4:c0669e00 r3:00404000
      [ 1238.280583] [<c0012fe8>] (show_stack+0x0/0x1c) from [<c04515a4>] (dump_stack+0x20/0x28)
      [ 1238.304631] [<c0451584>] (dump_stack+0x0/0x28) from [<c004970c>] (__might_sleep+0xf8/0x118)
      [ 1238.329734] [<c0049614>] (__might_sleep+0x0/0x118) from [<c02465ac>] (__pm_runtime_resume+0x38/0x90)
      [ 1238.357170]  r7:d616f000 r6:c049c458 r5:00000004 r4:d6a17210
      [ 1238.374251] [<c0246574>] (__pm_runtime_resume+0x0/0x90) from [<c029b1c4>] (sh_eth_get_stats+0x44/0x280)
      [ 1238.402468]  r7:d616f000 r6:c049c458 r5:d5c21000 r4:d5c21000
      [ 1238.419552] [<c029b180>] (sh_eth_get_stats+0x0/0x280) from [<c03ae39c>] (dev_get_stats+0x54/0x88)
      [ 1238.446204]  r5:d5c21000 r4:d5ed7e08
      [ 1238.456980] [<c03ae348>] (dev_get_stats+0x0/0x88) from [<c03c677c>] (netstat_show.isra.15+0x54/0x9c)
      [ 1238.484413]  r6:d5c21000 r5:d5c21238 r4:00000028 r3:00000001
      [ 1238.501495] [<c03c6728>] (netstat_show.isra.15+0x0/0x9c) from [<c03c69b8>] (show_tx_errors+0x18/0x1c)
      [ 1238.529196]  r7:d5f945d8 r6:d5f945c0 r5:c049716c r4:c0650e7c
      [ 1238.546279] [<c03c69a0>] (show_tx_errors+0x0/0x1c) from [<c023963c>] (dev_attr_show+0x24/0x50)
      [ 1238.572157] [<c0239618>] (dev_attr_show+0x0/0x50) from [<c010c148>] (sysfs_read_file+0xb0/0x140)
      [ 1238.598554]  r5:c049716c r4:d5c21240
      [ 1238.609326] [<c010c098>] (sysfs_read_file+0x0/0x140) from [<c00b9ee4>] (vfs_read+0xb0/0x13c)
      [ 1238.634679] [<c00b9e34>] (vfs_read+0x0/0x13c) from [<c00ba0ac>] (SyS_read+0x44/0x74)
      [ 1238.657944]  r8:bef45bf0 r7:00000000 r6:d6ac0600 r5:00000000 r4:00000000
      [ 1238.678172] [<c00ba068>] (SyS_read+0x0/0x74) from [<c000eec0>] (ret_fast_syscall+0x0/0x30)
      ----
      Signed-off-by: NMitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
      Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fa2955f
    • H
      stmmac: platform: Move plat_dat checking earlier · 28603d13
      Huacai Chen 提交于
      Original code only check/alloc plat_dat for the CONFIG_OF case, this
      patch check/alloc it earlier and unconditionally to avoid kernel build
      warnings:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:275
      stmmac_pltfr_probe() warn: variable dereferenced before check 'plat_dat'
      
      V2: Fix coding style.
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28603d13
    • M
      sh_eth: Fix skb alloc size and alignment adjust rule. · 4d6a949c
      Mitsuhiro Kimura 提交于
      In the current driver, allocation size of skb does not care the alignment
      adjust after allocation.
      And also, in the current implementation, buffer alignment method by
      sh_eth_set_receive_align function has a bug that this function displace
      buffer start address forcedly when the alignment is corrected.
      In the result, tail of the skb will exceed allocated area and kernel panic
      will be occurred.
      This patch fix this issue.
      Signed-off-by: NMitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
      Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d6a949c
    • T
      bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes · f6c6fda4
      Thomas Graf 提交于
      Fixes: 7f28fa10 ("bonding: add arp_ip_target netlink support")
      Reported-by: NJohn Fastabend <john.fastabend@gmail.com>
      Cc: Scott Feldman <sfeldma@cumulusnetworks.com>
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6c6fda4
  4. 27 11月, 2014 6 次提交
  5. 26 11月, 2014 4 次提交
  6. 25 11月, 2014 1 次提交
  7. 24 11月, 2014 4 次提交
    • L
      iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands · 5ac6c72e
      Luciano Coelho 提交于
      Older firmwares do not provide support for the HOT_SPOT_CMD command.
      Check for the appropriate TLV flag that declares hotspot support in
      the firmware to prevent a firmware assertion failure that can be
      triggered from the userspace,
      
      Cc: stable@vger.kernel.org [3.17+]
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      5ac6c72e
    • C
      igb: Fixes needed for surprise removal support · 17a402a0
      Carolyn Wyborny 提交于
      This patch adds some checks in order to prevent panic's on surprise
      removal of devices during S0, S3, S4.  Without this patch, Thunderbolt
      type device removal will panic the system.
      Signed-off-by: NYanir Lubetkin <yanirx.lubetkin@intel.com>
      Signed-off-by: NCarolyn Wyborny <carolyn.wyborny@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17a402a0
    • D
      ixgbe: fix use after free adapter->state test in ixgbe_remove/ixgbe_probe · b5b2ffc0
      Daniel Borkmann 提交于
      While working on a different issue, I noticed an annoying use
      after free bug on my machine when unloading the ixgbe driver:
      
      [ 8642.318797] ixgbe 0000:02:00.1: removed PHC on p2p2
      [ 8642.742716] ixgbe 0000:02:00.1: complete
      [ 8642.743784] BUG: unable to handle kernel paging request at ffff8807d3740a90
      [ 8642.744828] IP: [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
      [ 8642.745886] PGD 20c6067 PUD 81c1f6067 PMD 81c15a067 PTE 80000007d3740060
      [ 8642.746956] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      [ 8642.748039] Modules linked in: [...]
      [ 8642.752929] CPU: 1 PID: 1225 Comm: rmmod Not tainted 3.18.0-rc2+ #49
      [ 8642.754203] Hardware name: Supermicro X10SLM-F/X10SLM-F, BIOS 1.1b 11/01/2013
      [ 8642.755505] task: ffff8807e34d3fe0 ti: ffff8807b7204000 task.ti: ffff8807b7204000
      [ 8642.756831] RIP: 0010:[<ffffffffa01c77dc>]  [<ffffffffa01c77dc>] ixgbe_remove+0xfc/0x1b0 [ixgbe]
      [...]
      [ 8642.774335] Stack:
      [ 8642.775805]  ffff8807ee824098 ffff8807ee824098 ffffffffa01f3000 ffff8807ee824000
      [ 8642.777326]  ffff8807b7207e18 ffffffff8137720f ffff8807ee824098 ffff8807ee824098
      [ 8642.778848]  ffffffffa01f3068 ffff8807ee8240f8 ffff8807b7207e38 ffffffff8144180f
      [ 8642.780365] Call Trace:
      [ 8642.781869]  [<ffffffff8137720f>] pci_device_remove+0x3f/0xc0
      [ 8642.783395]  [<ffffffff8144180f>] __device_release_driver+0x7f/0xf0
      [ 8642.784876]  [<ffffffff814421f8>] driver_detach+0xb8/0xc0
      [ 8642.786352]  [<ffffffff814414a9>] bus_remove_driver+0x59/0xe0
      [ 8642.787783]  [<ffffffff814429d0>] driver_unregister+0x30/0x70
      [ 8642.789202]  [<ffffffff81375c65>] pci_unregister_driver+0x25/0xa0
      [ 8642.790657]  [<ffffffffa01eb38e>] ixgbe_exit_module+0x1c/0xc8e [ixgbe]
      [ 8642.792064]  [<ffffffff810f93a2>] SyS_delete_module+0x132/0x1c0
      [ 8642.793450]  [<ffffffff81012c61>] ? do_notify_resume+0x61/0xa0
      [ 8642.794837]  [<ffffffff816d2029>] system_call_fastpath+0x12/0x17
      
      The issue is that test_and_set_bit() done on adapter->state is being
      performed *after* the netdevice has been freed via free_netdev().
      
      When netdev is being allocated on initialization time, it allocates
      a private area, here struct ixgbe_adapter, that resides after the
      net_device structure. In ixgbe_probe(), the device init routine,
      we set up the adapter after alloc_etherdev_mq() on the private area
      and add a reference for the pci_dev as well via pci_set_drvdata().
      
      Both in the error path of ixgbe_probe(), but also on module unload
      when ixgbe_remove() is being called, commit 41c62843 ("ixgbe:
      Fix rcu warnings induced by LER") accesses adapter after free_netdev().
      The patch stores the result in a bool and thus fixes above oops on my
      side.
      
      Fixes: 41c62843 ("ixgbe: Fix rcu warnings induced by LER")
      Cc: stable <stable@vger.kernel.org>
      Cc: Mark Rustad <mark.d.rustad@intel.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5b2ffc0
    • V
      ixgbe: Correctly disable VLAN filter in promiscuous mode · 4556dc59
      Vlad Yasevich 提交于
      IXGBE adapter seems to require that VLAN filtering be enabled if
      VMDQ or SRIOV are enabled.  When those functions are disabled,
      VLAN filtering may be disabled in promiscuous mode.
      
      Prior to commit a9b8943e ("ixgbe: remove vlan_filter_disable
      and enable functions")
      
      The logic was correct.  However, after the commit the logic
      got reversed and VLAN filtered in now turned on when VMDQ/SRIOV
      is disabled.
      
      This patch changes the condition to enable hw vlan filtered
      when VMDQ or SRIOV is enabled.
      
      Fixes: a9b8943e ("ixgbe: remove vlan_filter_disable and enable functions")
      Cc: stable <stable@vger.kernel.org>
      CC: Jacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4556dc59
  8. 21 11月, 2014 4 次提交
  9. 20 11月, 2014 2 次提交
    • O
      net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too · 9737c6ab
      Or Gerlitz 提交于
      This is currently missing, which results in a crash when one attempts
      to set VXLAN tunnel over the mlx4_en when acting as PF.
      
      	[ 2408.785472] BUG: unable to handle kernel NULL pointer dereference at (null)
      	[...]
      	[ 2408.994104] Call Trace:
      	[ 2408.996584]  [<ffffffffa021f7f5>] ? vxlan_get_rx_port+0xd6/0x103 [vxlan]
      	[ 2409.003316]  [<ffffffffa021f71f>] ? vxlan_lowerdev_event+0xf2/0xf2 [vxlan]
      	[ 2409.010225]  [<ffffffffa0630358>] mlx4_en_start_port+0x862/0x96a [mlx4_en]
      	[ 2409.017132]  [<ffffffffa063070f>] mlx4_en_open+0x17f/0x1b8 [mlx4_en]
      
      While here, make sure to invoke vxlan_get_rx_port() only when VXLAN
      offloads are actually enabled and not when they are only supported.
      Reported-by: NIdo Shamay <idos@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9737c6ab
    • N
      bonding: fix curr_active_slave/carrier with loadbalance arp monitoring · b8e4500f
      Nikolay Aleksandrov 提交于
      Since commit 6fde8f03 ("bonding: fix locking in
      bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
      stale curr_active_slave when using arp monitoring in loadbalance modes. The
      reason is that in bond_loadbalance_arp_mon() we can't have
      do_failover == true but slave_state_changed == false, whenever do_failover
      is true then slave_state_changed is also true. Then the following piece
      from bond_loadbalance_arp_mon():
                      if (slave_state_changed) {
                              bond_slave_state_change(bond);
                              if (BOND_MODE(bond) == BOND_MODE_XOR)
                                      bond_update_slave_arr(bond, NULL);
                      } else if (do_failover) {
                              block_netpoll_tx();
                              bond_select_active_slave(bond);
                              unblock_netpoll_tx();
                      }
      
      will execute only the first branch, always and regardless of do_failover.
      Since these two events aren't related in such way, we need to decouple and
      consider them separately.
      
      For example this issue could lead to the following result:
      Bonding Mode: load balancing (round-robin)
      *MII Status: down*
      MII Polling Interval (ms): 0
      Up Delay (ms): 0
      Down Delay (ms): 0
      ARP Polling Interval (ms): 100
      ARP IP target/s (n.n.n.n form): 192.168.9.2
      
      Slave Interface: ens12
      *MII Status: up*
      Speed: 10000 Mbps
      Duplex: full
      Link Failure Count: 2
      Permanent HW addr: 00:0f:53:01:42:2c
      Slave queue ID: 0
      
      Slave Interface: eth1
      *MII Status: up*
      Speed: Unknown
      Duplex: Unknown
      Link Failure Count: 70
      Permanent HW addr: 52:54:00:2f:0f:8e
      Slave queue ID: 0
      
      Since some interfaces are up, then the status of the bond should also be
      up, but it will never change unless something invokes bond_set_carrier()
      (i.e. enslave, bond_select_active_slave etc). Now, if I force the
      calling of bond_select_active_slave via for example changing
      primary_reselect (it can change in any mode), then the MII status goes to
      "up" because it calls bond_select_active_slave() which should've been done
      from bond_loadbalance_arp_mon() itself.
      
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      
      Fixes: 6fde8f03 ("bonding: fix locking in bond_loadbalance_arp_mon()")
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Acked-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
      Acked-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8e4500f
  10. 19 11月, 2014 8 次提交
    • J
      vxlan: Inline vxlan_gso_check(). · 11bf7828
      Joe Stringer 提交于
      Suggested-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NJoe Stringer <joestringer@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11bf7828
    • D
      can: m_can: update to support CAN FD features · 80646733
      Dong Aisheng 提交于
      Bosch M_CAN is CAN FD capable device. This patch implements the CAN
      FD features include up to 64 bytes payload and bitrate switch function.
      1) Change the Rx FIFO and Tx Buffer to 64 bytes for support CAN FD
         up to 64 bytes payload. It's backward compatible with old 8 bytes
         normal CAN frame.
      2) Allocate can frame or canfd frame based on EDL bit
      3) Bitrate Switch function is disabled by default and will be enabled
         according to CANFD_BRS bit in cf->flags.
      Acked-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      80646733
    • D
      can: m_can: fix incorrect error messages · a93f5cae
      Dong Aisheng 提交于
      Fix a few error messages.
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      a93f5cae
    • D
      can: m_can: add missing delay after setting CCCR_INIT bit · 7660f633
      Dong Aisheng 提交于
      The spec mentions there may be a delay until the value written to INIT can be
      read back due to the synchronization mechanism between the two clock domains.
      But it does not indicate the exact clock cycles needed. The 5us delay is a
      test value and seems ok.
      
      Without the delay, CCCR.CCE bit may fail to be set and then the initialization
      fail sometimes when do repeatly up and down.
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      7660f633
    • D
      can: m_can: fix not set can_dlc for remote frame · 921f1681
      Dong Aisheng 提交于
      The original code missed to set the cf->can_dlc in the RTR case, so add it.
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      921f1681
    • D
      can: m_can: fix possible sleep in napi poll · f6a99649
      Dong Aisheng 提交于
      The m_can_get_berr_counter function can sleep and it may be called in napi poll
      function. Rework it to fix the following warning.
      
      root@imx6qdlsolo:~# cangen can0 -f -L 12 -D 112233445566778899001122
      [ 1846.017565] m_can 20e8000.can can0: entered error warning state
      [ 1846.023551] ------------[ cut here ]------------
      [ 1846.028216] WARNING: CPU: 0 PID: 560 at kernel/locking/mutex.c:867 mutex_trylock+0x218/0x23c()
      [ 1846.036889] DEBUG_LOCKS_WARN_ON(in_interrupt())
      [ 1846.041263] Modules linked in:
      [ 1846.044594] CPU: 0 PID: 560 Comm: cangen Not tainted 3.17.0-rc4-next-20140915-00010-g032d018-dirty #477
      [ 1846.054033] Backtrace:
      [ 1846.056557] [<80012448>] (dump_backtrace) from [<80012728>] (show_stack+0x18/0x1c)
      [ 1846.064180]  r6:809a07ec r5:809a07ec r4:00000000 r3:00000000
      [ 1846.069966] [<80012710>] (show_stack) from [<806c9ee0>] (dump_stack+0x8c/0xa4)
      [ 1846.077264] [<806c9e54>] (dump_stack) from [<8002aa78>] (warn_slowpath_common+0x70/0x94)
      [ 1846.085403]  r6:806cd1b0 r5:00000009 r4:be1d5c20 r3:be07b0c0
      [ 1846.091204] [<8002aa08>] (warn_slowpath_common) from [<8002aad4>] (warn_slowpath_fmt+0x38/0x40)
      [ 1846.099951]  r8:8119106c r7:80515aa4 r6:be027000 r5:00000001 r4:809d1df4
      [ 1846.106830] [<8002aaa0>] (warn_slowpath_fmt) from [<806cd1b0>] (mutex_trylock+0x218/0x23c)
      [ 1846.115141]  r3:80851c88 r2:8084fb74
      [ 1846.118804] [<806ccf98>] (mutex_trylock) from [<80515aa4>] (clk_prepare_lock+0x14/0xf4)
      [ 1846.126859]  r8:00000040 r7:be1d5cec r6:be027000 r5:be255800 r4:be027000
      [ 1846.133737] [<80515a90>] (clk_prepare_lock) from [<80517660>] (clk_prepare+0x14/0x2c)
      [ 1846.141583]  r5:be255800 r4:be027000
      [ 1846.145272] [<8051764c>] (clk_prepare) from [<8041ff14>] (m_can_get_berr_counter+0x20/0xd4)
      [ 1846.153672]  r4:be255800 r3:be07b0c0
      [ 1846.157325] [<8041fef4>] (m_can_get_berr_counter) from [<80420428>] (m_can_poll+0x310/0x8fc)
      [ 1846.165809]  r7:bd4dc540 r6:00000744 r5:11300000 r4:be255800
      [ 1846.171590] [<80420118>] (m_can_poll) from [<8056a468>] (net_rx_action+0xcc/0x1b4)
      [ 1846.179204]  r10:00000101 r9:be255ebc r8:00000040 r7:be7c3208 r6:8097c100 r5:be7c3200
      [ 1846.187192]  r4:0000012c
      [ 1846.189779] [<8056a39c>] (net_rx_action) from [<8002deec>] (__do_softirq+0xfc/0x2c4)
      [ 1846.197568]  r10:00000101 r9:8097c088 r8:00000003 r7:8097c080 r6:40000001 r5:8097c08c
      [ 1846.205559]  r4:00000020
      [ 1846.208144] [<8002ddf0>] (__do_softirq) from [<8002e194>] (do_softirq+0x7c/0x88)
      [ 1846.215588]  r10:00000000 r9:bd516a60 r8:be18ce00 r7:00000000 r6:be255800 r5:8056c0ec
      [ 1846.223578]  r4:60000093
      [ 1846.226163] [<8002e118>] (do_softirq) from [<8002e288>] (__local_bh_enable_ip+0xe8/0x10c)
      [ 1846.234386]  r4:00000200 r3:be1d4000
      [ 1846.238036] [<8002e1a0>] (__local_bh_enable_ip) from [<8056c108>] (__dev_queue_xmit+0x314/0x6b0)
      [ 1846.246868]  r6:be255800 r5:bd516a00 r4:00000000 r3:be07b0c0
      [ 1846.252645] [<8056bdf4>] (__dev_queue_xmit) from [<8056c4b8>] (dev_queue_xmit+0x14/0x18)
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      f6a99649
    • D
      can: m_can: add missing message RAM initialization · 962845da
      Dong Aisheng 提交于
      The M_CAN message RAM is usually equipped with a parity or ECC functionality.
      But RAM cells suffer a hardware reset and can therefore hold arbitrary content
      at startup - including parity and/or ECC bits.
      
      To prevent the M_CAN controller detecting checksum errors when reading
      potentially uninitialized TX message RAM content to transmit CAN frames the TX
      message RAM has to be written with (any kind of) initial data.
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      962845da
    • D
      can: m_can: add CONFIG_HAS_IOMEM dependence · efe22286
      David Cohen 提交于
      m_can uses io memory which makes it not compilable on architectures
      without HAS_IOMEM such as UML:
      
      drivers/built-in.o: In function `m_can_plat_probe':
      m_can.c:(.text+0x218cc5): undefined reference to `devm_ioremap_resource'
      m_can.c:(.text+0x218df9): undefined reference to `devm_ioremap'
      Signed-off-by: NDavid Cohen <david.a.cohen@linux.intel.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      efe22286