1. 14 5月, 2018 9 次提交
  2. 12 5月, 2018 11 次提交
  3. 27 4月, 2018 5 次提交
    • B
      i2c: sprd: Fix the i2c count issue · 2a010461
      Baolin Wang 提交于
      We found the I2C controller count register is unreliable sometimes,
      that will cause I2C to lose data. Thus we can read the data count
      from 'i2c_dev->count' instead of the I2C controller count register.
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      2a010461
    • B
      i2c: sprd: Prevent i2c accesses after suspend is called · da33aa03
      Baolin Wang 提交于
      Add one flag to indicate if the i2c controller has been in suspend state,
      which can prevent i2c accesses after i2c controller is suspended following
      system suspend.
      Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      da33aa03
    • A
      i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr() · 23a27722
      Alexander Popov 提交于
      i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which
      returns ZERO_SIZE_PTR if i2c_msg.len is zero.
      
      Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case
      of I2C_M_RD | I2C_M_RECV_LEN transfer. That causes a kernel oops in
      case of zero len.
      
      Let's check the len against zero before dereferencing buf pointer.
      
      This issue was triggered by syzkaller.
      Signed-off-by: NAlexander Popov <alex.popov@linux.com>
      Reviewed-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      [wsa: use '< 1' instead of '!' for easier readability]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      23a27722
    • S
      cpufreq: powernv: Fix hardlockup due to synchronous smp_call in timer interrupt · c0f7f5b6
      Shilpasri G Bhat 提交于
      gpstate_timer_handler() uses synchronous smp_call to set the pstate
      on the requested core. This causes the below hard lockup:
      
        smp_call_function_single+0x110/0x180 (unreliable)
        smp_call_function_any+0x180/0x250
        gpstate_timer_handler+0x1e8/0x580
        call_timer_fn+0x50/0x1c0
        expire_timers+0x138/0x1f0
        run_timer_softirq+0x1e8/0x270
        __do_softirq+0x158/0x3e4
        irq_exit+0xe8/0x120
        timer_interrupt+0x9c/0xe0
        decrementer_common+0x114/0x120
        -- interrupt: 901 at doorbell_global_ipi+0x34/0x50
        LR = arch_send_call_function_ipi_mask+0x120/0x130
        arch_send_call_function_ipi_mask+0x4c/0x130
        smp_call_function_many+0x340/0x450
        pmdp_invalidate+0x98/0xe0
        change_huge_pmd+0xe0/0x270
        change_protection_range+0xb88/0xe40
        mprotect_fixup+0x140/0x340
        SyS_mprotect+0x1b4/0x350
        system_call+0x58/0x6c
      
      One way to avoid this is removing the smp-call. We can ensure that the
      timer always runs on one of the policy-cpus. If the timer gets
      migrated to a cpu outside the policy then re-queue it back on the
      policy->cpus. This way we can get rid of the smp-call which was being
      used to set the pstate on the policy->cpus.
      
      Fixes: 7bc54b65 ("timers, cpufreq/powernv: Initialize the gpstate timer as pinned")
      Cc: stable@vger.kernel.org # v4.8+
      Reported-by: NNicholas Piggin <npiggin@gmail.com>
      Reported-by: NPridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
      Signed-off-by: NShilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
      Acked-by: NNicholas Piggin <npiggin@gmail.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c0f7f5b6
    • M
      mtd: rawnand: marvell: fix the chip-select DT parsing logic · f6997bec
      Miquel Raynal 提交于
      The block responsible of parsing the DT for the number of chip-select
      lines uses an 'if/else if/else if' block. The content of the second and
      third 'else if' conditions are:
              1/ the actual condition to enter the sub-block and
              2/ the operation to do in this sub-block.
      
              [...]
              else if (condition1_to_enter && action1() == failed)
                      raise_error();
              else if (condition2_to_enter && action2() == failed)
                      raise_error();
              [...]
      
      In case of failure, the sub-block is entered and an error raised.
      Otherwise, in case of success, the code would continue erroneously in
      the next 'else if' statement because it did not failed (and did not
      enter the first 'else if' sub-block).
      
      The first 'else if' refers to legacy bindings while the second 'else if'
      refers to new bindings. The second 'else if', which is entered
      erroneously, checks for the 'reg' property, which, for old bindings,
      does not mean anything because it would not be the number of CS
      available, but the regular register map of almost any DT node. This
      being said, the content of the 'reg' property being the register map
      offset and length, it has '2' values, so the number of CS in this
      situation is assumed to be '2'.
      
      When running nand_scan_ident() with 2 CS, the core will check for an
      array of chips. It will first issue a RESET and then a READ_ID. Of
      course this will trigger two timeouts because there is no chip in front
      of the second CS:
      
      [    1.367460] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000080)
      [    1.474292] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000280)
      
      Indeed, this is harmless and the core will then assume there is only one
      valid CS.
      
      Fix the logic in the whole block by entering each sub-block just on the
      'is legacy' condition, doing the action inside the sub-block. This way,
      when the action succeeds, the whole block is left.
      
      Furthermore, for both the old bindings and the new bindings the same
      logic was applied to retrieve the number of CS lines:
      using of_get_property() to get a size in bytes, converted in the actual
      number of lines by dividing it per sizeof(u32) (4 bytes).
      
      This is fine for the 'reg' property which is a list of the CS IDs but
      not for the 'num-cs' property which is directly the value of the number
      of CS.
      
      Anyway, no existing DT uses another value than 'num-cs = <1>' and no
      other value has ever been supported by the old driver (pxa3xx_nand.c).
      Remove this condition and apply a number of 1 CS anyway, as already
      described in the bindings.
      
      Finally, the 'reg' property of a 'nand' node (with the new bindings)
      gives the IDs of each CS line in use. marvell_nand.c driver first look
      at the number of CS lines that are present in this property.
      
      Better use of_property_count_elems_of_size() than dividing by 4 the size
      of the number of bytes returned by of_get_property().
      
      Fixes: 02f26ecf ("mtd: nand: add reworked Marvell NAND controller driver")
      Cc: stable@vger.kernel.org
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Tested-by: NChris Packham <chris.packham@alliedtelesis.co.nz>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      f6997bec
  4. 26 4月, 2018 15 次提交