1. 06 4月, 2013 2 次提交
  2. 05 4月, 2013 6 次提交
  3. 04 4月, 2013 3 次提交
  4. 03 4月, 2013 6 次提交
  5. 02 4月, 2013 16 次提交
    • A
      cpuidle / ACPI: recover percpu ACPI processor cstate · 6240a10d
      Alex Shi 提交于
      Commit ac3ebafa "ACPI / idle: remove usage of the statedata"
      changed the percpu processor cstate to a unified cstate in ACPI idle.
      That caused all our NHM boxes to boot hang or panic.
      
      2178751 Task dump for CPU 1:
      	2178752 swapper/1       R  running task     6736     0      1 0x00000000
      	2178753  ffff8801e8029dc8 ffffffff8101cf96 ffff8801e8029e28 ffffffff813d294b
      	2178754  0000000000000f99 0000000000000003 00000000003cf654 0000000025c17d03
      	2178755  ffff8801e8029e38 ffff8801e74fc000 00000002590dc5c4 ffffffff8163cdb0
      	2178756 Call Trace:
      	2178757  [<ffffffff8101cf96>] ? acpi_processor_ffh_cstate_enter+0x2d/0x2f
      	2178758  [<ffffffff813d294b>] acpi_idle_enter_bm+0x1b1/0x236
      	2178759  [<ffffffff8163cdb0>] ? disable_cpuidle+0x10/0x10
      	2178760  [<ffffffff8163cdc2>] cpuidle_enter+0x12/0x14
      	2178761  [<ffffffff8163d286>] cpuidle_wrap_enter+0x2f/0x6d
      	2178762  [<ffffffff8163d2d4>] cpuidle_enter_tk+0x10/0x12
      	2178763  [<ffffffff8163cdd6>] cpuidle_enter_state+0x12/0x3a
      	2178764  [<ffffffff8163d4a7>] cpuidle_idle_call+0xe8/0x161
      	2178765  [<ffffffff81008d99>] cpu_idle+0x5e/0xa4
      	2178766  [<ffffffff8174c6c1>] start_secondary+0x1a9/0x1ad
      	2178767 Task dump for CPU 2:
      
      In fact, the ACPI idle is based on the assumption of difference percpu
      cstate structures that are necessary for the implementation to work
      cprrectly.  A unique acpi_processor_cx is not sifficient by far.
      
      This patch is just a quick fix re-introducing the percpu cstates.
      
      If someone really wants to unify the ACPI cstates, please make sure
      that the whole software infrastructure is changed and take hardware
      as well as many different kinds of BIOS settings into account.
      
      [rjw: Changelog]
      Reported-by: NLKP project <lkp@linux.intel.com>
      Reported-by: NXie ChanglongX <changlongx.xie@intel.com>
      Tested-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NAlex Shi <alex.shi@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6240a10d
    • R
      ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices() · b34bb1ee
      Rafael J. Wysocki 提交于
      The ACPI handle of struct i2c_adapter's dev member should not be
      set, because this causes that struct i2c_adapter to be associated
      with the ACPI device node corresponding to its parent as the
      second "physical_device", which is incorrect (this happens during
      the registration of struct i2c_adapter).  Consequently,
      acpi_i2c_register_devices() should use the ACPI handle of the
      parent of the struct i2c_adapter it is called for rather than the
      struct i2c_adapter's ACPI handle (which should be NULL).
      
      Make that happen and modify the i2c-designware-platdrv driver,
      which currently is the only driver for ACPI-enumerated I2C
      controller chips, not to set the ACPI handle for the
      struct i2c_adapter it creates.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NWolfram Sang <wsa@the-dreams.de>
      b34bb1ee
    • B
      cpufreq: Correct header guards typo · beb0ff39
      Borislav Petkov 提交于
      It should be "governor".
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      beb0ff39
    • W
      video:uvesafb: Fix dereference NULL pointer code path · 090da752
      Wang YanQing 提交于
      platform_device_alloc could failed and return NULL,
      we should check this before call platform_device_put.
      Signed-off-by: NWang YanQing <udknight@gmail.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      090da752
    • J
      fbmon: use VESA_DMT_VSYNC_HIGH to fix typo · 477fc03f
      Jingoo Han 提交于
      VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
      because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Acked-by: NSteffen Trumtrar <s.trumtrar@pengutronix.de>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      477fc03f
    • R
      ACPI / SPI: Use parent's ACPI_HANDLE() in acpi_register_spi_devices() · 29896178
      Rafael J. Wysocki 提交于
      The ACPI handle of struct spi_master's dev member should not be
      set, because this causes that struct spi_master to be associated
      with the ACPI device node corresponding to its parent as the
      second "physical_device", which is incorrect (this happens during
      the registration of struct spi_master).  Consequently,
      acpi_register_spi_devices() should use the ACPI handle of the
      parent of the struct spi_master it is called for rather than that
      struct spi_master's ACPI handle (which should be NULL).
      
      Make that happen and modify the spi-pxa2xx driver, which currently is
      the only driver for ACPI-enumerated SPI controller chips, not to set
      the ACPI handle for the struct spi_master it creates.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      29896178
    • P
      cpufreq: check OF node /cpus presence before dereferencing it · f5c3ef21
      Paolo Pisati 提交于
      Check for the presence of the '/cpus' OF node before dereferencing it
      blindly:
      
      [    4.181793] Unable to handle kernel NULL pointer dereference at virtual address 0000001c
      [    4.181793] pgd = c0004000
      [    4.181823] [0000001c] *pgd=00000000
      [    4.181823] Internal error: Oops: 5 [#1] SMP ARM
      [    4.181823] Modules linked in:
      [    4.181823] CPU: 1    Tainted: G        W     (3.8.0-15-generic #25~hbankD)
      [    4.181854] PC is at of_get_next_child+0x64/0x70
      [    4.181854] LR is at of_get_next_child+0x24/0x70
      [    4.181854] pc : [<c04fda18>]    lr : [<c04fd9d8>]    psr: 60000113
      [    4.181854] sp : ed891ec0  ip : ed891ec0  fp : ed891ed4
      [    4.181884] r10: c04dafd0  r9 : c098690c  r8 : c0936208
      [    4.181884] r7 : ed890000  r6 : c0a63d00  r5 : 00000000  r4 : 00000000
      [    4.181884] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : c0b2acc8
      [    4.181884] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [    4.181884] Control: 10c5387d  Table: adcb804a  DAC: 00000015
      [    4.181915] Process swapper/0 (pid: 1, stack limit = 0xed890238)
      [    4.181915] Stack: (0xed891ec0 to 0xed892000)
      [    4.181915] 1ec0: c09b7b70 00000007 ed891efc ed891ed8 c04daff4 c04fd9c0 00000000 c09b7b70
      [    4.181915] 1ee0: 00000007 c0a63d00 ed890000 c0936208 ed891f54 ed891f00 c00088e0 c04dafdc
      [    4.181945] 1f00: ed891f54 ed891f10 c006e940 00000000 00000000 00000007 00000007 c08a4914
      [    4.181945] 1f20: 00000000 c07dbd30 c0a63d00 c09b7b70 00000007 c0a63d00 000000bc c0936208
      [    4.181945] 1f40: c098690c c0986914 ed891f94 ed891f58 c0936a40 c00087bc 00000007 00000007
      [    4.181976] 1f60: c0936208 be8bda20 b6eea010 c0a63d00 c064547c 00000000 00000000 00000000
      [    4.181976] 1f80: 00000000 00000000 ed891fac ed891f98 c0645498 c09368c8 00000000 00000000
      [    4.181976] 1fa0: 00000000 ed891fb0 c0014658 c0645488 00000000 00000000 00000000 00000000
      [    4.182006] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    4.182006] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [    4.182037] [<c04fda18>] (of_get_next_child+0x64/0x70) from [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284)
      [    4.182067] [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) from [<c00088e0>] (do_one_initcall+0x130/0x1b0)
      [    4.182067] [<c00088e0>] (do_one_initcall+0x130/0x1b0) from [<c0936a40>] (kernel_init_freeable+0x184/0x24c)
      [    4.182098] [<c0936a40>] (kernel_init_freeable+0x184/0x24c) from [<c0645498>] (kernel_init+0x1c/0xf4)
      [    4.182128] [<c0645498>] (kernel_init+0x1c/0xf4) from [<c0014658>] (ret_from_fork+0x14/0x20)
      [    4.182128] Code: f57ff04f e320f004 e89da830 e89da830 (e595001c)
      [    4.182128] ---[ end trace 634903a22e8609cb ]---
      [    4.182189] Kernel panic - not syncing: Attempted to kill init!  exitcode=0x0000000b
      [    4.182189]
      [    4.642395] CPU0: stopping
      
      [rjw: Changelog]
      Signed-off-by: NPaolo Pisati <paolo.pisati@canonical.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f5c3ef21
    • R
      PM / QoS: Avoid possible deadlock related to sysfs access · 0f703069
      Rafael J. Wysocki 提交于
      Commit b81ea1b5 (PM / QoS: Fix concurrency issues and memory leaks in
      device PM QoS) put calls to pm_qos_sysfs_add_latency(),
      pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
      pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a
      mistake, because it may lead to deadlocks in some situations.
      For example, if pm_qos_remote_wakeup_store() is run in parallel
      with dev_pm_qos_constraints_destroy(), they may deadlock in the
      following way:
      
       ======================================================
       [ INFO: possible circular locking dependency detected ]
       3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: G        W
       -------------------------------------------------------
       trinity-child6/12371 is trying to acquire lock:
        (s_active#54){++++.+}, at: [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60
      
       but task is already holding lock:
        (dev_pm_qos_mtx){+.+.+.}, at: [<ffffffff81f07cc3>] dev_pm_qos_constraints_destroy+0x23/0x250
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (dev_pm_qos_mtx){+.+.+.}:
              [<ffffffff811811da>] lock_acquire+0x1aa/0x240
              [<ffffffff83dab809>] __mutex_lock_common+0x59/0x5e0
              [<ffffffff83dabebf>] mutex_lock_nested+0x3f/0x50
              [<ffffffff81f07f2f>] dev_pm_qos_update_flags+0x3f/0xc0
              [<ffffffff81f05f4f>] pm_qos_remote_wakeup_store+0x3f/0x70
              [<ffffffff81efbb43>] dev_attr_store+0x13/0x20
              [<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150
              [<ffffffff8127f2c1>] __kernel_write+0x81/0x150
              [<ffffffff812afc2d>] write_pipe_buf+0x4d/0x80
              [<ffffffff812af57c>] splice_from_pipe_feed+0x7c/0x120
              [<ffffffff812afa25>] __splice_from_pipe+0x45/0x80
              [<ffffffff812b14fc>] splice_from_pipe+0x4c/0x70
              [<ffffffff812b1538>] default_file_splice_write+0x18/0x30
              [<ffffffff812afae3>] do_splice_from+0x83/0xb0
              [<ffffffff812afb2e>] direct_splice_actor+0x1e/0x20
              [<ffffffff812b0277>] splice_direct_to_actor+0xe7/0x200
              [<ffffffff812b15bc>] do_splice_direct+0x4c/0x70
              [<ffffffff8127eda9>] do_sendfile+0x169/0x300
              [<ffffffff8127ff94>] SyS_sendfile64+0x64/0xb0
              [<ffffffff83db7d18>] tracesys+0xe1/0xe6
      
       -> #0 (s_active#54){++++.+}:
              [<ffffffff811800cf>] __lock_acquire+0x15bf/0x1e50
              [<ffffffff811811da>] lock_acquire+0x1aa/0x240
              [<ffffffff81300aa2>] sysfs_deactivate+0x122/0x1a0
              [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60
              [<ffffffff812ff77f>] sysfs_hash_and_remove+0x7f/0xb0
              [<ffffffff813035a1>] sysfs_unmerge_group+0x51/0x70
              [<ffffffff81f068f4>] pm_qos_sysfs_remove_flags+0x14/0x20
              [<ffffffff81f07490>] __dev_pm_qos_hide_flags+0x30/0x70
              [<ffffffff81f07cd5>] dev_pm_qos_constraints_destroy+0x35/0x250
              [<ffffffff81f06931>] dpm_sysfs_remove+0x11/0x50
              [<ffffffff81efcf6f>] device_del+0x3f/0x1b0
              [<ffffffff81efd128>] device_unregister+0x48/0x60
              [<ffffffff82d4083c>] usb_hub_remove_port_device+0x1c/0x20
              [<ffffffff82d2a9cd>] hub_disconnect+0xdd/0x160
              [<ffffffff82d36ab7>] usb_unbind_interface+0x67/0x170
              [<ffffffff81f001a7>] __device_release_driver+0x87/0xe0
              [<ffffffff81f00559>] device_release_driver+0x29/0x40
              [<ffffffff81effc58>] bus_remove_device+0x148/0x160
              [<ffffffff81efd07f>] device_del+0x14f/0x1b0
              [<ffffffff82d344f9>] usb_disable_device+0xf9/0x280
              [<ffffffff82d34ff8>] usb_set_configuration+0x268/0x840
              [<ffffffff82d3a7fc>] usb_remove_store+0x4c/0x80
              [<ffffffff81efbb43>] dev_attr_store+0x13/0x20
              [<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150
              [<ffffffff8127f71d>] do_loop_readv_writev+0x4d/0x90
              [<ffffffff8127f999>] do_readv_writev+0xf9/0x1e0
              [<ffffffff8127faba>] vfs_writev+0x3a/0x60
              [<ffffffff8127fc60>] SyS_writev+0x50/0xd0
              [<ffffffff83db7d18>] tracesys+0xe1/0xe6
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(dev_pm_qos_mtx);
                                      lock(s_active#54);
                                      lock(dev_pm_qos_mtx);
         lock(s_active#54);
      
        *** DEADLOCK ***
      
      To avoid that, remove the calls to functions mentioned above from
      under dev_pm_qos_mtx and introduce a separate lock to prevent races
      between functions that add or remove device PM QoS sysfs attributes
      from happening.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0f703069
    • R
      USB / PM: Don't try to hide PM QoS flags from usb_port_device_release() · da259465
      Rafael J. Wysocki 提交于
      Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
      "usb: Add driver/usb/core/(port.c,hub.h) files", from
      usb_port_device_release(), because (1) it is completely unnecessary
      (the flags have been removed already by the PM core during the
      unregistration of the device object) and (2) it triggers a NULL
      pointer dereference in sysfs_find_dirent() (dev->kobj.sd is NULL at
      this point).
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da259465
    • A
      loop: prevent bdev freeing while device in use · c1681bf8
      Anatol Pomozov 提交于
      struct block_device lifecycle is defined by its inode (see fs/block_dev.c) -
      block_device allocated first time we access /dev/loopXX and deallocated on
      bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile"
      we want that block_device stay alive until we destroy the loop device
      with "losetup -d".
      
      But because we do not hold /dev/loopXX inode its counter goes 0, and
      inode/bdev can be destroyed at any moment. Usually it happens at memory
      pressure or when user drops inode cache (like in the test below). When later in
      loop_clr_fd() we want to use bdev we have use-after-free error with following
      stack:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
        bd_set_size+0x10/0xa0
        loop_clr_fd+0x1f8/0x420 [loop]
        lo_ioctl+0x200/0x7e0 [loop]
        lo_compat_ioctl+0x47/0xe0 [loop]
        compat_blkdev_ioctl+0x341/0x1290
        do_filp_open+0x42/0xa0
        compat_sys_ioctl+0xc1/0xf20
        do_sys_open+0x16e/0x1d0
        sysenter_dispatch+0x7/0x1a
      
      To prevent use-after-free we need to grab the device in loop_set_fd()
      and put it later in loop_clr_fd().
      
      The issue is reprodusible on current Linus head and v3.3. Here is the test:
      
        dd if=/dev/zero of=loop.file bs=1M count=1
        while [ true ]; do
          losetup /dev/loop0 loop.file
          echo 2 > /proc/sys/vm/drop_caches
          losetup -d /dev/loop0
        done
      
      [ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every
        time we call loop_set_fd() we check that loop_device->lo_state is
        Lo_unbound and set it to Lo_bound If somebody will try to set_fd again
        it will get EBUSY.  And if we try to loop_clr_fd() on unbound loop
        device we'll get ENXIO.
      
        loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
        loop_device->lo_ctl_mutex. ]
      Signed-off-by: NAnatol Pomozov <anatol.pomozov@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c1681bf8
    • M
      radeon: Attempt to use platform-provided ROM image · 06a08570
      Matthew Garrett 提交于
      Some platforms only provide their PCI ROM via a platform-specific interface.
      Fall back to attempting that if all other sources fail.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      06a08570
    • M
      nouveau: Attempt to use platform-provided ROM image · 121cdf08
      Matthew Garrett 提交于
      Some platforms only provide their PCI ROM via a platform-specific interface.
      Fall back to attempting that if all other sources fail.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      121cdf08
    • S
      mwifiex: limit channel number not to overflow memory · 901ceba4
      Stone Piao 提交于
      Limit the channel number in scan request, or the driver scan
      config structure memory will be overflowed.
      
      Cc: <stable@vger.kernel.org> # 3.5+
      Signed-off-by: NStone Piao <piaoyun@marvell.com>
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      901ceba4
    • T
      clk: tegra: Allow PLLE training to succeed · 0f1bc12e
      Thierry Reding 提交于
      Under some circumstances the PLLE needs to be retrained, in which case
      access to the PMC registers is required. Fix this by passing a pointer
      to the PMC registers instead of NULL when registering the PLLE clock.
      Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
      Acked-By: NPeter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: NMike Turquette <mturquette@linaro.org>
      0f1bc12e
    • Y
      EISA/PCI: Init EISA early, before PNP · c5fb301a
      Yinghai Lu 提交于
      Matthew reported kernels fail the pci_eisa probe and are later successful
      with the virtual_eisa_root_init force probe without slot0.
      
      The reason for that is: PNP probing is before pci_eisa_init gets called
      as pci_eisa_init is called via pci_driver.
      
      pnp 00:0f has 0xc80 - 0xc84 reserved.
      [    9.700409] pnp 00:0f: [io  0x0c80-0x0c84]
      
      so eisa_probe will fail from pci_eisa_init
      				==>eisa_root_register
      					==>eisa_probe path.
      as force_probe is not set in pci_eisa_root, it will bail early when
      slot0 is not probed and initialized.
      
      Try to use subsys_initcall_sync instead, and will keep following sequence:
      	pci_subsys_init
      	pci_eisa_init_early
      	pnpacpi_init/isapnp_init
      
      After this patch EISA can be initialized properly, and PNP overlapping
      resource will not be reserved.
      [   10.104434] system 00:0f: [io  0x0c80-0x0c84] could not be reserved
      Reported-by: NMatthew Whitehead <mwhitehe@redhat.com>
      Tested-by: NMatthew Whitehead <mwhitehe@redhat.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org
      c5fb301a
    • Y
      EISA/PCI: Fix bus res reference · 2cfda637
      Yinghai Lu 提交于
      Matthew found that 3.8.3 is having problems with an old (ancient)
      PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel.
      He identified the 82375, but doesn't assign the struct resource *res
      pointer inside the struct eisa_root_device, and panics.
      
      pci_eisa_init() was using bus->resource[] directly instead of
      pci_bus_resource_n().  The bus->resource[] array is a PCI-internal
      implementation detail, and after commit 45ca9e97 (PCI: add helpers for
      building PCI bus resource lists) and commit 0efd5aab (PCI: add struct
      pci_host_bridge_window with CPU/bus address offset), bus->resource[] is not
      used for PCI root buses any more.
      
      The 82375 is a subtractive-decode PCI device, so handle it the same
      way we handle PCI-PCI bridges in subtractive-decode mode in
      pci_read_bridge_bases().
      
      [bhelgaas: changelog]
      Reported-by: NMatthew Whitehead <mwhitehe@redhat.com>
      Tested-by: NMatthew Whitehead <mwhitehe@redhat.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org	# v3.3+
      2cfda637
  6. 01 4月, 2013 7 次提交
    • A
      spi/mpc512x-psc: optionally keep PSC SS asserted across xfer segmensts · 1ad849ae
      Anatolij Gustschin 提交于
      Some SPI slave devices require asserted chip select signal across
      multiple transfer segments of an SPI message. Currently the driver
      always de-asserts the internal SS signal for every single transfer
      segment of the message and ignores the 'cs_change' flag of the
      transfer description. Disable the internal chip select (SS) only
      if this is needed and indicated by the 'cs_change' flag.
      
      Without this change, each partial transfer of a surrounding
      multi-part SPI transaction might erroneously change the SS
      signal, which might prevent slaves from answering the request
      that was sent in a previous transfer segment because the
      transaction could be considered aborted (SS was de-asserted
      before reading the response).
      Reported-by: NGerhard Sittig <gerhard.sittig@ifm.com>
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@vger.kernel.org
      1ad849ae
    • B
      spi: Unlock a spinlock before calling into the controller driver. · b0b36b86
      Bryan Freed 提交于
      spi_pump_messages() calls into a controller driver with
      unprepare_transfer_hardware() which is documented as "This may sleep".
      As in the prepare_transfer_hardware() call below, we should release the
      queue_lock spinlock before making the call.
      Rework the logic a bit to hold queue_lock to protect the 'busy' flag,
      then release it to call unprepare_transfer_hardware().
      Signed-off-by: NBryan Freed <bfreed@chromium.org>
      Reviewed-by: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      b0b36b86
    • G
      spi/s3c64xx: modified error interrupt handling and init · 375981f2
      Girish K S 提交于
      The status of the interrupt is available in the status register,
      so reading the clear pending register and writing back the same
      value will not actually clear the pending interrupts. This patch
      modifies the interrupt handler to read the status register and
      clear the corresponding pending bit in the clear pending register.
      
      Modified the hwInit function to clear all the pending interrupts.
      Signed-off-by: NGirish K S <ks.giri@samsung.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@vger.kernel.org
      375981f2
    • J
      DM9000B: driver initialization upgrade · 6741f40d
      Joseph CHANG 提交于
      Fix bug for DM9000 revision B which contain a DSP PHY
      
      DM9000B use DSP PHY instead previouse DM9000 revisions' analog PHY,
      So need extra change in initialization, For
      explicity PHY Reset and PHY init parameter, and
      first DM9000_NCR reset need NCR_MAC_LBK bit by dm9000_probe().
      
      Following DM9000_NCR reset cause by dm9000_open() clear the
      NCR_MAC_LBK bit.
      
      Without this fix, Power-up FIFO pointers error happen around 2%
      rate among Davicom's customers' boards. With this fix, All above
      cases can be solved.
      Signed-off-by: NJoseph CHANG <josright123@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6741f40d
    • S
      sh_eth: make 'link' field of 'struct sh_eth_private' *int* · 3340d2aa
      Sergei Shtylyov 提交于
      The 'link' field of 'struct sh_eth_private' has type 'enum phy_state' while the
      'link' field of 'struct phy_device' is merely *int* (having values 0 and 1) and
      the former field gets assigned from the latter. Make the field match, getting
      rid of incorrectly used PHY_DOWN value in assignments/comparisons.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3340d2aa
    • S
      sh_eth: workaround for spurious ECI interrupt · 3893b273
      Sergei Shtylyov 提交于
      At least on Renesas R8A7778, EESR.ECI interrupt seems to fire regardless of its
      mask in EESIPR register. I can 100% reproduce it with the following scenario:
      target is booted with 'ip=on' option, and so IP-Config opens SoC Ether device
      but doesn't get a proper reply and then succeeds with on-board SMC chip; then
      I login and try to bring up the SoC Ether device with 'ifconfig', and I get
      an ECI interrupt once request_irq() is called by sh_eth_open() (while interrupt
      mask in EESIPR register is all 0), if that interrupt is accompanied by a pending
      EESR.FRC (frame receive completion) interrupt, I get kernel oops in sh_eth_rx()
      because sh_eth_ring_init() hasn't been called yet!
      
      The solution I worked out is the following: in sh_eth_interrupt(), mask the
      interrupt status from EESR register with the interrupt mask from EESIPR register
      in order not to handle the disabled interrupts -- but forcing EESIPR.M_ECI bit
      in this mask set because we always need to fully handle EESR.ECI interrupt in
      sh_eth_error() in order to quench it (as it doesn't get cleared by just writing
      1 to the this bit as all the other interrupts).
      
      While at it, remove unneeded initializer for 'intr_status' variable and give it
      *unsigned long* type, matching the type of sh_eth_read()'s result; fix comment.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reviewed-by: NMax Filippov <max.filippov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3893b273
    • S
      sh_eth: fix handling of no LINK signal · 1e1b812b
      Sergei Shtylyov 提交于
      The code handling the absent LINK signal (or the absent PSR register -- which
      reflects the state of this signal) is quite naive and has probably never really
      worked.  It's probably enough to say that this code is executed only on the LINK
      change interrupt (sic!) but even if we actually have the signal and choose to
      ignore it (it might be connected to PHY's link/activity LED output as on the
      Renesas BOCK-W board), sh_eth_adjust_link() on which this code relies to update
      'mdp->link' gets executed later than the LINK change interrupt where it is
      checked, and so RX/TX never get enabled via ECMR register.
      
      So, ignore the LINK changed interrupt iff LINK signal is absent (or just chosen
      not to be used) or PSR register is absent, and enable/disable RX/TX directly in
      sh_eth_adjust_link() in this case.
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e1b812b