- 15 Jan, 2020 29 commits
-
-
Shubhrajyoti Datta authored
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: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Krzysztof Kozlowski authored
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: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Krzysztof Kozlowski authored
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: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Krzysztof Kozlowski authored
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: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
i2c_new_device is deprecated, use i2c_new_client_device. Also, align a paragraph while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
i2c_new_device is deprecated, use i2c_new_client_device. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Tested-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
Move away from the deprecated API and return the shiny new ERRPTR where useful. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Krzysztof Kozlowski authored
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: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
-
Wolfram Sang authored
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: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
The driver is not 'new' anymore, so remove details from the driver it surpassed. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Wolfram Sang authored
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: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Dmitry Osipenko authored
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: Thierry Reding <treding@nvidia.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
- 13 Jan, 2020 3 commits
-
-
Martin Blumenstingl authored
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: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> [wsa: converted some whitespace alignment] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
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
-
- 12 Jan, 2020 3 commits
-
-
Guo Ren authored
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: Guo 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: Paul Walmsley <paul.walmsley@sifive.com>
-
Yash Shah authored
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: Yash Shah <yash.shah@sifive.com> Reviewed-by: Anup 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: Paul Walmsley <paul.walmsley@sifive.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
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
-
- 11 Jan, 2020 2 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
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
-
git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linuxLinus Torvalds authored
Pull thread fixes from Christian Brauner: "This contains a series of patches to fix CLONE_SETTLS when used with clone3(). The clone3() syscall passes the tls argument through struct clone_args instead of a register. This means, all architectures that do not implement copy_thread_tls() but still support CLONE_SETTLS via copy_thread() expecting the tls to be located in a register argument based on clone() are currently unfortunately broken. Their tls value will be garbage. The patch series fixes this on all architectures that currently define __ARCH_WANT_SYS_CLONE3. It also adds a compile-time check to ensure that any architecture that enables clone3() in the future is forced to also implement copy_thread_tls(). My ultimate goal is to get rid of the copy_thread()/copy_thread_tls() split and just have copy_thread_tls() at some point in the not too distant future (Maybe even renaming copy_thread_tls() back to simply copy_thread() once the old function is ripped from all arches). This is dependent now on all arches supporting clone3(). While all relevant arches do that now there are still four missing: ia64, m68k, sh and sparc. They have the system call reserved, but not implemented. Once they all implement clone3() we can get rid of ARCH_WANT_SYS_CLONE3 and HAVE_COPY_THREAD_TLS. This series also includes a minor fix for the arm64 uapi headers which caused __NR_clone3 to be missing from the exported user headers. Unfortunately the series came in a little late especially given that it touches a range of architectures. Due to the holidays not all arch maintainers responded in time probably due to their backlog. Will and Arnd have thankfully acked the arm specific changes. Given that the changes are straightforward and rather minimal combined with the fact the that clone3() with CLONE_SETTLS is broken I decided to send them post rc3 nonetheless" * tag 'clone3-tls-v5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux: um: Implement copy_thread_tls clone3: ensure copy_thread_tls is implemented xtensa: Implement copy_thread_tls riscv: Implement copy_thread_tls parisc: Implement copy_thread_tls arm: Implement copy_thread_tls arm64: Implement copy_thread_tls arm64: Move __ARCH_WANT_SYS_CLONE3 definition to uapi headers
-
- 10 Jan, 2020 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hidLinus Torvalds authored
Pull HID fix from Jiri Kosina: "A regression fix for EPOLLOUT handling in hidraw and uhid" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: hidraw, uhid: Always report EPOLLOUT
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB/PHY fixes from Greg KH: "Here are a number of USB and PHY driver fixes for 5.5-rc6 Nothing all that unusual, just the a bunch of small fixes for a lot of different reported issues. The PHY driver fixes are in here as they interacted with the usb drivers. Full details of the patches are in the shortlog, and all of these have been in linux-next with no reported issues" * tag 'usb-5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (24 commits) usb: missing parentheses in USE_NEW_SCHEME usb: ohci-da8xx: ensure error return on variable error is set usb: musb: Disable pullup at init usb: musb: fix idling for suspend after disconnect interrupt usb: typec: ucsi: Fix the notification bit offsets USB: Fix: Don't skip endpoint descriptors with maxpacket=0 USB-PD tcpm: bad warning+size, PPS adapters phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz usb: chipidea: host: Disable port power only if previously enabled usb: cdns3: should not use the same dev_id for shared interrupt handler usb: dwc3: gadget: Fix request complete check usb: musb: dma: Correct parameter passed to IRQ handler usb: musb: jz4740: Silence error if code is -EPROBE_DEFER usb: udc: tegra: select USB_ROLE_SWITCH USB: core: fix check for duplicate endpoints phy: cpcap-usb: Drop extra write to usb2 register phy: cpcap-usb: Improve host vs docked mode detection phy: cpcap-usb: Prevent USB line glitches from waking up modem phy: mapphone-mdm6600: Fix uninitialized status value regression phy: cpcap-usb: Fix flakey host idling and enumerating of devices ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc fix from Greg KH: "Here is a single fix, for the chrdev core, for 5.5-rc6 There's been a long-standing race condition triggered by syzbot, and occasionally real people, in the chrdev open() path. Will finally took the time to track it down and fix it for real before the holidays. Here's that one patch, it's been in linux-next for a while with no reported issues and it does fix the reported problem" * tag 'char-misc-5.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: chardev: Avoid potential use-after-free in 'chrdev_open()'
-