1. 01 10月, 2012 3 次提交
    • J
      IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support · 1ffeb2eb
      Jack Morgenstein 提交于
      1. Introduce the basic SR-IOV parvirtualization context objects for
         multiplexing and demultiplexing MADs.
      2. Introduce support for the new proxy and tunnel QP types.
      
      This patch introduces the objects required by the master for managing
      QP paravirtualization for guests.
      
      struct mlx4_ib_sriov is created by the master only.
      It is a container for the following:
      
      1. All the info required by the PPF to multiplex and de-multiplex MADs
         (including those from the PF). (struct mlx4_ib_demux_ctx demux)
      2. All the info required to manage alias GUIDs (i.e., the GUID at
         index 0 that each guest perceives.  In fact, this is not the GUID
         which is actually at index 0, but is, in fact, the GUID which is at
         index[<VF number>] in the physical table.
      3. structures which are used to manage CM paravirtualization
      4. structures for managing the real special QPs when running in SR-IOV
         mode.  The real SQPs are controlled by the PPF in this case.  All
         SQPs created and controlled by the ib core layer are proxy SQP.
      
      struct mlx4_ib_demux_ctx contains the information per port needed
      to manage paravirtualization:
      
      1. All multicast paravirt info
      2. All tunnel-qp paravirt info for the port.
      3. GUID-table and GUID-prefix for the port
      4. work queues.
      
      struct mlx4_ib_demux_pv_ctx contains all the info for managing the
      paravirtualized QPs for one slave/port.
      
      struct mlx4_ib_demux_pv_qp contains the info need to run an individual
      QP (either tunnel qp or real SQP).
      
      Note:  We made use of the 2 most significant bits in enum
      mlx4_ib_qp_flags (based on enum ib_qp_create_flags in ib_verbs.h).
      We need these bits in the low-level driver for internal purposes.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      1ffeb2eb
    • J
      IB/core: Add ib_find_exact_cached_pkey() · 73aaa741
      Jack Morgenstein 提交于
      When P_Key tables potentially contain both full and partial membership
      copies for the same P_Key, we need a function to find the index for an
      exact (16-bit) P_Key.
      
      This is necessary when the master forwards QP1 MADs sent by guests.
      If the guest has sent the MAD with a limited membership P_Key, we need
      to to forward the MAD using the same limited membership P_Key.  Since
      the master may have both the limited and the full member P_Keys in its
      table, we must make sure to retrieve the limited membership P_Key in
      this case.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      73aaa741
    • J
      IB/core: Handle table with full and partial membership for the same P_Key · ff7166c4
      Jack Morgenstein 提交于
      Extend the cached and non-cached P_Key table lookups to handle limited
      and full membership of the same P_Key to co-exist in the P_Key table.
      
      This is necessary for SR-IOV, to allow for some guests would to have
      the full membership P_Key in their virtual P_Key table, while other
      guests on the same physical HCA would have the limited one.
      To support this, we need both the limited and full membership P_Keys
      to be present in the master's (hypervisor physical port) P_Key table.
      
      The algorithm for handling P_Key tables which contain both the limited
      and the full membership versions of the same P_Key works as follows:
      
      When scanning the P_Key table for a 15-bit P_Key:
      
      A. If there is a full member version of that P_Key anywhere in the
          table, return its index (even if a limited-member version of the
          P_Key exists earlier in the table).
      
      B. If the full member version is not in the table, but the
         limited-member version is in the table, return the index of the
         limited P_Key.
      Signed-off-by: NLiran Liss <liranl@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      ff7166c4
  2. 24 9月, 2012 5 次提交
    • S
      edac_mc: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs. · faa2ad09
      Shaun Ruffell 提交于
      Fix potential NULL pointer dereference in edac_unregister_sysfs() on
      system boot introduced in 3.6-rc1.
      
      Since commit 7a623c03 ("edac: rewrite the sysfs code to use struct
      device") edac_mc_alloc() no longer initializes embedded kobjects in
      struct mem_ctl_info.  Therefore edac_mc_free() can no longer simply
      decrement a kobject reference count to free the allocated memory unless
      the memory controller driver module had also called edac_mc_add_mc().
      
      Now edac_mc_free() will check if the newly embedded struct device has
      been registered with sysfs before using either the standard device
      release functions or freeing the data structures itself with logic
      pulled out of the error path of edac_mc_alloc().
      
      The BUG this patch resolves for me:
      
        BUG: unable to handle kernel NULL pointer dereference at   (null)
        EIP is at __wake_up_common+0x1a/0x6a
        Process modprobe (pid: 933, ti=f3dc6000 task=f3db9520 task.ti=f3dc6000)
        Call Trace:
          complete_all+0x3f/0x50
          device_pm_remove+0x23/0xa2
          device_del+0x34/0x142
          edac_unregister_sysfs+0x3b/0x5c [edac_core]
          edac_mc_free+0x29/0x2f [edac_core]
          e7xxx_probe1+0x268/0x311 [e7xxx_edac]
          e7xxx_init_one+0x56/0x61 [e7xxx_edac]
          local_pci_probe+0x13/0x15
        ...
      
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NShaun Ruffell <sruffell@digium.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faa2ad09
    • F
      edac_mc: fix messy kfree calls in the error path · ef6e7816
      Fengguang Wu 提交于
      coccinelle warns about:
      
      + drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line 429
      
         421         if (mci->csrows) {
       > 422                 for (chn = 0; chn < tot_channels; chn++) {
         423                         csr = mci->csrows[chn];
         424                         if (csr) {
       > 425                                 for (chn = 0; chn < tot_channels; chn++)
         426                                          kfree(csr->channels[chn]);
         427                                  kfree(csr);
         428                          }
       > 429                          kfree(mci->csrows[i]);
         430                  }
         431                  kfree(mci->csrows);
         432          }
      
      and that code block seem to mess things up in several ways (double free, memory
      leak, out-of-bound reads etc.):
      
      L422: The iterator "chn" and bound "tot_channels" are totally wrong. Should be
            "row" and "tot_csrows" respectively. Which means either memory leak, or
            out-of-bound reads (which if does not trigger an immediate page fault
            error, will further lead to kfree() on random addresses).
      
      L425: The inner loop is reusing the same iterator "chn" as the outer loop,
            which could lead to premature end of the outer loop, and hence memory leak.
      
      L429: The array index 'i' in mci->csrows[i] is a temporary value used in
            previous loops, and won't change at all in the current loop. Which
            means either out-of-bound read and possibly kfree(random number), or the
            same mci->csrows[i] get freed once and again, and possibly double free
            for the kfree(csr) in L427.
      
      L426/L427: a kfree(csr->channels) is needed in between to avoid leaking the memory.
      
      The buggy code was introduced by commit de3910eb ("edac: change the mem
      allocation scheme to make Documentation/kobject.txt happy") in the 3.6-rc1
      merge window. Fix it by freeing up resources in this order:
      
        free csrows[i]->channels[j]
        free csrows[i]->channels
        free csrows[i]
        free csrows
      
      CC: Mauro Carvalho Chehab <mchehab@redhat.com>
      CC: Shaun Ruffell <sruffell@digium.com>
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef6e7816
    • A
      hwmon: (fam15h_power) Tweak runavg_range on resume · 5f0ecb90
      Andreas Herrmann 提交于
      The quirk introduced with commit
      00250ec9 (hwmon: fam15h_power: fix
      bogus values with current BIOSes) is not only required during driver
      load but also when system resumes from suspend. The BIOS might set the
      previously recommended (but unsuitable) initilization value for the
      running average range register during resume.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Tested-by: NAndreas Hartmann <andihartmann@01019freenet.de>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Cc: stable@vger.kernel.org # 3.0+
      5f0ecb90
    • S
      hwmon: (coretemp) Use get_online_cpus to avoid races involving CPU hotplug · 641f1456
      Silas Boyd-Wickizer 提交于
      coretemp_init loops with for_each_online_cpu, adding platform_devices
      and sysfs interfaces, then calls register_hotcpu_notifier.  There is a
      race if a CPU is offlined or onlined after the loop, but before
      register_hotcpu_notifier.  The race might result in the absence of a
      platform_device+sysfs interface for an online CPU, or the presence of
      a platform_device+sysfs interface for an offline CPU.  A similar race
      occurs during coretemp_exit, after the module calls
      unregister_hotcpu_notifier, but before it unregisters all devices, a
      CPU might offline and a device for an offline CPU will exist for a
      short while.
      
      This fix surrounds for_each_online_cpu and register_hotcpu_notifier
      with get_online_cpus+put_online_cpus; and surrounds
      unregister_hotcpu_notifier and device unregistering with
      get_online_cpus+put_online_cpus.
      
      Build tested.
      Signed-off-by: NSilas Boyd-Wickizer <sbw@mit.edu>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      641f1456
    • S
      hwmon: (via-cputemp) Use get_online_cpus to avoid races involving CPU hotplug · 1ec3ddfd
      Silas Boyd-Wickizer 提交于
      via_cputemp_init loops with for_each_online_cpu, adding
      platform_devices, then calls register_hotcpu_notifier.  If a CPU is
      offlined between the loop and register_hotcpu_notifier, then later
      onlined, via_cputemp_device_add will attempt to add platform devices
      with the same ID.  A similar race occurs during via_cputemp_exit,
      after the module calls unregister_hotcpu_notifier, a CPU might offline
      and a device will exist for a CPU that is offline.
      
      This fix surrounds for_each_online_cpu and register_hotcpu_notifier
      with get_online_cpus+put_online_cpus; and surrounds
      unregister_hotcpu_notifier and device unregistering with
      get_online_cpus+put_online_cpus.
      
      Build tested.
      Signed-off-by: NSilas Boyd-Wickizer <sbw@mit.edu>
      Acked-by: NHarald Welte <laforge@gnumonks.org>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      1ec3ddfd
  3. 22 9月, 2012 7 次提交
  4. 21 9月, 2012 7 次提交
    • M
      can: ti_hecc: fix oops during rmmod · ab04c8bd
      Marc Kleine-Budde 提交于
      This patch fixes an oops which occurs when unloading the driver, while the
      network interface is still up. The problem is that first the io mapping is
      teared own, then the CAN device is unregistered, resulting in accessing the
      hardware's iomem:
      
      [  172.744232] Unable to handle kernel paging request at virtual address c88b0040
      [  172.752441] pgd = c7be4000
      [  172.755645] [c88b0040] *pgd=87821811, *pte=00000000, *ppte=00000000
      [  172.762207] Internal error: Oops: 807 [#1] PREEMPT ARM
      [  172.767517] Modules linked in: ti_hecc(-) can_dev
      [  172.772430] CPU: 0    Not tainted  (3.5.0alpha-00037-g3554cc0 #126)
      [  172.778961] PC is at ti_hecc_close+0xb0/0x100 [ti_hecc]
      [  172.784423] LR is at __dev_close_many+0x90/0xc0
      [  172.789123] pc : [<bf00c768>]    lr : [<c033be58>]    psr: 60000013
      [  172.789123] sp : c5c1de68  ip : 00040081  fp : 00000000
      [  172.801025] r10: 00000001  r9 : c5c1c000  r8 : 00100100
      [  172.806457] r7 : c5d0a48c  r6 : c5d0a400  r5 : 00000000  r4 : c5d0a000
      [  172.813232] r3 : c88b0000  r2 : 00000001  r1 : c5d0a000  r0 : c5d0a000
      [  172.820037] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [  172.827423] Control: 10c5387d  Table: 87be4019  DAC: 00000015
      [  172.833404] Process rmmod (pid: 600, stack limit = 0xc5c1c2f0)
      [  172.839447] Stack: (0xc5c1de68 to 0xc5c1e000)
      [  172.843994] de60:                   bf00c6b8 c5c1dec8 c5d0a000 c5d0a000 00200200 c033be58
      [  172.852478] de80: c5c1de44 c5c1dec8 c5c1dec8 c033bf2c c5c1de90 c5c1de90 c5d0a084 c5c1de44
      [  172.860992] dea0: c5c1dec8 c033c098 c061d3dc c5d0a000 00000000 c05edf28 c05edb34 c000d724
      [  172.869476] dec0: 00000000 c033c2f8 c5d0a084 c5d0a084 00000000 c033c370 00000000 c5d0a000
      [  172.877990] dee0: c05edb00 c033c3b8 c5d0a000 bf00d3ac c05edb00 bf00d7c8 bf00d7c8 c02842dc
      [  172.886474] df00: c02842c8 c0282f90 c5c1c000 c05edb00 bf00d7c8 c0283668 bf00d7c8 00000000
      [  172.894989] df20: c0611f98 befe2f80 c000d724 c0282d10 bf00d804 00000000 00000013 c0068a8c
      [  172.903472] df40: c5c538e8 685f6974 00636365 c61571a8 c5cb9980 c61571a8 c6158a20 c00c9bc4
      [  172.911987] df60: 00000000 00000000 c5cb9980 00000000 c5cb9980 00000000 c7823680 00000006
      [  172.920471] df80: bf00d804 00000880 c5c1df8c 00000000 000d4267 befe2f80 00000001 b6d90068
      [  172.928985] dfa0: 00000081 c000d5a0 befe2f80 00000001 befe2f80 00000880 b6d90008 00000008
      [  172.937469] dfc0: befe2f80 00000001 b6d90068 00000081 00000001 00000000 befe2eac 00000000
      [  172.945983] dfe0: 00000000 befe2b18 00023ba4 b6e6addc 60000010 befe2f80 a8e00190 86d2d344
      [  172.954498] [<bf00c768>] (ti_hecc_close+0xb0/0x100 [ti_hecc]) from [<c033be58>] (__dev__registered_many+0xc0/0x2a0)
      [  172.984161] [<c033c098>] (rollback_registered_many+0xc0/0x2a0) from [<c033c2f8>] (rollback_registered+0x20/0x30)
      [  172.994750] [<c033c2f8>] (rollback_registered+0x20/0x30) from [<c033c370>] (unregister_netdevice_queue+0x68/0x98)
      [  173.005401] [<c033c370>] (unregister_netdevice_queue+0x68/0x98) from [<c033c3b8>] (unregister_netdev+0x18/0x20)
      [  173.015899] [<c033c3b8>] (unregister_netdev+0x18/0x20) from [<bf00d3ac>] (ti_hecc_remove+0x60/0x80 [ti_hecc])
      [  173.026245] [<bf00d3ac>] (ti_hecc_remove+0x60/0x80 [ti_hecc]) from [<c02842dc>] (platform_drv_remove+0x14/0x18)
      [  173.036712] [<c02842dc>] (platform_drv_remove+0x14/0x18) from [<c0282f90>] (__device_release_driver+0x7c/0xbc)
      
      Cc: stable <stable@vger.kernel.org>
      Cc: Anant Gole <anantgole@ti.com>
      Tested-by: NJan Luebbe <jlu@pengutronix.de>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      ab04c8bd
    • I
      can: janz-ican3: fix support for older hardware revisions · e21093ef
      Ira W. Snyder 提交于
      The Revision 1.0 Janz CMOD-IO Carrier Board does not have support for
      the reset registers. To support older hardware, the code is changed to
      use the hardware reset register on the Janz VMOD-ICAN3 hardware itself.
      
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      e21093ef
    • D
      drm/nouveau: add dmi quirk for gpio reset · 6c06d608
      Dave Airlie 提交于
      This fixes the gpio reset problem so the Retina MBP works, but avoids
      breaking the Dell systems. Ben will work on a better solution for 3.7.
      
      Tested by me on retina MBP.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6c06d608
    • E
      aoe: assert AoE packets marked as requiring no checksum · 8babe8cc
      Ed Cashin 提交于
      In order for the network layer to see that AoE requires
      no checksumming in a generic way, the packets must be
      marked as requiring no checksum, so we make this requirement
      explicit with the assertion.
      Signed-off-by: NEd Cashin <ecashin@coraid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8babe8cc
    • D
      at91ether: return PTR_ERR if call to clk_get fails · 3cfc1590
      Devendra Naga 提交于
      we are currently returning ENODEV, as the clk_get may give a exact
      error code in its returned pointer, assign it to the ret by using the
      PTR_ERR function, so that the subsequent goto label will jump to the
      error path and clean the driver and return the error correctly.
      Signed-off-by: NDevendra Naga <devendra.aaru@gmail.com>
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3cfc1590
    • B
      net: qmi_wwan: adding Huawei E367, ZTE MF683 and Pantech P4200 · 9db273f4
      Bjørn Mork 提交于
      One of the modes of Huawei E367 has this QMI/wwan interface:
      
       I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=07 Driver=(none)
       E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
       E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
       E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
      
      Huawei use subclass and protocol to identify vendor specific
      functions, so adding a new vendor rule for this combination.
      
      The Pantech devices UML290 (106c:3718) and P4200 (106c:3721) use
      the same subclass to identify the QMI/wwan function.  Replace the
      existing device specific UML290 entries with generic vendor matching,
      adding support for the Pantech P4200.
      
      The ZTE MF683 has 6 vendor specific interfaces, all using
      ff/ff/ff for cls/sub/prot.  Adding a match on interface #5 which
      is a QMI/wwan interface.
      
      Cc: Fangxiaozhi (Franko) <fangxiaozhi@huawei.com>
      Cc: Thomas Schäfer <tschaefer@t-online.de>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Shawn J. Goff <shawn7400@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9db273f4
    • S
      drm/radeon: Prevent leak of scratch register on resume from suspend · 16c58081
      Simon Kitching 提交于
      Cards typically have 5-7 scratch registers; one of these is reserved for
      rdev->rptr_save_reg. Unfortunately the reservation is done in function
      r100_cp_init, which is called by all drivers except r600 - and this
      function is also invoked on resume from suspend. After several resumes,
      no scratch registers are free and graphics acceleration is disabled.
      
      Dmesg then reports either:
         *ERROR* radeon: cp failed to get scratch reg (-22).
         *ERROR* radeon: cp isn't working(-22).
         radeon 0000:01:00.0: failed initializing CP (-22).
      or:
         *ERROR* radeon: failed to get scratch reg (-22).
         *ERROR* radeon: failed testing IB on GFX ring (-22).
         *ERROR* ib ring test failed (-22).
      
      The chain of calls on boot for all except r600 is:
      radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init
      
      The chain of calls on resume for all except r600 is:
      rXXX_resume -> rXXX_startup -> r100_cp_init.
      
      R600 correctly allocates rptr_save_reg in r600_init (ie once only, not
      in resume). However moving the code into the init functions for all
      drivers means touching 4 drivers. So instead, this patch just adds a
      test in r100_cp_init to avoid reallocating on resume. As the rdev
      structure is allocated via kzalloc in radeon_driver_load_kms, and zero
      is not a valid registerid, zero safely implies not-yet-allocated.
      
      This issue appears to have been introduced in c7eff978 (3.6.0-rcN)
      Signed-off-by: NSimon Kitching <skitching@vonos.net>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      16c58081
  5. 20 9月, 2012 9 次提交
  6. 19 9月, 2012 8 次提交
  7. 18 9月, 2012 1 次提交
    • S
      [SCSI] hpsa: fix handling of protocol error · 256d0eaa
      Stephen M. Cameron 提交于
      If a command status of CMD_PROTOCOL_ERR is received, this
      information should be conveyed to the SCSI mid layer, not
      dropped on the floor.  CMD_PROTOCOL_ERR may be received
      from the Smart Array for any commands destined for an external
      RAID controller such as a P2000, or commands destined for tape
      drives or CD/DVD-ROM drives, if for instance a cable is
      disconnected.  This mostly affects multipath configurations, as
      disconnecting a cable on a non-multipath configuration is not
      going to do anything good regardless of whether CMD_PROTOCOL_ERR
      is handled correctly or not.  Not handling CMD_PROTOCOL_ERR
      correctly in a multipath configaration involving external RAID
      controllers may cause data corruption, so this is quite a serious
      bug.  This bug should not normally cause a problem for direct
      attached disk storage.
      Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      256d0eaa