commit 5abe9b2684 upstream.
As of next-20160607 with allyesconfig we get this linker failure:
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x21bc0d): Section mismatch in reference from
the function intel_scu_devices_create() to the function
.init.text:i2c_register_board_info()
This is caused by the fact that intel_scu_devices_create() calls
i2c_register_board_info() and intel_scu_devices_create() is not
annotated with __init. This typically involves manual code
inspection and if one is certain this is correct we would
just peg intel_scu_devices_create() with a __ref annotation.
In this case this would be wrong though as the
intel_scu_devices_create() call is exported, and used in
the ipc_probe() on drivers/platform/x86/intel_scu_ipc.c.
The issue is that even though builtin_pci_driver(ipc_driver)
is used this just exposes the probe routine, which can occur
at any point in time if this bus supports hotplug. A race
can happen between kernel_init_freeable() that calls the init
calls (in this case registeres the intel_scu_ipc.c driver, and
later free_initmem(), which would free the i2c_register_board_info().
If a probe happens later in boot i2c_register_board_info() would
not be present and we should get a page fault.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
[wsa: made function declaration a one-liner]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 2501c1bb05 ]
While modifying the driver to use the STOP interrupt, the completion of the
intermediate transfers need to wake the driver back up in order to initiate
the next transfer (restart condition). Otherwise you get never ending
interrupts and only the first transfer sent.
Fixes: 71ccea095e ("i2c: riic: correctly finish transfers")
Reported-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* linux-linaro-lsk-v4.4-android: (510 commits)
Linux 4.4.103
Revert "sctp: do not peel off an assoc from one netns to another one"
xen: xenbus driver must not accept invalid transaction ids
s390/kbuild: enable modversions for symbols exported from asm
ASoC: wm_adsp: Don't overrun firmware file buffer when reading region data
btrfs: return the actual error value from from btrfs_uuid_tree_iterate
ASoC: rsnd: don't double free kctrl
netfilter: nf_tables: fix oob access
netfilter: nft_queue: use raw_smp_processor_id()
spi: SPI_FSL_DSPI should depend on HAS_DMA
staging: iio: cdc: fix improper return value
iio: light: fix improper return value
mac80211: Suppress NEW_PEER_CANDIDATE event if no room
mac80211: Remove invalid flag operations in mesh TSF synchronization
drm: Apply range restriction after color adjustment when allocation
ALSA: hda - Apply ALC269_FIXUP_NO_SHUTUP on HDA_FIXUP_ACT_PROBE
ath10k: set CTS protection VDEV param only if VDEV is up
ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
ath10k: ignore configuring the incorrect board_id
ath10k: fix incorrect txpower set by P2P_DEVICE interface
...
Conflicts:
drivers/media/v4l2-core/v4l2-ctrls.c
kernel/sched/fair.c
Change-Id: I48152b2a0ab1f9f07e1da7823119b94f9b9e1751
[ Upstream commit 71ccea095e ]
This fixes the condition where the controller has not fully completed its
final transfer and leaves the bus and controller in a undesirable state.
At the end of the last transmitted byte, the existing driver would just
signal for a STOP condition to be transmitted then immediately signal
completion. However, the full STOP procedure might not have fully taken
place by the time the runtime PM shuts off the peripheral clock, leaving
the bus in a suspended state.
Alternatively, the STOP condition on the bus may have completed, but when
the next transaction is requested by the upper layer, not all the
necessary register cleanup was finished from the last transfer which made
the driver return BUS BUSY when it really wasn't.
This patch now makes all transmit and receive transactions wait for the
STOP condition to fully complete before signaling a completed transaction.
With this new method, runtime PM no longer seems to be an issue.
Fixes: 310c18a414 ("i2c: riic: add driver")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6ebcedbab upstream.
Commit b6c159a9cb ("i2c: ismt: Don't duplicate the receive length for
block reads") broke I2C block reads. It aimed to fix normal SMBus block
read, but changed the correct behavior of I2C block read in the process.
According to Documentation/i2c/smbus-protocol, one vital difference
between normal SMBus block read and I2C block read is that there is no
byte count prefixed in the data sent on the wire:
SMBus Block Read: i2c_smbus_read_block_data()
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
I2C Block Read: i2c_smbus_read_i2c_block_data()
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
Therefore the two transaction types need to be processed differently in
the driver by copying of the dma_buffer as done previously for the
I2C_SMBUS_I2C_BLOCK_DATA case.
Fixes: b6c159a9cb ("i2c: ismt: Don't duplicate the receive length for block reads")
Signed-off-by: Pontus Andersson <epontan@gmail.com>
Tested-by: Stephen Douthit <stephend@adiengineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba201c4f5e upstream.
Compare the number of bytes actually seen on the wire to the byte
count field returned by the slave device.
Previously we just overwrote the byte count returned by the slave
with the real byte count and let the caller figure out if the
message was sane.
Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
Tested-by: Dan Priamo <danp@adiengineering.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b6c159a9cb upstream.
According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.
desc->rxbytes reports all bytes read on the wire, including the
"byte count" byte. So if a device sends 4 bytes in response to a
block read, on the wire and in the DMA buffer we see:
count data1 data2 data3 data4
0x04 0xde 0xad 0xbe 0xef
That's what we want to return in data->block to the next level.
Instead we were actually prefixing that with desc->rxbytes:
bad
count count data1 data2 data3 data4
0x05 0x04 0xde 0xad 0xbe 0xef
This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.
Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
Tested-by: Dan Priamo <danp@adiengineering.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 27bfeb5a06 upstream.
David reported that the length for memset was incorrect (element sizes
were not taken into account). Then I saw that we are clearing kzalloced
memory, so we can simply drop this code.
Reported-by: David Binderman <dcb314@hotmail.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a23318feef upstream.
The commit 8503ff1665 ("i2c: designware: Avoid unnecessary resuming
during system suspend"), may suggest to the PM core to try out the so
called direct_complete path for system sleep. In this path, the PM core
treats a runtime suspended device as it's already in a proper low power
state for system sleep, which makes it skip calling the system sleep
callbacks for the device, except for the ->prepare() and the ->complete()
callbacks.
However, the PM core may unset the direct_complete flag for a parent
device, in case its child device are being system suspended before. In this
scenario, the PM core invokes the system sleep callbacks, no matter if the
device is runtime suspended or not.
Particularly in cases of an existing i2c slave device, the above path is
triggered, which breaks the assumption that the i2c device is always
runtime resumed whenever the dw_i2c_plat_suspend() is being called.
More precisely, dw_i2c_plat_suspend() calls clk_core_disable() and
clk_core_unprepare(), for an already disabled/unprepared clock, leading to
a splat in the log about clocks calls being wrongly balanced and breaking
system sleep.
To still allow the direct_complete path in cases when it's possible, but
also to keep the fix simple, let's runtime resume the i2c device in the
->suspend() callback, before continuing to put the device into low power
state.
Note, in cases when the i2c device is attached to the ACPI PM domain, this
problem doesn't occur, because ACPI's ->suspend() callback, assigned to
acpi_subsys_suspend(), already calls pm_runtime_resume() for the device.
It should also be noted that this change does not fix commit 8503ff1665
("i2c: designware: Avoid unnecessary resuming during system suspend").
Because for the non-ACPI case, the system sleep support was already broken
prior that point.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If i2c slave devices don't work at the same time, which have
the same i2c addr, this patch can make them working.
Change-Id: I1bfb7783924b08bdc6e12bf47c2de01bdac7c2e2
Signed-off-by: Zhang aihui <zah@rock-chips.com>
LSK 17.07 v4.4-android
* tag 'lsk-v4.4-17.07-android': (402 commits)
dt/vendor-prefixes: remove redundant vendor
Linux 4.4.77
saa7134: fix warm Medion 7134 EEPROM read
x86/mm/pat: Don't report PAT on CPUs that don't support it
ext4: check return value of kstrtoull correctly in reserved_clusters_store
staging: comedi: fix clean-up of comedi_class in comedi_init()
staging: vt6556: vnt_start Fix missing call to vnt_key_init_table.
tcp: fix tcp_mark_head_lost to check skb len before fragmenting
md: fix super_offset endianness in super_1_rdev_size_change
md: fix incorrect use of lexx_to_cpu in does_sb_need_changing
perf tools: Use readdir() instead of deprecated readdir_r() again
perf tests: Remove wrong semicolon in while loop in CQM test
perf trace: Do not process PERF_RECORD_LOST twice
perf dwarf: Guard !x86_64 definitions under #ifdef else clause
perf pmu: Fix misleadingly indented assignment (whitespace)
perf annotate browser: Fix behaviour of Shift-Tab with nothing focussed
perf tools: Remove duplicate const qualifier
perf script: Use readdir() instead of deprecated readdir_r()
perf thread_map: Use readdir() instead of deprecated readdir_r()
perf tools: Use readdir() instead of deprecated readdir_r()
...
Conflicts:
Makefile
drivers/Kconfig
drivers/Makefile
drivers/usb/dwc3/gadget.c
Change-Id: Ib4aae2e34ebbf0d7953c748a33f673acb3e744fc
LSK 17.06 v4.4-android
* tag 'lsk-v4.4-17.06-android': (134 commits)
ANDROID: sdcardfs: remove dead function open_flags_to_access_mode()
ANDROID: android-base.cfg: split out arm64-specific configs
usb: gadget: f_fs: Fix possibe deadlock
ANDROID: uid_sys_stats: check previous uid_entry before call find_or_register_uid
ANDROID: sdcardfs: d_splice_alias can return error values
android: base-cfg: disable CONFIG_NFS_FS and CONFIG_NFSD
schedstats/eas: guard properly to avoid breaking non-smp schedstats users
BACKPORT: f2fs: sanity check size of nat and sit cache
FROMLIST: f2fs: sanity check checkpoint segno and blkoff
sched/tune: don't use schedtune before it is ready
sched/fair: use SCHED_CAPACITY_SCALE for energy normalization
sched/{fair,tune}: use reciprocal_value to compute boost margin
sched/tune: Initialize raw_spin_lock in boosted_groups
sched/tune: report when SchedTune has not been initialized
sched/tune: fix sched_energy_diff tracepoint
sched/tune: increase group count to 5
cpufreq/schedutil: use boosted_cpu_util for PELT to match WALT
sched/fair: Fix sched_group_energy() to support per-cpu capacity states
sched/fair: discount task contribution to find CPU with lowest utilization
sched/fair: ensure utilization signals are synchronized before use
...
If the system rebooted, there might be i2c transfer at the
same time, it will make something unpredictable, because
the i2c host was reseted, but the slave device wasn't, such
as rk808 pmic, so make sure the i2c transfer to be finished
before system shutdown at the reset mode.
Change-Id: I3c09f3acbe86595c295edc191aa38351adb7d5dc
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
commit 30f939feae upstream.
i2c_smbus_xfer() does not always fill an entire block, allowing
kernel stack memory disclosure through the temp variable. Clear
it before it's read to.
Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f724fb303 upstream.
In of_i2c_register_device(), when the check for
device address validity fails we print the info.addr,
which has not been assigned properly.
Fix this by printing the actual invalid address.
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: b4e2f6ac12 ("i2c: apply DT flags when probing")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 93d710a65e upstream.
We get the following build error from UM Linux after adding
an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
ERROR: "devm_ioremap_resource"
[drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
ERROR: "of_address_to_resource"
[drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
It appears that the I2C mux core code depends on HAS_IOMEM
for historical reasons, while CONFIG_I2C_MUX_REG does *not*
have a direct dependency on HAS_IOMEM.
This creates a situation where a allyesconfig or allmodconfig
for UM Linux will select I2C_MUX, and will implicitly enable
I2C_MUX_REG as well, and the compilation will fail for the
register driver.
Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
removing the dependency from I2C_MUX.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 147b36d5b7 upstream.
Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.
The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:
i2c_register_driver() i2c_del_adapter()
driver_register() ...
bus_add_driver() ...
... bus_for_each_drv(..., __process_removed_adapter)
... i2c_do_del_adapter()
... list_for_each_entry_safe(..., &driver->clients, ...)
INIT_LIST_HEAD(&driver->clients);
To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().
The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:
% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 17 [#1] SMP ARM
CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: e5ada400 task.stack: e4936000
PC is at i2c_do_del_adapter+0x20/0xcc
LR is at __process_removed_adapter+0x14/0x1c
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 35bd004a DAC: 00000051
Process sh (pid: 533, stack limit = 0xe4936210)
Stack: (0xe4937d28 to 0xe4938000)
Backtrace:
[<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
[<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
[<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
[<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
[<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
[<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
[<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
[<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
[<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
[<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
[<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
[<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
[<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
[<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
[<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* linux-linaro-lsk-v4.4-android: (1362 commits)
Linux 4.4.30
Revert "fix minor infoleak in get_user_ex()"
Revert "x86/mm: Expand the exception table logic to allow new handling options"
Linux 4.4.29
ARM: pxa: pxa_cplds: fix interrupt handling
powerpc/nvram: Fix an incorrect partition merge
mpt3sas: Don't spam logs if logging level is 0
perf symbols: Fixup symbol sizes before picking best ones
perf symbols: Check symbol_conf.allow_aliases for kallsyms loading too
perf hists browser: Fix event group display
clk: divider: Fix clk_divider_round_rate() to use clk_readl()
clk: qoriq: fix a register offset error
s390/con3270: fix insufficient space padding
s390/con3270: fix use of uninitialised data
s390/cio: fix accidental interrupt enabling during resume
x86/mm: Expand the exception table logic to allow new handling options
dmaengine: ipu: remove bogus NO_IRQ reference
power: bq24257: Fix use of uninitialized pointer bq->charger
staging: r8188eu: Fix scheduling while atomic splat
ASoC: dapm: Fix kcontrol creation for output driver widget
...
We found a bug that i2c transfer sometimes failed on 3066a board with
stabel-4.8, the con register would be updated by uninitialized tuning
value, it made the i2c transfer failed.
So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
Change-Id: I8686b8525e7fc8adc896f60dec4ae74d6c2a173c
Signed-off-by: David Wu <david.wu@rock-chips.com>
Tested-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
commit 331dcf421c upstream.
If the i2c device is already runtime suspended, if qup_i2c_suspend is
executed during suspend-to-idle or suspend-to-ram it will result in the
following splat:
WARNING: CPU: 3 PID: 1593 at drivers/clk/clk.c:476 clk_core_unprepare+0x80/0x90
Modules linked in:
CPU: 3 PID: 1593 Comm: bash Tainted: G W 4.8.0-rc3 #14
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
PC is at clk_core_unprepare+0x80/0x90
LR is at clk_unprepare+0x28/0x40
pc : [<ffff0000086eecf0>] lr : [<ffff0000086f0c58>] pstate: 60000145
Call trace:
clk_core_unprepare+0x80/0x90
qup_i2c_disable_clocks+0x2c/0x68
qup_i2c_suspend+0x10/0x20
platform_pm_suspend+0x24/0x68
...
This patch fixes the issue by executing qup_i2c_pm_suspend_runtime
conditionally in qup_i2c_suspend.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 371a015344 upstream.
the eg20t driver call request_irq() function before the pch_base_address,
base address of i2c controller's register, is assigned an effective value.
there is one possible scenario that an interrupt which isn't inside eg20t
arrives immediately after request_irq() is executed when i2c controller
shares an interrupt number with others. since the interrupt handler
pch_i2c_handler() has already active as shared action, it will be called
and read its own register to determine if this interrupt is from itself.
At that moment, since base address of i2c registers is not remapped
in kernel space yet,so the INT handler will access an illegal address
and then a error occurs.
Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixs the following warning:
drivers/i2c/busses/i2c-rk3x.c: In function 'rk3x_i2c_v1_calc_timings':
drivers/i2c/busses/i2c-rk3x.c:745:41: warning: variable 'min_total_ns' set but not used [-Wunused-but-set-variable]
Change-Id: I99da5c5dc80da040eb5333bdf204a71de472a332
Reported-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This patch fixes the following sparse warning:
drivers/i2c/busses/i2c-rk3x.c:888:17: warning: cast truncates bits from constant value (ffffffffff00 becomes ffffff00)
Change-Id: If4ffda2f57ce967a6824765093823bd7ff75ebe3
Reported-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Depending on a number of factors including:
- Which exact Rockchip SoC we're working with
- How deep we suspend
- Which i2c port we're on
We might lose the state of the i2c registers at suspend time.
Specifically we've found that on rk3399 the i2c ports that are not in
the PMU power domain lose their state with the current suspend depth
configured by ARM Tursted Firmware.
Note that there are very few actual i2c registers that aren't configured
per transfer anyway so all we actually need to re-configure are the
clock config registers. We'll just add a call to rk3x_i2c_adapt_div()
at resume time and be done with it.
NOTE: On rk3399 on ports whose power was lost, I put printouts in at
resume time. I saw things like:
before: con=0x00010300, div=0x00060006
after: con=0x00010200, div=0x00180025
Change-Id: I9799a77b9f332ef6b72ca2a8c1ee348b470a4d53
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: David Wu <david.wu@rock-chips.com>
Tested-by: David Wu <david.wu@rock-chips.com>
[wsa: removed duplicate const]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit 4d01d88019 upstream.
cros_ec_cmd_xfer returns success status if the command transport
completes successfully, but the execution result is incorrectly ignored.
In many cases, the execution result is assumed to be successful, leading
to ignored errors and operating on uninitialized data.
We've recently introduced the cros_ec_cmd_xfer_status() helper to avoid these
problems. Let's use it.
[Regarding the 'Fixes' tag; there is significant refactoring since the driver's
introduction, but the underlying logical error exists throughout I believe]
Fixes: 9d230c9e4f ("i2c: ChromeOS EC tunnel driver")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7dd91d52a8 upstream.
There is the only failure path in efm32_i2c_probe(),
where clk_disable_unprepare() is missed.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: 1b5b23718b ("i2c: efm32: new bus driver")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a7ae81952c upstream.
Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
Device (SBUS)
{
OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
Field (SMBI, ByteAcc, NoLock, Preserve)
{
HSTS, 8,
Offset (0x02),
HCON, 8,
HCOM, 8,
TXSA, 8,
DAT0, 8,
DAT1, 8,
HBDR, 8,
PECR, 8,
RXSA, 8,
SDAT, 16
}
There are also bunch of AML methods that that the BIOS can use to access
these fields. Most of the systems in question AML methods accessing the
SMBI OpRegion are never used.
Now, because of this SMBI OpRegion many systems fail to load the SMBus
driver with an error looking like one below:
ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
conflicts with OpRegion 0x0000000000003040-0x000000000000304F
(\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver
The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
the SMBus driver.
It turns out that we can install a custom SystemIO address space handler
for the SMBus device to intercept all accesses through that OpRegion. This
allows us to share the PCI BAR with the AML code if it for some reason is
using it. We do not expect that this OpRegion handler will ever be called
but if it is we print a warning and prevent all access from the SMBus
driver itself.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041
Reported-by: Andy Lutomirski <luto@kernel.org>
Reported-by: Pali Rohár <pali.rohar@gmail.com>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* linux-linaro-lsk-v4.4-android: (797 commits)
parisc: Use generic extable search and sort routines
arm64: kasan: Use actual memory node when populating the kernel image shadow
arm64: mm: treat memstart_addr as a signed quantity
arm64: lse: deal with clobbered IP registers after branch via PLT
arm64: mm: check at build time that PAGE_OFFSET divides the VA space evenly
arm64: kasan: Fix zero shadow mapping overriding kernel image shadow
arm64: consistently use p?d_set_huge
arm64: fix KASLR boot-time I-cache maintenance
arm64: hugetlb: partial revert of 66b3923a1a
arm64: make irq_stack_ptr more robust
arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness
efi: stub: use high allocation for converted command line
efi: stub: add implementation of efi_random_alloc()
efi: stub: implement efi_get_random_bytes() based on EFI_RNG_PROTOCOL
arm64: kaslr: randomize the linear region
arm64: add support for kernel ASLR
arm64: add support for building vmlinux as a relocatable PIE binary
arm64: switch to relative exception tables
extable: add support for relative extables to search and sort routines
scripts/sortextable: add support for ET_DYN binaries
...
Conflicts:
arch/arm64/mm/dma-mapping.c
drivers/clk/rockchip/clk-rk3368.c
drivers/mmc/core/core.c
drivers/mmc/core/sdio.c
include/linux/dcache.h
Change-Id: Ibaa1e90ac735db8d9f5e542c266ef27b91616ef4
commit 10ff4c5239 upstream.
The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.
But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.
An example of this happens on the Exynos5422 Odroid XU4 board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.
The possible deadlock is reported by the kernel lockdep:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
*** DEADLOCK ***
Fix it by leaving the code prepared on probe and use {en,dis}able in
the I2C transfer function.
This patch is similar to commit 34e81ad5f0 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 609d5a1b2b upstream.
Since commit ea8daa7b97 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:
drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
'dma_alloc_coherent' from incompatible pointer type
Fix the build break by converting txdma & rxdma to dma_addr_t.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fixes: ea8daa7b97
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* linux-linaro-lsk-v4.4-android: (477 commits)
arm64: vdso: Mark vDSO code as read-only
ARM/vdso: Mark the vDSO code read-only after init
x86/vdso: Mark the vDSO code read-only after init
lkdtm: Verify that '__ro_after_init' works correctly
arch: Introduce post-init read-only memory
x86/mm: Always enable CONFIG_DEBUG_RODATA and remove the Kconfig option
mm/init: Add 'rodata=off' boot cmdline parameter to disable read-only kernel mappings
asm-generic: Consolidate mark_rodata_ro()
Linux 4.4.6
ld-version: Fix awk regex compile failure
target: Drop incorrect ABORT_TASK put for completed commands
block: don't optimize for non-cloned bio in bio_get_last_bvec()
MIPS: smp.c: Fix uninitialised temp_foreign_map
MIPS: Fix build error when SMP is used without GIC
ovl: fix getcwd() failure after unsuccessful rmdir
ovl: copy new uid/gid into overlayfs runtime inode
userfaultfd: don't block on the last VM updates at exit time
powerpc/powernv: Fix OPAL_CONSOLE_FLUSH prototype and usages
powerpc/powernv: Add a kmsg_dumper that flushes console output on panic
powerpc: Fix dedotify for binutils >= 2.26
...
- new method to caculate i2c timings for rk3399:
There was an timing issue about "repeated start" time at the I2C
controller of version0, controller appears to drop SDA at .875x (7/8)
programmed clk high. On version 1 of the controller, the rule(.875x)
isn't enough to meet tSU;STA
requirements on 100k's Standard-mode. To resolve this issue,
sda_update_config, start_setup_config and stop_setup_config for I2C
timing information are added, new rules are designed to calculate
the timing information at new v1.
- pclk and function clk are separated at rk3399.
- support i2c highspeed mode: 1.7MHz for rk3399
Change-Id: I413455cf94fe7486c40694059e2f0931433992bb
Signed-off-by: David Wu <david.wu@rock-chips.com>
Switch to the new generic functions: i2c_parse_fw_timings().
Change-Id: I14c3bea8e696d0ba5467effba1a157cd86e376d6
Signed-off-by: David Wu <david.wu@rock-chips.com>
