1. 21 7月, 2015 11 次提交
    • J
      stmmac: fix setting of driver data in stmmac_dvr_probe · a7a62685
      Joachim Eastwood 提交于
      Commit 803f8fc4 ("stmmac: move driver data setting into
      stmmac_dvr_probe") mistakenly set priv and not priv->dev as
      driver data. This meant that the remove, resume and suspend
      callbacks that fetched and tried to use this data would most
      likely explode. Fix the issue by using the correct variable.
      
      Fixes: 803f8fc4 ("stmmac: move driver data setting into stmmac_dvr_probe")
      Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7a62685
    • S
      net/mdio: fix mdio_bus_match for c45 PHY · e0536cd9
      Shaohui Xie 提交于
      We store c45 PHY's id information in c45_ids, so it should be used to
      check the matching between PHY driver and PHY device for c45 PHY.
      Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0536cd9
    • R
      qmi_wwan: add the second QMI/network interface for Sierra Wireless MC7305/MC7355 · e3426ca7
      Reinhard Speyerer 提交于
      Sierra Wireless MC7305/MC7355 with USB ID 1199:9041 also provide a
      second QMI/network interface like the MC73xx with USB ID 1199:68c0 on
      USB interface #10 when used in the appropriate USB configuration.
      Add the corresponding QMI_FIXED_INTF entry to the qmi_wwan driver.
      
      Please note that the second QMI/network interface is not working for
      early MC73xx firmware versions like 01.08.x as the device does not
      respond to QMI messages on the second /dev/cdc-wdm port.
      Signed-off-by: NReinhard Speyerer <rspmn@arcor.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3426ca7
    • S
      ravb: fix race updating TCCR · 06613e38
      Sergei Shtylyov 提交于
      The TCCR.TSRQn bit may get clearead after TCCR gets read, so that TCCR write
      would get skipped. We don't need to check this bit before setting.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06613e38
    • K
      net: netcp: fix improper initialization in netcp_ndo_open() · 194ac06e
      Karicheri, Muralidharan 提交于
      The keystone qmss will raise interrupt when packet arrive at the
      receive queue. Only control available to avoid interrupt from happening
      is to keep the free descriptor queue (FDQ) empty in the receive side.
      So the filling of descriptors into the FDQ has to happen after
      request_irq() call is made as part of knav_queue_enable_notify(). So
      move the function netcp_rxpool_refill() after this call.
      Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      194ac06e
    • D
      bonding: correct the MAC address for "follow" fail_over_mac policy · a951bc1e
      dingtianhong 提交于
      The "follow" fail_over_mac policy is useful for multiport devices that
      either become confused or incur a performance penalty when multiple
      ports are programmed with the same MAC address, but the same MAC
      address still may happened by this steps for this policy:
      
      1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
         bond0 has the same mac address with eth0, it is MAC1.
      
      2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
         eth1 is backup, eth1 has MAC2.
      
      3) ifconfig eth0 down
         eth1 became active slave, bond will swap MAC for eth0 and eth1,
         so eth1 has MAC1, and eth0 has MAC2.
      
      4) ifconfig eth1 down
         there is no active slave, and eth1 still has MAC1, eth2 has MAC2.
      
      5) ifconfig eth0 up
         the eth0 became active slave again, the bond set eth0 to MAC1.
      
      Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
      MAC address, it will break this policy for ACTIVE_BACKUP mode.
      
      This patch will fix this problem by finding the old active slave and
      swap them MAC address before change active slave.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Tested-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a951bc1e
    • F
      net: dsa: bcm_sf2: do not use indirect reads and writes for 7445E0 · b8c6cd1d
      Florian Fainelli 提交于
      7445E0 contains an ECO which disconnected the internal SF2 pseudo-PHY which was
      known to conflict with the external pseudo-PHY of BCM53125 switches. This
      motivated the need to utilize the internal SF2 MDIO controller via indirect
      register reads/writes to control external Broadcom switches due to this address
      conflict (both responded at address 30d).
      
      For 7445E0, the internal pseudo-PHY of the SF2 switch got disconnected, and as
      a consequence this prevents the internal SF2 MDIO bus controller from reading
      data (reads back everything as 0) since the MDI line is tied low.
      
      Fix this by making the indirect register reads and writes conditional to
      7445D0, on 7445E0 we can utilize the SWITCH_MDIO controller (backed by
      mdio-unimac and not the DSA created slave MII bus).
      
      We utilize of_machine_is_compatible() here since this is the only way for use
      to differentiate between these two chips in a way that does not violate layers
      or becomes (too) vendor-specific.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8c6cd1d
    • N
      bonding: correctly handle bonding type change on enslave failure · 7d5cd2ce
      Nikolay Aleksandrov 提交于
      If the bond is enslaving a device with different type it will be setup
      by it, but if after being setup the enslave fails the bond doesn't
      switch back its type and also keeps pointers to foreign structures that can
      be long gone. Thus revert back any type changes if the enslave failed and
      the bond had to change its type.
      Example:
       Before patch:
      $ echo lo > bond0/bonding/slaves
      -bash: echo: write error: Cannot assign requested address
      $ ip l sh bond0
      20: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
      mode DEFAULT group default
          link/loopback 16:54:78:34:bd:41 brd 00:00:00:00:00:00
      $ echo +eth1 > bond0/bonding/slaves
      $ ip l sh bond0
      20: bond0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
      DEFAULT group default qlen 1000
          link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
      (notice the MASTER flag is gone)
      
       After patch:
      $ echo lo > bond0/bonding/slaves
      -bash: echo: write error: Cannot assign requested address
      $ ip l sh bond0
      21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
      mode DEFAULT group default qlen 1000
          link/ether 6e:66:94:f6:07:fc brd ff:ff:ff:ff:ff:ff
      $ echo +eth1 > bond0/bonding/slaves
      $ ip l sh bond0
      21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
      mode DEFAULT group default qlen 1000
          link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Fixes: e36b9d16 ("bonding: clean muticast addresses when device changes type")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d5cd2ce
    • N
      bonding: fix destruction of bond with devices different from arphrd_ether · 06f6d109
      Nikolay Aleksandrov 提交于
      When the bonding is being unloaded and the netdevice notifier is
      unregistered it executes NETDEV_UNREGISTER for each device which should
      remove the bond's proc entry but if the device enslaved is not of
      ARPHRD_ETHER type and is in front of the bonding, it may execute
      bond_release_and_destroy() first which would release the last slave and
      destroy the bond device leaving the proc entry and thus we will get the
      following error (with dynamic debug on for bond_netdev_event to see the
      events order):
      [  908.963051] eql: event: 9
      [  908.963052] eql: IFF_SLAVE
      [  908.963054] eql: event: 2
      [  908.963056] eql: IFF_SLAVE
      [  908.963058] eql: event: 6
      [  908.963059] eql: IFF_SLAVE
      [  908.963110] bond0: Releasing active interface eql
      [  908.976168] bond0: Destroying bond bond0
      [  908.976266] bond0 (unregistering): Released all slaves
      [  908.984097] ------------[ cut here ]------------
      [  908.984107] WARNING: CPU: 0 PID: 1787 at fs/proc/generic.c:575
      remove_proc_entry+0x112/0x160()
      [  908.984110] remove_proc_entry: removing non-empty directory
      'net/bonding', leaking at least 'bond0'
      [  908.984111] Modules linked in: bonding(-) eql(O) 9p nfsd auth_rpcgss
      oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul
      crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev qxl drm_kms_helper
      snd_hda_codec_generic aesni_intel ttm aes_x86_64 glue_helper pcspkr lrw
      gf128mul ablk_helper cryptd snd_hda_intel virtio_console snd_hda_codec
      psmouse serio_raw snd_hwdep snd_hda_core 9pnet_virtio 9pnet evdev joydev
      drm virtio_balloon snd_pcm snd_timer snd soundcore i2c_piix4 i2c_core
      pvpanic acpi_cpufreq parport_pc parport processor thermal_sys button
      autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sr_mod cdrom
      ata_generic virtio_blk virtio_net floppy ata_piix e1000 libata ehci_pci
      virtio_pci scsi_mod uhci_hcd ehci_hcd virtio_ring virtio usbcore
      usb_common [last unloaded: bonding]
      
      [  908.984168] CPU: 0 PID: 1787 Comm: rmmod Tainted: G        W  O
      4.2.0-rc2+ #8
      [  908.984170] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [  908.984172]  0000000000000000 ffffffff81732d41 ffffffff81525b34
      ffff8800358dfda8
      [  908.984175]  ffffffff8106c521 ffff88003595af78 ffff88003595af40
      ffff88003e3a4280
      [  908.984178]  ffffffffa058d040 0000000000000000 ffffffff8106c59a
      ffffffff8172ebd0
      [  908.984181] Call Trace:
      [  908.984188]  [<ffffffff81525b34>] ? dump_stack+0x40/0x50
      [  908.984193]  [<ffffffff8106c521>] ? warn_slowpath_common+0x81/0xb0
      [  908.984196]  [<ffffffff8106c59a>] ? warn_slowpath_fmt+0x4a/0x50
      [  908.984199]  [<ffffffff81218352>] ? remove_proc_entry+0x112/0x160
      [  908.984205]  [<ffffffffa05850e6>] ? bond_destroy_proc_dir+0x26/0x30
      [bonding]
      [  908.984208]  [<ffffffffa057540e>] ? bond_net_exit+0x8e/0xa0 [bonding]
      [  908.984217]  [<ffffffff8142f407>] ? ops_exit_list.isra.4+0x37/0x70
      [  908.984225]  [<ffffffff8142f52d>] ?
      unregister_pernet_operations+0x8d/0xd0
      [  908.984228]  [<ffffffff8142f58d>] ?
      unregister_pernet_subsys+0x1d/0x30
      [  908.984232]  [<ffffffffa0585269>] ? bonding_exit+0x23/0xdba [bonding]
      [  908.984236]  [<ffffffff810e28ba>] ? SyS_delete_module+0x18a/0x250
      [  908.984241]  [<ffffffff81086f99>] ? task_work_run+0x89/0xc0
      [  908.984244]  [<ffffffff8152b732>] ?
      entry_SYSCALL_64_fastpath+0x16/0x75
      [  908.984247] ---[ end trace 7c006ed4abbef24b ]---
      
      Thus remove the proc entry manually if bond_release_and_destroy() is
      used. Because of the checks in bond_remove_proc_entry() it's not a
      problem for a bond device to change namespaces (the bug fixed by the
      Fixes commit) but since commit
      f9399814 ("bonding: Don't allow bond devices to change network
      namespaces.") that can't happen anyway.
      Reported-by: NCarol Soto <clsoto@linux.vnet.ibm.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Fixes: a64d49c3 ("bonding: Manage /proc/net/bonding/ entries from
                            the netdev events")
      Tested-by: NCarol L Soto <clsoto@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06f6d109
    • V
      net: dsa: mv88e6xxx: fix fid_mask when leaving bridge · 40a71660
      Vivien Didelot 提交于
      The mv88e6xxx_priv_state structure contains an fid_mask, where 1 means
      the FID is free to use, 0 means the FID is in use.
      
      This patch fixes the bit clear in mv88e6xxx_leave_bridge() when
      assigning a new FID to a port.
      
      Example scenario: I have 7 ports, port 5 is CPU, port 6 is unused (no
      PHY). After setting the ports 0, 1 and 2 in bridge br0, and ports 3 and
      4 in bridge br1, I have the following fid_mask: 0b111110010110 (0xf96).
      
      Indeed, br0 uses FID 0, and br1 uses FID 3.
      
      After setting nomaster for port 0, I get the wrong fid_mask: 0b10 (0x2).
      
      With this patch we correctly get 0b111110010100 (0xf94), meaning port 0
      uses FID 1, br0 uses FID 0, and br1 uses FID 3.
      Signed-off-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40a71660
    • M
      virtio_net: don't require ANY_LAYOUT with VERSION_1 · 75993300
      Michael S. Tsirkin 提交于
      ANY_LAYOUT is a compatibility feature. It's implied
      for VERSION_1 devices, and non-transitional devices
      might not offer it. Change code to behave accordingly.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75993300
  2. 17 7月, 2015 1 次提交
  3. 16 7月, 2015 10 次提交
  4. 15 7月, 2015 14 次提交
  5. 13 7月, 2015 4 次提交
    • L
      Revert "drm/i915: Use crtc_state->active in primary check_plane func" · 01e2d062
      Linus Torvalds 提交于
      This reverts commit dec4f799.
      
      Jörg Otte reports a NULL pointder dereference due to this commit, as
      'crtc_state' very much can be NULL:
      
              crtc_state = state->base.state ?
                      intel_atomic_get_crtc_state(state->base.state, intel_crtc) : NULL;
      
      So the change to test 'crtc_state->base.active' cannot possibly be
      correct as-is.
      
      There may be some other minimal fix (like just checking crtc_state for
      NULL), but I'm just reverting it now for the rc2 release, and people
      like Daniel Vetter who actually know this code will figure out what the
      right solution is in the longer term.
      Reported-and-bisected-by: NJörg Otte <jrg.otte@gmail.com>
      Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      01e2d062
    • O
      can: replace timestamp as unique skb attribute · d3b58c47
      Oliver Hartkopp 提交于
      Commit 514ac99c "can: fix multiple delivery of a single CAN frame for
      overlapping CAN filters" requires the skb->tstamp to be set to check for
      identical CAN skbs.
      
      Without timestamping to be required by user space applications this timestamp
      was not generated which lead to commit 36c01245 "can: fix loss of CAN frames
      in raw_rcv" - which forces the timestamp to be set in all CAN related skbuffs
      by introducing several __net_timestamp() calls.
      
      This forces e.g. out of tree drivers which are not using alloc_can{,fd}_skb()
      to add __net_timestamp() after skbuff creation to prevent the frame loss fixed
      in mainline Linux.
      
      This patch removes the timestamp dependency and uses an atomic counter to
      create an unique identifier together with the skbuff pointer.
      
      Btw: the new skbcnt element introduced in struct can_skb_priv has to be
      initialized with zero in out-of-tree drivers which are not using
      alloc_can{,fd}_skb() too.
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      d3b58c47
    • J
      can: c_can: Fix default pinmux glitch at init · 03336519
      J.D. Schroeder 提交于
      The previous change 3973c526 (net: can: c_can: Disable pins when CAN
      interface is down) causes a slight glitch on the pinctrl settings when used.
      Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
      the device core will automatically set the default pins. This causes the pins
      to be momentarily set to the default and then to the sleep state in
      register_c_can_dev(). By adding an optional "enable" state, boards can set the
      default pin state to be disabled and avoid the glitch when the switch from
      default to sleep first occurs. If the "enable" state is not available
      c_can_pinctrl_select_state() falls back to using the "default" pinctrl state.
      
      [Roger Q] - Forward port to v4.2 and use pinctrl_get_select().
      Signed-off-by: NJ.D. Schroeder <jay.schroeder@garmin.com>
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      03336519
    • S
      can: rcar_can: unify error messages · 585bc2ac
      Sergei Shtylyov 提交于
      All the error messages in the driver but  the ones from devm_clk_get() failures
      use similar format.  Make those  two messages consitent with others.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      585bc2ac