- 27 Nov, 2018 40 commits
-
-
Mattias Jacobsson authored
commit f6501f49 upstream. Add another Apple Cinema Display to the list of supported displays Signed-off-by:
Mattias Jacobsson <2pi@mok.nu> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nathan Chancellor authored
commit 7c973012 upstream. After building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x3bf19a6): Section mismatch in reference from the function ssc_probe() to the function .init.text:atmel_ssc_get_driver_data() The function ssc_probe() references the function __init atmel_ssc_get_driver_data(). This is often because ssc_probe lacks a __init annotation or the annotation of atmel_ssc_get_driver_data is wrong. Remove __init from atmel_ssc_get_driver_data to get rid of the mismatch. Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Emmanuel Pescosta authored
commit a7711257 upstream. Following on from this patch: https://lkml.org/lkml/2017/11/3/516, Corsair K70 LUX RGB keyboards also require the DELAY_INIT quirk to start correctly at boot. Dmesg output: usb 1-6: string descriptor 0 read error: -110 usb 1-6: New USB device found, idVendor=1b1c, idProduct=1b33 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-6: can't set config #1, error -110 Signed-off-by:
Emmanuel Pescosta <emmanuelpescosta099@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Kai-Heng Feng authored
commit 781f0766 upstream. Devices connected under Terminus Technology Inc. Hub (1a40:0101) may fail to work after the system resumes from suspend: [ 206.063325] usb 3-2.4: reset full-speed USB device number 4 using xhci_hcd [ 206.143691] usb 3-2.4: device descriptor read/64, error -32 [ 206.351671] usb 3-2.4: device descriptor read/64, error -32 Info for this hub: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1a40 ProdID=0101 Rev=01.11 S: Product=USB 2.0 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub Some expirements indicate that the USB devices connected to the hub are innocent, it's the hub itself is to blame. The hub needs extra delay time after it resets its port. Hence wait for extra delay, if the device is connected to this quirky hub. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Kai-Heng Feng authored
commit deefd242 upstream. Raydium USB touchscreen fails to set config if LPM is enabled: [ 2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119 [ 2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.030660] usb 1-8: Product: Raydium Touch System [ 2.030661] usb 1-8: Manufacturer: Raydium Corporation [ 7.132209] usb 1-8: can't set config #1, error -110 Same behavior can be observed on 2386:3114. Raydium claims the touchscreen supports LPM under Windows, so I used Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows that the LPM doesn't work under Windows, either. So let's just disable LPM for Raydium touchscreens. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-toolsSigned-off-by:
-
Maarten Jacobs authored
commit 63529eaa upstream. The cdc-acm kernel module currently does not support the Hiro (Conexant) H05228 USB modem. The patch below adds the device specific information: idVendor 0x0572 idProduct 0x1349 Signed-off-by:
Maarten Jacobs <maarten256@outlook.com> Acked-by:
Oliver Neukum <oneukum@suse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Jimmy Assarsson authored
commit 95217260 upstream. If alloc_can_err_skb() fails, cf is never initialized. Move assignment of cf inside check. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jimmy Assarsson <jimmyassarsson@gmail.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Jimmy Assarsson authored
commit e13fb9b3 upstream. The call to can_put_echo_skb() may result in the skb being freed. The skb is later used in the call to dev->ops->dev_frame_to_cmd(). This is avoided by moving the call to can_put_echo_skb() after dev->ops->dev_frame_to_cmd(). Reported-by:
-
Takashi Iwai authored
commit d99501b8 upstream. We need to call pci_iounmap() instead of iounmap() for the regions obtained via pci_iomap() call for some archs that need special treatment. Fixes: aa31704f ("ALSA: hda/ca0132: Add PCI region2 iomap for SBZ") Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 563785ed upstream. HP Pavilion 15 (103c:820d) with ALC295 codec requires the quirk for the mute LED control over mic3 pin. Added the corresponding quirk entry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201653 Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dan Carpenter authored
commit 43279819 upstream. I was trying to solve a double free but I introduced a more serious NULL dereference bug. The problem is that if there is an IRQ which triggers immediately, then we need "info->uio_dev" but it's not set yet. This patch puts the original initialization back to how it was and just sets info->uio_dev to NULL on the error path so it should solve both the Oops and the double free. Fixes: f019f07e ("uio: potential double frees if __uio_register_device() fails") Reported-by:
Mathias Thore <Mathias.Thore@infinera.com> Signed-off-by:
-
Olof Johansson authored
commit 21f70d4a upstream. Sparse highlighted it, and appears to be a pure bug (from vs to). ./arch/riscv/include/asm/uaccess.h:403:35: warning: incorrect type in argument 1 (different address spaces) ./arch/riscv/include/asm/uaccess.h:403:39: warning: incorrect type in argument 2 (different address spaces) ./arch/riscv/include/asm/uaccess.h:409:37: warning: incorrect type in argument 1 (different address spaces) ./arch/riscv/include/asm/uaccess.h:409:41: warning: incorrect type in argument 2 (different address spaces) Signed-off-by:
Olof Johansson <olof@lixom.net> Cc: stable@vger.kernel.org Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
Aaro Koskinen authored
commit 82fba2df upstream. Re-enable OCTEON USB driver which is needed on older hardware (e.g. EdgeRouter Lite) for mass storage etc. This got accidentally deleted when config options were changed for OCTEON2/3 USB. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Paul Burton <paul.burton@mips.com> Fixes: f922bc0a ("MIPS: Octeon: cavium_octeon_defconfig: Enable more drivers") Patchwork: https://patchwork.linux-mips.org/patch/21077/ Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 4.14+ Signed-off-by:
-
Sakari Ailus authored
commit 92539d3e upstream. Patch ad608fbc changed how events were subscribed to address an issue elsewhere. As a side effect of that change, the "add" callback was called before the event subscription was added to the list of subscribed events, causing the first event queued by the add callback (and possibly other events arriving soon afterwards) to be lost. Fix this by adding the subscription to the list before calling the "add" callback, and clean up afterwards if that fails. Fixes: ad608fbc ("media: v4l: event: Prevent freeing event subscriptions while accessed") Reported-by:
Dave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Tested-by:
Hans Verkuil <hans.verkuil@cisco.com> Tested-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Kirill A. Shutemov authored
commit b082f2dd upstream Splitting out the sanity check in map_ldt_struct() moved page table syncing into a separate function, which made the pgd variable unused. Remove it. [ tglx: Massaged changelog ] Fixes: 9bae3197 ("x86/ldt: Split out sanity check in map_ldt_struct()") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Andy Lutomirski <luto@kernel.org> Cc: bp@alien8.de Cc: hpa@zytor.com Cc: dave.hansen@linux.intel.com Cc: peterz@infradead.org Cc: boris.ostrovsky@oracle.com Cc: jgross@suse.com Cc: bhe@redhat.com Cc: willy@infradead.org Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181026122856.66224-4-kirill.shutemov@linux.intel.comSigned-off-by:
Sasha Levin <sashal@kernel.org>
-
Kirill A. Shutemov authored
commit a0e6e083 upstream modify_ldt(2) leaves the old LDT mapped after switching over to the new one. The old LDT gets freed and the pages can be re-used. Leaving the mapping in place can have security implications. The mapping is present in the userspace page tables and Meltdown-like attacks can read these freed and possibly reused pages. It's relatively simple to fix: unmap the old LDT and flush TLB before freeing the old LDT memory. This further allows to avoid flushing the TLB in map_ldt_struct() as the slot is unmapped and flushed by unmap_ldt_struct() or has never been mapped at all. [ tglx: Massaged changelog and removed the needless line breaks ] Fixes: f55f0501 ("x86/pti: Put the LDT in its own PGD if PTI is on") Signed-off-by:
-
Kirill A. Shutemov authored
commit d52888aa upstream On 5-level paging the LDT remap area is placed in the middle of the KASLR randomization region and it can overlap with the direct mapping, the vmalloc or the vmap area. The LDT mapping is per mm, so it cannot be moved into the P4D page table next to the CPU_ENTRY_AREA without complicating PGD table allocation for 5-level paging. The 4 PGD slot gap just before the direct mapping is reserved for hypervisors, so it cannot be used. Move the direct mapping one slot deeper and use the resulting gap for the LDT remap area. The resulting layout is the same for 4 and 5 level paging. [ tglx: Massaged changelog ] Fixes: f55f0501 ("x86/pti: Put the LDT in its own PGD if PTI is on") Signed-off-by:
-
YueHaibing authored
[ Upstream commit 025911a5 ] There is no need to have the '__be32 *p' variable static since new value always be assigned before use it. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Cc: stable@vger.kernel.org Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit 8ef14c2c ] This reverts commit 6147b1cf. The reverted patch results in attempted write access to the source repository, even if that repository is mounted read-only. Output from "strace git status -uno --porcelain": getcwd("/tmp/linux-test", 129) = 16 open("/tmp/linux-test/.git/index.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = -1 EROFS (Read-only file system) While git appears to be able to handle this situation, a monitored build environment (such as the one used for Chrome OS kernel builds) may detect it and bail out with an access violation error. On top of that, the attempted write access suggests that git _will_ write to the file even if a build output directory is specified. Users may have the reasonable expectation that the source repository remains untouched in that situation. Fixes: 6147b1cf ("scripts/setlocalversion: git: Make -dirty check more robust" Cc: Genki Sky <sky@genki.is> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit bbcde0a7 ] Since commit b41d920a ("kbuild: deb-pkg: split generating packaging and build"), the build version of the kernel contained in a deb package is too low by 1. Prior to the bad commit, the kernel was built first, then the number in .version file was read out, and written into the debian control file. Now, the debian control file is created before the kernel is actually compiled, which is causing the version number mismatch. Let the mkdebian script pass KBUILD_BUILD_VERSION=${revision} to require the build system to use the specified version number. Fixes: b41d920a ("kbuild: deb-pkg: split generating packaging and build") Reported-by:
Doug Smythies <dsmythies@telus.net> Signed-off-by:
-
Dmitry Bogdanov authored
[ Upstream commit ad703c2b ] Packets with marked invalid IP/UDP/TCP checksums were considered as good by the driver. The error was in a logic, processing offload bits in RX descriptor. Signed-off-by:
Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by:
Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Igor Russkikh authored
[ Upstream commit bfaa9f85 ] Fixed a condition mistake due to which macvlans unicast item number 32 was not added in the unicast filter. The consequence is that when exactly 32 macvlans are created on NIC, the last created macvlan receives no traffic because its MAC was not registered in HW. Fixes: 94b3b542 ("net: aquantia: vlan unicast address list correct handling") Signed-off-by:
Nikita Danilov <nikita.danilov@aquantia.com> Signed-off-by:
-
Dmitry Bogdanov authored
[ Upstream commit 7a1bb494 ] IOMMU fault may occurr on unbind/bind or if_down/if_up sequence. Although driver disables the rings on down, this is not enough. Due to internal HW design, during subsequent initialization NIC sometimes may reuse RX descriptors cache and write to the host memory from the descriptor cache. That's get catched by IOMMU on host. This patch invalidates the descriptor cache in NIC on interface down to prevent writing to the cached descriptors and to the memory pointed in those descriptors. Signed-off-by:
-
Thor Thayer authored
[ Upstream commit 8137b6ef ] Ping problems with packets > 8191 as shown: PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data. 8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms wrong data byte 8144 should be 0xd0 but was 0x0 16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f %< ---------------snip-------------------------------------- 8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf 8144 0 0 0 0 d0 d1 ^^^^^^^ Notice the 4 bytes of 0 before the expected byte of d0. Databook notes that the RX buffer must be a multiple of 4/8/16 bytes [1]. Update the DMA Buffer size define to 8188 instead of 8192. Remove the -1 from the RX buffer size allocations and use the new DMA Buffer size directly. [1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a [section 8.4.2 - Table 8-24] Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets. Fixes: 286a8372 ("stmmac: add CHAINED descriptor mode support (V4)") Suggested-by:
Jose Abreu <jose.abreu@synopsys.com> Signed-off-by:
Thor Thayer <thor.thayer@linux.intel.com> Signed-off-by:
-
Sagiv Ozeri authored
[ Upstream commit fa5c448d ] A stuck ramrod should be deleted from the completion_pending list, otherwise it will be added again in the future and corrupt the list. Return error value to inform that ramrod is stuck and should be deleted. Signed-off-by:
Sagiv Ozeri <sagiv.ozeri@cavium.com> Signed-off-by:
Denis Bolotin <denis.bolotin@cavium.com> Signed-off-by:
-
Denis Bolotin authored
[ Upstream commit fb5e7438 ] qed_sp_destroy_request() API was added for SPQ users that need to free/return the entry they acquired in their error flows. Signed-off-by:
Michal Kalderon <michal.kalderon@cavium.com> Signed-off-by:
-
Denis Bolotin authored
[ Upstream commit 2632f22e ] When there are no SPQ entries left in the free_pool, new entries are allocated and are added to the unlimited list. When an entry in the pool is available, the content is copied from the original entry, and the new entry is sent to the device. qed_spq_post() is not aware of that, so the additional entry is stored in the original entry as p_post_ent, which can later be returned to the pool. Signed-off-by:
-
Denis Bolotin authored
[ Upstream commit 39477551 ] Free the allocated SPQ entry or return the acquired SPQ entry to the free list in error flows. Signed-off-by:
-
Jacob Keller authored
[ Upstream commit ba766b8b ] Since commit bacd75cf ("i40e/i40evf: Add capability exchange for outer checksum", 2017-04-06) the i40e driver has not reported support for IP-in-IP offloads. This likely occurred due to a bad rebase, as the commit extracts hw_enc_features into its own variable. As part of this change, it dropped the NETIF_F_FSO_IPXIP flags from the netdev->hw_enc_features. This was unfortunately not caught during code review. Fix this by adding back the missing feature flags. For reference, NETIF_F_GSO_IPXIP4 was added in commit 7e13318d ("net: define gso types for IPx over IPv4 and IPv6", 2016-05-20), replacing NETIF_F_GSO_IPIP and NETIF_F_GSO_SIT. NETIF_F_GSO_IPXIP6 was added in commit bf2d1df3 ("intel: Add support for IPv6 IP-in-IP offload", 2016-05-20). Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Chinh T Cao authored
[ Upstream commit ffe49823 ] Since the req_speeds field in struct ice_link_status is a u8, req_speeds & ICE_AQ_LINK_SPEED_40GB always returns 0. This was caught by a coverity scan. Fix this by changing req_speeds to be u16. Reported-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
Chinh T Cao <chinh.t.cao@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
-
Brett Creeley authored
[ Upstream commit d944b469 ] Currently if the driver does a TSO offload the bytecount sent to netdev_tx_sent_queue will be incorrect. This is because in ice_tso we overwrite the initial value that we set in ice_tx_map. This creates a mismatch between the Tx and Tx clean flow. In the Tx clean flow we calculate the bytecount (called total_bytes) as we clean the descriptors so the value used in the Tx clean path is correct. Fix this by using += in ice_tso instead of =. This fixes the mismatch in bytecount mentioned above. Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Signed-off-by:
-
Akeem G Abodunrin authored
[ Upstream commit 0f5d4c21 ] Setting Rx or Tx pause parameter currently results in link loss on the interface, requiring the platform/host to be cold power cycled. Fix it. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by:
-
Jiri Olsa authored
[ Upstream commit 8e88c29b ] Andi reported following malfunction: # perf record -e '{ref-cycles,cycles}:S' -a sleep 1 # perf script non matching sample_id_all That's because we disable sample_id_all bit for non-sampling group members. We can't do that, because it needs to be the same over the whole event list. This patch keeps it untouched again. Reported-by:
Andi Kleen <andi@firstfloor.org> Tested-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180923150420.27327-1-jolsa@kernel.org Fixes: e9add8ba ("perf evsel: Disable write_backward for leader sampling group events") Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Gustavo Romero authored
[ Upstream commit 6ac22262 ] Currently jvmti agent can not be used because function scnprintf is not present in the agent libperf-jvmti.so. As a result the JVM when using such agent to record JITed code profiling information will fail on looking up scnprintf: java: symbol lookup error: lib/libperf-jvmti.so: undefined symbol: scnprintf This commit fixes that by reverting to the use of snprintf, that can be looked up, instead of scnprintf, adding a proper check for the returned value in order to print a better error message when the jitdump file pathname is too long. Checking the returned value also helps to comply with some recent gcc versions, like gcc8, which will fail due to truncated writing checks related to the -Werror=format-truncation= flag. Signed-off-by:
Gustavo Romero <gromero@linux.vnet.ibm.com> Acked-by:
-
Valentin Schneider authored
[ Upstream commit 40fa3780 ] When running on linux-next (8c60c36d0b8c ("Add linux-next specific files for 20181019")) + CONFIG_PROVE_LOCKING=y on a big.LITTLE system (e.g. Juno or HiKey960), we get the following report: [ 0.748225] Call trace: [ 0.750685] lockdep_assert_cpus_held+0x30/0x40 [ 0.755236] static_key_enable_cpuslocked+0x20/0xc8 [ 0.760137] build_sched_domains+0x1034/0x1108 [ 0.764601] sched_init_domains+0x68/0x90 [ 0.768628] sched_init_smp+0x30/0x80 [ 0.772309] kernel_init_freeable+0x278/0x51c [ 0.776685] kernel_init+0x10/0x108 [ 0.780190] ret_from_fork+0x10/0x18 The static_key in question is 'sched_asym_cpucapacity' introduced by commit: df054e84 ("sched/topology: Add static_key for asymmetric CPU capacity optimizations") In this particular case, we enable it because smp_prepare_cpus() will end up fetching the capacity-dmips-mhz entry from the devicetree, so we already have some asymmetry detected when entering sched_init_smp(). This didn't get detected in tip/sched/core because we were missing: commit cb538267 ("jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations") Calls to build_sched_domains() post sched_init_smp() will hold the hotplug lock, it just so happens that this very first call is a special case. As stated by a comment in sched_init_smp(), "There's no userspace yet to cause hotplug operations" so this is a harmless warning. However, to both respect the semantics of underlying callees and make lockdep happy, take the hotplug lock in sched_init_smp(). This also satisfies the comment atop sched_init_domains() that says "Callers must hold the hotplug lock". Reported-by:
Sudeep Holla <sudeep.holla@arm.com> Tested-by:
Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dietmar.Eggemann@arm.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: morten.rasmussen@arm.com Cc: quentin.perret@arm.com Link: http://lkml.kernel.org/r/1540301851-3048-1-git-send-email-valentin.schneider@arm.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit 848bd3f3 ] We need to enable runtime PM on this i2c controller before populating child devices with i2c_add_adapter(). Otherwise, if a child device uses runtime PM and stays runtime PM enabled we'll get the following warning at boot. Enabling runtime PM for inactive device (a98000.i2c) with active children [...] Call trace: pm_runtime_enable+0xd8/0xf8 geni_i2c_probe+0x440/0x460 platform_drv_probe+0x74/0xc8 [...] Let's move the runtime PM enabling and setup to before we add the adapter, so that this device can respond to runtime PM requests from children. Fixes: 37692de5 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Vignesh R authored
[ Upstream commit 5b277402 ] Allow I2C_OMAP to be built for K3 platforms. Signed-off-by:
Vignesh R <vigneshr@ti.com> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 8f676b85 ] Whenever we update ns_head info, we need to make sure it is still compatible with all underlying backing devices because although nvme multipath doesn't have any explicit use of these limits, other devices can still be stacked on top of it which may rely on the underlying limits. Start with unlimited stacking limits, and every info update iterate over siblings and adjust queue limits. Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Robin Murphy authored
[ Upstream commit 6778be4e ] of_dma_configure() was *supposed* to be following the same logic as acpi_dma_configure() and only setting bus_dma_mask if some range was specified by the firmware. However, it seems that subtlety got lost in the process of fitting it into the differently-shaped control flow, and as a result the force_dma==true case ends up always setting the bus mask to the 32-bit default, which is not what anyone wants. Make sure we only touch it if the DT actually said so. Fixes: 6c2fb2ea ("of/device: Set bus DMA mask as appropriate") Reported-by:
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Tested-by:
John Stultz <john.stultz@linaro.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
Robert Richter <robert.richter@cavium.com> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Luis Henriques authored
[ Upstream commit 71f2cc64 ] This patch fixes a possible null pointer dereference in check_quota_exceeded, detected by the static checker smatch, with the following warning: fs/ceph/quota.c:240 check_quota_exceeded() error: we previously assumed 'realm' could be null (see line 188) Fixes: b7a29217 ("ceph: quota: support for ceph.quota.max_files") Reported-by:
Luis Henriques <lhenriques@suse.com> Reviewed-by:
"Yan, Zheng" <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
