Update the help text to reflect current support devices:
1. The Exynos high speed I2C driver supports Exynos5 (ARMv7), Exynos5433
   and Exynos7 (both ARMv8) SoCs,
2. The S3C I2C driver supports S3C, S5Pv210 and Exynos{3,4,5} SoCs.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some of the I2C bus drivers can be compile tested to increase build
coverage.  This requires also:
1. Adding dependencies on COMMON_CLK for BCM2835 and Meson I2C
   controllers,
2. Adding 'if' conditional to 'default y' so they will not get enabled
   by default on all other architectures,
3. Limiting few compile test options to supported architectures (which
   provide the readsX()/writesX() primitives).
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
[wsa: revert chunk for ZX2967. it needs more preparation]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The recommendation is that the set_active should be done
with pm runtime disabled.
Also fix the remove path for clocking.
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It's not always the case that clock is already available when i2c
driver get probed at the first time, e.g. the clock is provided by
clock wizard which may be probed after i2c driver. So let's defer
the probe when devm_clk_get() call fails and give it chance to
try later.
Signed-off-by: NVenkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add timeout to the rx fifo empty wait loop. Also check for the return
value for xiic_reinit and pass it to xiic_start_xfer.
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

size_t should be printed with its own format to be 64-bit friendly and
fix warning when compiling on 64-bit platform (e.g. with COMPILE_TEST):

    drivers/i2c/busses/i2c-highlander.c: In function ‘highlander_i2c_smbus_xfer’:
    drivers/i2c/busses/i2c-highlander.c:325:22: warning:
        format ‘%d’ expects argument of type ‘int’,
        but argument 3 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

resource_size_t should be printed with its own size-independent format
to fix warnings when compiling on 64-bit platform (e.g. with
COMPILE_TEST):

    drivers/i2c/busses/i2c-pnx.c: In function ‘i2c_pnx_probe’:
    drivers/i2c/busses/i2c-pnx.c:737:47: warning:
        format ‘%x’ expects argument of type ‘unsigned int’,
        but argument 5 has type ‘resource_size_t {aka long long unsigned int}’ [-Wformat=]
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

resource_size_t should be printed with its own size-independent format
to fix warnings when compiling on 64-bit platform (e.g. with
COMPILE_TEST):

    drivers/i2c/busses/i2c-pmcmsp.c: In function ‘pmcmsptwi_probe’:
    drivers/i2c/busses/i2c-pmcmsp.c:276:25: warning:
        format ‘%x’ expects argument of type ‘unsigned int’,
        but argument 3 has type ‘resource_size_t {aka long long unsigned int}’ [-Wformat=]
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

i2c_new_device is deprecated, use i2c_new_client_device. Also, align a
paragraph while here.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

i2c_new_device is deprecated, use i2c_new_client_device.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Tested-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

iomem pointers should be printed with pointer format to hide the
actual value and fix warnings when compiling on 64-bit platform (e.g. with
COMPILE_TEST):

    drivers/i2c/busses/i2c-stu300.c: In function ‘stu300_wait_while_busy’:
    drivers/i2c/busses/i2c-stu300.c:446:76: warning:
        cast from pointer to integer of different size [-Wpointer-to-int-cast]
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It is more robust to check completion status in addition to the left time
in a case of DMA transfer because transfer's completion happens in two
phases [one is ISR, other is tasklet] and thus it is possible that DMA is
completed while I2C completion awaiting times out because of the deferred
notification done by the DMA driver. The DMA completion status becomes
100% actual after DMA synchronization. This fixes spurious DMA timeouts
when system is under load.
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It is possible that I2C could error out in the middle of DMA transfer and
in this case DMA channel needs to be reset, otherwise a follow up transfer
will fail because DMA channel stays blocked.
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There is nothing to synchronize in regards to memory accesses for PIO
transfers and for DMA transfers the DMA API takes care of the syncing.
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

DMA is preferred for a larger transfers, while PIO is preferred for a
smaller transfers to avoid unnecessary DMA overhead. There is no strict
size limitations for the PIO-mode transfers, so let's rename the constant
for clarity.
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

System shutdown may happen with interrupts being disabled and in this case
kernel may hang if atomic transfer isn't supported by driver.

There were several occurrences where I found my Nexus 7 completely
discharged despite of being turned off and then one day I spotted this in
the log:

 reboot: Power down
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:40 i2c_transfer+0x95/0x9c
 No atomic I2C transfer handler for 'i2c-1'
 Modules linked in: tegra30_devfreq
 CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.4.0-next-20191202-00120-gf7ecd80fb803-dirty #3195
 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
 [<c010e4b5>] (unwind_backtrace) from [<c010a0fd>] (show_stack+0x11/0x14)
 [<c010a0fd>] (show_stack) from [<c09995e5>] (dump_stack+0x85/0x94)
 [<c09995e5>] (dump_stack) from [<c011f3d1>] (__warn+0xc1/0xc4)
 [<c011f3d1>] (__warn) from [<c011f691>] (warn_slowpath_fmt+0x61/0x78)
 [<c011f691>] (warn_slowpath_fmt) from [<c069a8dd>] (i2c_transfer+0x95/0x9c)
 [<c069a8dd>] (i2c_transfer) from [<c05667f1>] (regmap_i2c_read+0x4d/0x6c)
 [<c05667f1>] (regmap_i2c_read) from [<c0563601>] (_regmap_raw_read+0x99/0x1cc)
 [<c0563601>] (_regmap_raw_read) from [<c0563757>] (_regmap_bus_read+0x23/0x38)
 [<c0563757>] (_regmap_bus_read) from [<c056293d>] (_regmap_read+0x3d/0xfc)
 [<c056293d>] (_regmap_read) from [<c0562d3b>] (_regmap_update_bits+0x87/0xc4)
 [<c0562d3b>] (_regmap_update_bits) from [<c0563add>] (regmap_update_bits_base+0x39/0x50)
 [<c0563add>] (regmap_update_bits_base) from [<c056fd39>] (max77620_pm_power_off+0x29/0x2c)
 [<c056fd39>] (max77620_pm_power_off) from [<c013bbdd>] (__do_sys_reboot+0xe9/0x170)
 [<c013bbdd>] (__do_sys_reboot) from [<c0101001>] (ret_fast_syscall+0x1/0x28)
 Exception stack(0xde907fa8 to 0xde907ff0)
 7fa0:                   00000000 00000000 fee1dead 28121969 4321fedc 00000000
 7fc0: 00000000 00000000 00000000 00000058 00000000 00000000 00000000 00000000
 7fe0: 0045adf0 bed9abb8 004444a0 b6c666d0
 ---[ end trace bdd18f87595b1a5e ]---

The atomic transferring is implemented by enforcing PIO mode for the
transfer and by polling interrupt status until transfer is completed or
failed.

Now system shuts down properly every time.
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Potentially it is possible that interrupt may fire after transfer timeout.
That may not end up well for the next transfer because interrupt handling
may race with hardware resetting.

This is very unlikely to happen in practice, but anyway let's prevent the
potential problem by enabling interrupt only at the moments when it is
actually necessary to get some interrupt event.
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

After removal of the parport-light driver, this include is used by the
parport driver exclusively and can be included in the main source. Move
module parameter declarations to its variable declaration while here.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The driver is not 'new' anymore, so remove details from the driver it
surpassed.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The justification of a light version of the parport driver was less
overhead for embedded systems. Well, today, even if an embedded system
still has a parport, it surely can handle the fully-fledged parport
driver. Remove it to reduce the maintenance burden.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

One of the recent Tegra I2C commits made a change that resumes runtime PM
during driver's probe, but it missed to put the RPM in a case of error.
Note that it's not correct to use pm_runtime_status_suspended because it
breaks RPM refcounting.

Fixes: 8ebf15e9 ("i2c: tegra: Move suspend handling to NOIRQ phase")
Cc: <stable@vger.kernel.org> # v5.4+
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I noticed that sometime I2C clock is kept enabled during suspend-resume.
This happens because runtime PM defers dynamic suspension and thus it may
happen that runtime PM is in active state when system enters into suspend.
In particular I2C controller that is used for CPU's DVFS is often kept ON
during suspend because CPU's voltage scaling happens quite often.

Fixes: 8ebf15e9 ("i2c: tegra: Move suspend handling to NOIRQ phase")
Cc: <stable@vger.kernel.org> # v5.4+
Tested-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Boards with some of the 32-bit SoCs (mostly Meson8 and Meson8m2) use a
Ricoh RN5T618 PMU which acts as system power controller. The driver for
the system power controller may need to the I2C bus just before shutting
down or rebooting the system. At this stage the interrupts may be
disabled already.

Implement the master_xfer_atomic callback so the driver for the RN5T618
PMU can communicate properly with the PMU when shutting down or
rebooting the board. The CTRL register has a status bit which can be
polled to determine when processing has completed. According to the
public S805 datasheet the value 0 means "idle" and 1 means "running".
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
[wsa: converted some whitespace alignment]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Pull RISC-V fixes from Paul Walmsley:
 "Two fixes for RISC-V:

   - Clear FP registers during boot when FP support is present, rather
     than when they aren't present

   - Move the header files associated with the SiFive L2 cache
     controller to drivers/soc (where the code was recently moved)"

* tag 'riscv/for-v5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: Fixup obvious bug for fp-regs reset
  riscv: move sifive_l2_cache.h to include/soc

CSR_MISA is defined in Privileged Architectures' spec: 3.1.1 Machine
ISA Register misa. Every bit:1 indicate a feature, so we should beqz
reset_done when there is no F/D bit in csr_misa register.
Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
[paul.walmsley@sifive.com: fix typo in commit message]
Fixes: 9e806356 ("riscv: clear the instruction cache and all registers when booting")
Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>

The commit 9209fb51 ("riscv: move sifive_l2_cache.c to drivers/soc")
moves the sifive L2 cache driver to driver/soc. It did not move the
header file along with the driver. Therefore this patch moves the header
file to driver/soc
Signed-off-by: NYash Shah <yash.shah@sifive.com>
Reviewed-by: NAnup Patel <anup@brainfault.org>
[paul.walmsley@sifive.com: updated to fix the include guard]
Fixes: 9209fb51 ("riscv: move sifive_l2_cache.c to drivers/soc")
Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>

Pull iommu fixes from Joerg Roedel:

 - Two fixes for VT-d and generic IOMMU code to fix teardown on error
   handling code paths.

 - Patch for the Intel VT-d driver to fix handling of non-PCI devices

 - Fix W=1 compile warning in dma-iommu code

* tag 'iommu-fixes-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/dma: fix variable 'cookie' set but not used
  iommu/vt-d: Unlink device if failed to add to group
  iommu: Remove device link to group on failure
  iommu/vt-d: Fix adding non-PCI devices to Intel IOMMU

Pull i2c fixes from Wolfram Sang:
 "Two driver bugfixes, a documentation fix, and a removal of a spec
  violation for the bus recovery algorithm in the core"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: fix bus recovery stop mode timing
  i2c: bcm2835: Store pointer to bus clock
  dt-bindings: i2c: at91: fix i2c-sda-hold-time-ns documentation for sam9x60
  i2c: at91: fix clk_offset for sam9x60