1. 06 3月, 2012 2 次提交
  2. 03 3月, 2012 2 次提交
    • N
      hwmon: (f75375s) Catch some attempts to write to r/o registers · 15d1ad0c
      Nikolaus Schulz 提交于
      It makes no sense to attempt to manually configure the fan in auto mode,
      or set the duty cycle directly in closed loop mode.  The corresponding
      registers are then read-only.  If the user tries it nonetheless, error out
      with EINVAL instead of silently doing nothing.
      Signed-off-by: NNikolaus Schulz <mail@microschulz.de>
      [guenter.roeck@ericsson.com: Minor formatting cleanup]
      Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
      15d1ad0c
    • N
      hwmon: (f75375s) Properly map the F75387 automatic modes to pwm_enable · b17d6561
      Nikolaus Schulz 提交于
      The F75387 supports automatic fan control using either PWM duty cycle or
      RPM speed values.  Make the driver detect the latter mode, and expose the
      different modes in sysfs as per pwm_enable, so that the user can switch
      between them.
      
      The interpretation of the pwm_enable attribute for the F75387 is adjusted
      to be a superset of those values used for similar Fintek chips which do
      not support automatic duty mode, with 2 mapping to automatic speed mode,
      and moving automatic duty mode to the new value 4.
      
      Toggling the duty mode via pwm_enable is currently denied for the F75387,
      as the chip then simply reinterprets the fan configuration register values
      according to the new mode, switching between RPM and PWM units, which
      makes this a dangerous operation.
      
      This patch introduces a new pwm mode into the driver. This is necessary
      because the new mode (automatic pwm mode, 4) may already be enabled by the
      BIOS, and the driver should not break existing functionality. This was seen
      on at least one board.
      Signed-off-by: NNikolaus Schulz <mail@microschulz.de>
      Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
      b17d6561
  3. 01 3月, 2012 4 次提交
  4. 29 2月, 2012 9 次提交
  5. 28 2月, 2012 2 次提交
    • P
      crypto: mv_cesa - fix final callback not ignoring input data · f8f54e19
      Phil Sutter 提交于
      Broken by commit 6ef84509 for users
      passing a request with non-zero 'nbytes' field, like e.g. testmgr.
      
      Cc: <stable@kernel.org> # 3.0+
      Signed-off-by: NPhil Sutter <phil.sutter@viprinet.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f8f54e19
    • C
      drm/i915: Remove use of the autoreported ringbuffer HEAD position · 5d031e5b
      Chris Wilson 提交于
      This is a revert of 6aa56062.
      
      This was originally introduced to workaround reads of the ringbuffer
      registers returning 0 on SandyBridge causing hangs due to ringbuffer
      overflow. The root cause here was reads through the GT powerwell require
      the forcewake dance, something we only learnt of later. Now it appears
      that reading the reported head position from the HWS is returning
      garbage, leading once again to hangs.
      
      For example, on q35 the autoreported head reports:
        [  217.975608] head now 00010000, actual 00010000
        [  436.725613] head now 00200000, actual 00200000
        [  462.956033] head now 00210000, actual 00210010
        [  485.501409] head now 00400000, actual 00400020
        [  508.064280] head now 00410000, actual 00410000
        [  530.576078] head now 00600000, actual 00600020
        [  553.273489] head now 00610000, actual 00610018
      which appears reasonably sane. In contrast, if we look at snb:
        [  141.970680] head now 00e10000, actual 00008238
        [  141.974062] head now 02734000, actual 000083c8
        [  141.974425] head now 00e10000, actual 00008488
        [  141.980374] head now 032b5000, actual 000088b8
        [  141.980885] head now 03271000, actual 00008950
        [  142.040628] head now 02101000, actual 00008b40
        [  142.180173] head now 02734000, actual 00009050
        [  142.181090] head now 00000000, actual 00000ae0
        [  142.183737] head now 02734000, actual 00009050
      
      In addition, the automatic reporting of the head position is scheduled
      to be defeatured in the future. It has no more utility, remove it.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45492Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      5d031e5b
  6. 27 2月, 2012 3 次提交
  7. 25 2月, 2012 8 次提交
  8. 24 2月, 2012 10 次提交
    • J
      regulator: fix the ldo configure according to 88pm860x spec · 3380643b
      Jett.Zhou 提交于
      Signed-off-by: NJett.Zhou <jtzhou@marvell.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@vger.kernel.org
      3380643b
    • O
      iommu/omap: fix NULL pointer dereference · 87997aaa
      Ohad Ben-Cohen 提交于
      Fix this:
      
      root@omap4430-panda:~# cat /debug/iommu/ducati/mem
      [   62.725708] Unable to handle kernel NULL pointer dereference at virtual addre
      ss 0000001c
      [   62.725708] pgd = e6240000
      [   62.737091] [0000001c] *pgd=a7168831, *pte=00000000, *ppte=00000000
      [   62.743682] Internal error: Oops: 17 [#1] SMP
      [   62.743682] Modules linked in: omap_iommu_debug omap_iovmm virtio_rpmsg_bus o
      map_remoteproc remoteproc virtio_ring virtio mailbox_mach mailbox
      [   62.743682] CPU: 0    Not tainted  (3.3.0-rc1-00265-g382f84e-dirty #682)
      [   62.743682] PC is at debug_read_mem+0x5c/0xac [omap_iommu_debug]
      [   62.743682] LR is at 0x1004
      [   62.777832] pc : [<bf033178>]    lr : [<00001004>]    psr: 60000013
      [   62.777832] sp : e72c7f40  ip : c0763c00  fp : 00000001
      [   62.777832] r10: 00000000  r9 : 00000000  r8 : e72c7f80
      [   62.777832] r7 : e6ffdc08  r6 : bed1ac78  r5 : 00001000  r4 : e7276000
      [   62.777832] r3 : e60f3460  r2 : 00000000  r1 : e60f38c0  r0 : 00000000
      [   62.777832] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   62.816375] Control: 10c53c7d  Table: a624004a  DAC: 00000015
      [   62.816375] Process cat (pid: 1176, stack limit = 0xe72c62f8)
      [   62.828369] Stack: (0xe72c7f40 to 0xe72c8000)
      ...
      [   62.884185] [<bf033178>] (debug_read_mem+0x5c/0xac [omap_iommu_debug]) from [<c010e354>] (vfs_read+0xac/0x130)
      [   62.884185] [<c010e354>] (vfs_read+0xac/0x130) from [<c010e4a8>] (sys_read+0x40/0x70)
      [   62.884185] [<c010e4a8>] (sys_read+0x40/0x70) from [<c0014a00>] (ret_fast_syscall+0x0/0x3c)
      
      Fix also its 'echo bla > /debug/iommu/ducati/mem' Oops sibling, too.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Hiroshi Doyu <hdoyu@nvidia.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Joerg Roedel <Joerg.Roedel@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      87997aaa
    • O
      iommu/omap: fix erroneous omap-iommu-debug API calls · 46451d62
      Ohad Ben-Cohen 提交于
      Adapt omap-iommu-debug to the latest omap-iommu API changes, which
      were introduced by commit fabdbca8 "iommu/omap: eliminate the public
      omap_find_iommu_device() method".
      
      In a nutshell, iommu users are not expected to provide the omap_iommu
      handle anymore - instead, iommus are attached using their user's device
      handle.
      
      omap-iommu-debug is a hybrid beast though: it invokes both public and
      private omap iommu API, so fix it as necessary (otherwise a crash
      is imminent).
      
      Note: omap-iommu-debug is a bit disturbing, as it fiddles with internal
      omap iommu data and requires exposing API which is otherwise not needed.
      It should better be more tightly coupled with omap-iommu, to prevent
      further bit rot and avoid exposing redundant API. Naturally that's out
      of scope for the -rc cycle, so for now just fix the obvious.
      Reported-by: NRussell King <linux@arm.linux.org.uk>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Hiroshi Doyu <hdoyu@nvidia.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Joerg Roedel <Joerg.Roedel@amd.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      46451d62
    • C
      davinci_emac: Do not free all rx dma descriptors during init · 5d697032
      Christian Riesch 提交于
      This patch fixes a regression that was introduced by
      
      commit 0a5f3846
      davinci_emac: Add Carrier Link OK check in Davinci RX Handler
      
      Said commit adds a check whether the carrier link is ok. If the link is
      not ok, the skb is freed and no new dma descriptor added to the rx dma
      channel. This causes trouble during initialization when the carrier
      status has not yet been updated. If a lot of packets are received while
      netif_carrier_ok returns false, all dma descriptors are freed and the
      rx dma transfer is stopped.
      
      The bug occurs when the board is connected to a network with lots of
      traffic and the ifconfig down/up is done, e.g., when reconfiguring
      the interface with DHCP.
      
      The bug can be reproduced by flood pinging the davinci board while doing
      ifconfig eth0 down
      ifconfig eth0 up
      on the board.
      
      After that, the rx path stops working and the overrun value reported
      by ifconfig is counting up.
      
      This patch reverts commit 0a5f3846
      and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.
      Signed-off-by: NChristian Riesch <christian.riesch@omicron.at>
      Cc: <stable@vger.kernel.org>
      Cc: Hegde, Vinay <vinay.hegde@ti.com>
      Cc: Cyril Chemparathy <cyril@ti.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Tested-by: NRajashekhara, Sudhakar <sudhakar.raj@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d697032
    • Y
    • F
      viafb: fix IGA1 modesetting on VX900 · e2920638
      Florian Tobias Schandinat 提交于
      Even if the documentation calls this bit "Reserved" it has to be set
      to 0 for correct modesetting on IGA1.
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@vger.kernel.org
      e2920638
    • F
      viafb: select HW scaling on VX900 for IGA2 · 050f0e02
      Florian Tobias Schandinat 提交于
      VX900 can do hardware scaling for both IGAs in contrast to previous
      hardware which could do it only for IGA2. This patch ensures that
      we set the parameter for IGA2 and not for IGA1. This fixes hardware
      scaling on VX900 until we have the infrastructure to support it for
      both IGAs.
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@vger.kernel.org
      050f0e02
    • G
      phy: IC+101G and PHY_HAS_INTERRUPT flag · e3e09f26
      Giuseppe CAVALLARO 提交于
      This patch adds the PHY_HAS_INTERRUPT flag for IC+101 device series.
      Also the patch does a simple dity-up to signal that
      the driver actually is for IP101A LF and IP101G devices.
      In fact, these are two similar PHYs that have the same IDs
      and mainly differ for the EEE capability supported in the
      G series.
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3e09f26
    • D
      netdev/phy/icplus: Correct broken phy_init code · b8e3995a
      David McKay 提交于
      The code for ip1001_config_init() was totally broken if you were not
      using RGMII. Instead of returning an error code or zero it actually
      returned the value in the IP1001_SPEC_CTRL_STATUS_2 register. It was
      also trying to set the IP1001_APS_ON bit , but never actually wrote
      back the register.
      
      The error checking was also incorrect in both this function and the
      reset function, so this patch fixes that up in a consistent fashion.
      Signed-off-by: NDavid McKay <david.mckay@st.com>
      Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8e3995a
    • H
      drm/i915: fix a sprite watermark computation to avoid divide by zero if xpos<0 · 4e9bb47b
      Hai Lan 提交于
      When setting overlay position with x<0, it will divide 0 and make drm
      driver crash.
      Signed-off-by: NHai Lan <hai.lan@intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      4e9bb47b