Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 5月, 2018 23 次提交
  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
  5. 26 4月, 2018 12 次提交