1. 30 5月, 2014 2 次提交
    • Z
      ACPI / PNP: use device ID list for PNPACPI device enumeration · eec15edb
      Zhang Rui 提交于
      ACPI can be used to enumerate PNP devices, but the code does not
      handle this in the right way currently.  Namely, if an ACPI device
      object
       1. Has a _CRS method,
       2. Has an identification of
          "three capital characters followed by four hex digits",
       3. Is not in the excluded IDs list,
      it will be enumerated to PNP bus (that is, a PNP device object will
      be create for it).  This means that, actually, the PNP bus type is
      used as the default bus type for enumerating _HID devices in ACPI.
      
      However, more and more _HID devices need to be enumerated to the
      platform bus instead (that is, platform device objects need to be
      created for them).  As a result, the device ID list in acpi_platform.c
      is used to enforce creating platform device objects rather than PNP
      device objects for matching devices.  That list has been continuously
      growing recently, unfortunately, and it is pretty much guaranteed to
      grow even more in the future.
      
      To address that problem it is better to enumerate _HID devices
      as platform devices by default.  To this end, change the way of
      enumerating PNP devices by adding a PNP ACPI scan handler that
      will use a device ID list to create PNP devices for the ACPI
      device objects whose device IDs are present in that list.
      
      The initial device ID list in the PNP ACPI scan handler contains
      all of the pnp_device_id strings from all the existing PNP drivers,
      so this change should be transparent to the PNP core and all of the
      PNP drivers.  Still, in the future it should be possible to reduce
      its size by converting PNP drivers that need not be PNP for any
      technical reasons into platform drivers.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      [rjw: Rewrote the changelog, modified the PNP ACPI scan handler code]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      eec15edb
    • R
      ACPI / scan: .match() callback for ACPI scan handlers · aca0a4eb
      Rafael J. Wysocki 提交于
      Introduce a .match() callback for ACPI scan handlers to allow them to
      use more elaborate matching algorithms if necessary.  That is needed
      for the upcoming PNP scan handler in particular.
      
      This change is based on a Zhang Rui's prototype.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      aca0a4eb
  2. 25 5月, 2014 5 次提交
  3. 23 5月, 2014 4 次提交
    • J
      [SCSI] scsi_transport_sas: move bsg destructor into sas_rphy_remove · 6aa6caff
      Joe Lawrence 提交于
      The recent change in sysfs, bcdde7e2
      "sysfs: make __sysfs_remove_dir() recursive" revealed an asymmetric
      rphy device creation/deletion sequence in scsi_transport_sas:
      
        modprobe mpt2sas
          sas_rphy_add
            device_add A               rphy->dev
            device_add B               sas_device transport class
            device_add C               sas_end_device transport class
            device_add D               bsg class
      
        rmmod mpt2sas
          sas_rphy_delete
            sas_rphy_remove
              device_del B
              device_del C
              device_del A
                sysfs_remove_group     recursive sysfs dir removal
            sas_rphy_free
              device_del D             warning
      
        where device A is the parent of B, C, and D.
      
      When sas_rphy_free tries to unregister the bsg request queue (device D
      above), the ensuing sysfs cleanup discovers that its sysfs group has
      already been removed and emits a warning, "sysfs group... not found for
      kobject 'end_device-X:0'".
      
      Since bsg creation is a side effect of sas_rphy_add, move its
      complementary removal call into sas_rphy_remove. This imposes the
      following tear-down order for the devices above: D, B, C, A.
      
      Note the sas_device and sas_end_device transport class devices (B and C
      above) are created and destroyed both via the list match traversal in
      attribute_container_device_trigger, so the order in which they are
      handled is fixed. This is fine as long as they are deleted before their
      parent device.
      Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      6aa6caff
    • V
      bonding: Send ALB learning packets using the right source · d0c21d43
      Vlad Yasevich 提交于
      ALB learning packets are currentlyalways sent using the slave mac
      address for all vlans configured on top of bond.   This is not always
      correct, as vlans may change their mac address.
      This patch introduced a concept of strict matching where the
      source of learning packets can either strictly match the address
      passed in, or it can determine a more correct address to use.
      
      There are 3 casese to consider:
        1) Switchover.  In this case, we have a new active slave and we need
           tell the switch about all addresses available on the slave.
        2) Monitor.  We'll periodically refresh learning info for all slaves.
           In this case, we refresh all addresses for current active, and just
           the slave address for other slaves.
        3) Teaching of disabled adddress.  This happens as part of the
           failover and in this case, we alwyas to use just the address
           provided.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0c21d43
    • V
      bonding: Don't assume 802.1Q when sending alb learning packets. · d6b694c0
      Vlad Yasevich 提交于
      TLB/ALB learning packets always assume 802.1Q vlan protocol, but
      that is no longer the case since we now have support for Q-in-Q
      on top of bonding.  Pass the vlan protocol to alb_send_lp_vid()
      so that the packets are properly tagged.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Acked-by: NVeaceslav Falico <vfalico@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6b694c0
    • H
      stmmac: Remove unbalanced clk_disable call · 89df20d9
      Hans de Goede 提交于
      The stmmac_open call was calling clk_disable_unprepare on phy init
      failure, but it never calls clk_prepare_enable, this causes
      a WARN_ON in the clk framework to trigger if for some reason phy init
      fails.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Acked-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89df20d9
  4. 22 5月, 2014 2 次提交
  5. 21 5月, 2014 1 次提交
  6. 20 5月, 2014 17 次提交
  7. 19 5月, 2014 2 次提交
  8. 18 5月, 2014 1 次提交
    • M
      target: fix memory leak on XCOPY · 1e1110c4
      Mikulas Patocka 提交于
      On each processed XCOPY command, two "kmalloc-512" memory objects are
      leaked. These represent two allocations of struct xcopy_pt_cmd in
      target_core_xcopy.c.
      
      The reason for the memory leak is that the cmd_kref field is not
      initialized (thus, it is zero because the allocations were done with
      kzalloc). When we decrement zero kref in target_put_sess_cmd, the result
      is not zero, thus target_release_cmd_kref is not called.
      
      This patch fixes the bug by moving kref initialization from
      target_get_sess_cmd to transport_init_se_cmd (this function is called from
      target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be
      easily verified that all code that calls target_get_sess_cmd also calls
      transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce
      any new problems.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org	# 3.12+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      1e1110c4
  9. 17 5月, 2014 6 次提交
    • V
      bonding: Fix alb mode to only use first level vlans. · f60c3704
      Vlad Yasevich 提交于
      ALB/TLB learning packets use all vlans configured on top
      of the bond.  This ends up being incorrect if we have a stack
      of vlans on top of the bond.  ALB/TLB should only use
      first level/outer most vlans in its announcements.
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f60c3704
    • V
      bonding: Fix stacked device detection in arp monitoring · 44a40855
      Vlad Yasevich 提交于
      Prior to commit fbd929f2
      	bonding: support QinQ for bond arp interval
      
      the arp monitoring code allowed for proper detection of devices
      stacked on top of vlans.  Since the above commit, the
      code can still detect a device stacked on top of single
      vlan, but not a device stacked on top of Q-in-Q configuration.
      The search will only set the inner vlan tag if the route
      device is the vlan device.  However, this is not always the
      case, as it is possible to extend the stacked configuration.
      
      With this patch it is possible to provision devices on
      top Q-in-Q vlan configuration that should be used as
      a source of ARP monitoring information.
      
      For example:
      ip link add link bond0 vlan10 type vlan proto 802.1q id 10
      ip link add link vlan10 vlan100 type vlan proto 802.1q id 100
      ip link add link vlan100 type macvlan
      
      Note:  This patch limites the number of stacked VLANs to 2,
      just like before.  The original, however had another issue
      in that if we had more then 2 levels of VLANs, we would end
      up generating incorrectly tagged traffic.  This is no longer
      possible.
      
      Fixes: fbd929f2 (bonding: support QinQ for bond arp interval)
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@redhat.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Ding Tianhong <dingtianhong@huawei.com>
      CC: Patric McHardy <kaber@trash.net>
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44a40855
    • T
      random: fix BUG_ON caused by accounting simplification · f9c6d498
      Theodore Ts'o 提交于
      Commit ee1de406 ("random: simplify accounting logic") simplified
      things too much, in that it allows the following to trigger an
      overflow that results in a BUG_ON crash:
      
      dd if=/dev/urandom of=/dev/zero bs=67108707 count=1
      
      Thanks to Peter Zihlstra for discovering the crash, and Hannes
      Frederic for analyizing the root cause.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Reported-by: NPeter Zijlstra <peterz@infradead.org>
      Reported-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Cc: Greg Price <price@mit.edu>
      f9c6d498
    • V
      macvlan: Fix lockdep warnings with stacked macvlan devices · c674ac30
      Vlad Yasevich 提交于
      Macvlan devices try to avoid stacking, but that's not always
      successfull or even desired.  As an example, the following
      configuration is perefectly legal and valid:
      
      eth0 <--- macvlan0 <---- vlan0.10 <--- macvlan1
      
      However, this configuration produces the following lockdep
      trace:
      [  115.620418] ======================================================
      [  115.620477] [ INFO: possible circular locking dependency detected ]
      [  115.620516] 3.15.0-rc1+ #24 Not tainted
      [  115.620540] -------------------------------------------------------
      [  115.620577] ip/1704 is trying to acquire lock:
      [  115.620604]  (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
      [  115.620686]
      but task is already holding lock:
      [  115.620723]  (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40
      [  115.620795]
      which lock already depends on the new lock.
      
      [  115.620853]
      the existing dependency chain (in reverse order) is:
      [  115.620894]
      -> #1 (&macvlan_netdev_addr_lock_key){+.....}:
      [  115.620935]        [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
      [  115.620974]        [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
      [  115.621019]        [<ffffffffa07296c3>] vlan_dev_set_rx_mode+0x53/0x110 [8021q]
      [  115.621066]        [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
      [  115.621105]        [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
      [  115.621143]        [<ffffffff815da6be>] __dev_open+0xde/0x140
      [  115.621174]        [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
      [  115.621174]        [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
      [  115.621174]        [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
      [  115.621174]        [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
      [  115.621174]        [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
      [  115.621174]        [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
      [  115.621174]        [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
      [  115.621174]        [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
      [  115.621174]        [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
      [  115.621174]        [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
      [  115.621174]        [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
      [  115.621174]        [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
      [  115.621174]        [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
      [  115.621174]        [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
      [  115.621174]
      -> #0 (&vlan_netdev_addr_lock_key/1){+.....}:
      [  115.621174]        [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60
      [  115.621174]        [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
      [  115.621174]        [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
      [  115.621174]        [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
      [  115.621174]        [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan]
      [  115.621174]        [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
      [  115.621174]        [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
      [  115.621174]        [<ffffffff815da6be>] __dev_open+0xde/0x140
      [  115.621174]        [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
      [  115.621174]        [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
      [  115.621174]        [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
      [  115.621174]        [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
      [  115.621174]        [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
      [  115.621174]        [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
      [  115.621174]        [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
      [  115.621174]        [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
      [  115.621174]        [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
      [  115.621174]        [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
      [  115.621174]        [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
      [  115.621174]        [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
      [  115.621174]        [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
      [  115.621174]        [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
      [  115.621174]
      other info that might help us debug this:
      
      [  115.621174]  Possible unsafe locking scenario:
      
      [  115.621174]        CPU0                    CPU1
      [  115.621174]        ----                    ----
      [  115.621174]   lock(&macvlan_netdev_addr_lock_key);
      [  115.621174]                                lock(&vlan_netdev_addr_lock_key/1);
      [  115.621174]                                lock(&macvlan_netdev_addr_lock_key);
      [  115.621174]   lock(&vlan_netdev_addr_lock_key/1);
      [  115.621174]
       *** DEADLOCK ***
      
      [  115.621174] 2 locks held by ip/1704:
      [  115.621174]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815e6dbb>] rtnetlink_rcv+0x1b/0x40
      [  115.621174]  #1:  (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40
      [  115.621174]
      stack backtrace:
      [  115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24
      [  115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
      [  115.621174]  ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0
      [  115.621174]  ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8
      [  115.621174]  0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230
      [  115.621174] Call Trace:
      [  115.621174]  [<ffffffff816ee20c>] dump_stack+0x4d/0x66
      [  115.621174]  [<ffffffff816e9e1b>] print_circular_bug+0x200/0x20e
      [  115.621174]  [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60
      [  115.621174]  [<ffffffff810d3172>] ? trace_hardirqs_on_caller+0xb2/0x1d0
      [  115.621174]  [<ffffffff810d57f2>] lock_acquire+0xa2/0x130
      [  115.621174]  [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80
      [  115.621174]  [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50
      [  115.621174]  [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80
      [  115.621174]  [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80
      [  115.621174]  [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan]
      [  115.621174]  [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0
      [  115.621174]  [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40
      [  115.621174]  [<ffffffff815da6be>] __dev_open+0xde/0x140
      [  115.621174]  [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170
      [  115.621174]  [<ffffffff815daaa9>] dev_change_flags+0x29/0x60
      [  115.621174]  [<ffffffff811e1db1>] ? mem_cgroup_bad_page_check+0x21/0x30
      [  115.621174]  [<ffffffff815e7f11>] do_setlink+0x321/0x9a0
      [  115.621174]  [<ffffffff810d394c>] ? __lock_acquire+0x37c/0x1a60
      [  115.621174]  [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730
      [  115.621174]  [<ffffffff815ea169>] ? rtnl_newlink+0xe9/0x730
      [  115.621174]  [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250
      [  115.621174]  [<ffffffff810d329d>] ? trace_hardirqs_on+0xd/0x10
      [  115.621174]  [<ffffffff815e6dbb>] ? rtnetlink_rcv+0x1b/0x40
      [  115.621174]  [<ffffffff815e6de0>] ? rtnetlink_rcv+0x40/0x40
      [  115.621174]  [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0
      [  115.621174]  [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40
      [  115.621174]  [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0
      [  115.621174]  [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740
      [  115.621174]  [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0
      [  115.621174]  [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0
      [  115.621174]  [<ffffffff8119d4f8>] ? might_fault+0xa8/0xb0
      [  115.621174]  [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0
      [  115.621174]  [<ffffffff815cb51e>] ? verify_iovec+0x5e/0xe0
      [  115.621174]  [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380
      [  115.621174]  [<ffffffff816faa0d>] ? __do_page_fault+0x11d/0x570
      [  115.621174]  [<ffffffff810cfe9f>] ? up_read+0x1f/0x40
      [  115.621174]  [<ffffffff816fab04>] ? __do_page_fault+0x214/0x570
      [  115.621174]  [<ffffffff8120a10b>] ? mntput_no_expire+0x6b/0x1c0
      [  115.621174]  [<ffffffff8120a0b7>] ? mntput_no_expire+0x17/0x1c0
      [  115.621174]  [<ffffffff8120a284>] ? mntput+0x24/0x40
      [  115.621174]  [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80
      [  115.621174]  [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20
      [  115.621174]  [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b
      
      Fix this by correctly providing macvlan lockdep class.
      Signed-off-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c674ac30
    • T
      clk: tegra: Fix wrong value written to PLLE_AUX · d2c834ab
      Tuomas Tynkkynen 提交于
      The value written to PLLE_AUX was incorrect due to a wrong variable
      being used. Without this fix SATA does not work.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NTuomas Tynkkynen <ttynkkynen@nvidia.com>
      Tested-by: NMikko Perttunen <mperttunen@nvidia.com>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Tested-by: NThierry Reding <treding@nvidia.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NMike Turquette <mturquette@linaro.org>
      [mturquette@linaro.org: improved changelog]
      d2c834ab
    • J
      staging: rtl8723au: Do not reset wdev->iftype in netdev_close() · bb4e5065
      Jes Sorensen 提交于
      wdev->ifdev should be set by .change_virtual_intf(). This solves the
      problem of WARN() messages on module unload.
      Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb4e5065
新手
引导
客服 返回
顶部