- 24 3月, 2020 9 次提交
-
-
由 Wolfram Sang 提交于
Currently, select_tuning() is called after RPM resume. But select_tuning() needs some additional function calls to work correctly. Instead of reimplementing the whole postprocessing, just enforce retuning. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200129203709.30493-5-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
check_scc_error() is too Renesas specific. Let's just call it check_retune() to make it also easier understandable what it does. Only a rename, no functional change. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200129203709.30493-4-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
When the tap array in the driver is too low, this is not a warning but an error. Also _once is not helpful, we should make sure it is prominently in the logs. It is safe to do this because this will only show up during SoC enablement when we a new SoCs needs more taps (if that ever will happen). Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200129203709.30493-3-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
Move Renesas specific code for executing the tuning with a SCC into the SDHI driver and leave only a generic call in the TMIO driver. Simplify the code a little by removing init_tuning() and prepare_tuning() callbacks. The latter is directly folded into the new execute_tuning() callbacks. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200129203709.30493-2-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
Use increasing BIT numbers consistently and remove some superfluous comments. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20191217114034.13290-6-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
HW engineers say that automatic tap correction cannot be used for HS400 in all R-Car Gen3 SoCs. So, check for that SDHI variant and disable it when HS400 is about to be enabled. Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20191217114034.13290-5-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Takeshi Saito 提交于
R-Car Gen3 cannot use correction error status with HS400. HS200: CMD and DAT signal timing are based on CLK signal. HS400: CMD signal is based on CLK. DAT signal is based on DS signal. In HS400, CMD signal is 200MHz(SDR). DAT signal is 200MHz(DDR). Center position of signal is different between CMD and DAT. TAP position should be adjusted to the center position of CMD signal. DAT sampling timing is adjusted by HS400 calibration circuit regardless of TAP position. Refer to renesas_sdhi_adjust_hs400mode_enable(). However, correction error status contains CMD and DAT status in HS400 (DAT signal is not masked in HS400). Therefore, correction error status cannot use in HS400. It means that auto correction cannot be uses in HS400. Manual correction can change to the correct TAP position by ignoring DAT correction error status and using only CMD correction status. Signed-off-by: NTakeshi Saito <takeshi.saito.xv@renesas.com> [wsa: refactored patch from BSP] Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20191217114034.13290-4-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Takeshi Saito 提交于
This patch adds a manual correction mechanism for SDHI. Currently, SDHI uses automatic TAP position correction. However, TAP position can also be corrected manually via correction error status flags. Signed-off-by: NTakeshi Saito <takeshi.saito.xv@renesas.com> Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20191217114034.13290-3-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
hw_reset() clears the automatic correction bit twice. I couldn't find anything in the docs recommending that. Removing one of them didn't cause any regressions here, so keep it simple. Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20191217114034.13290-2-wsa+renesas@sang-engineering.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 22 3月, 2020 1 次提交
-
-
由 Joerg Roedel 提交于
Commit 3f8fd02b ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()") introduced a call to vmalloc_sync_all() in the vunmap() code-path. While this change was necessary to maintain correctness on x86-32-pae kernels, it also adds additional cycles for architectures that don't need it. Specifically on x86-64 with CONFIG_VMAP_STACK=y some people reported severe performance regressions in micro-benchmarks because it now also calls the x86-64 implementation of vmalloc_sync_all() on vunmap(). But the vmalloc_sync_all() implementation on x86-64 is only needed for newly created mappings. To avoid the unnecessary work on x86-64 and to gain the performance back, split up vmalloc_sync_all() into two functions: * vmalloc_sync_mappings(), and * vmalloc_sync_unmappings() Most call-sites to vmalloc_sync_all() only care about new mappings being synchronized. The only exception is the new call-site added in the above mentioned commit. Shile Zhang directed us to a report of an 80% regression in reaim throughput. Fixes: 3f8fd02b ("mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()") Reported-by: Nkernel test robot <oliver.sang@intel.com> Reported-by: NShile Zhang <shile.zhang@linux.alibaba.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Tested-by: NBorislav Petkov <bp@suse.de> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [GHES] Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20191009124418.8286-1-joro@8bytes.org Link: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/4D3JPPHBNOSPFK2KEPC6KGKS6J25AIDB/ Link: http://lkml.kernel.org/r/20191113095530.228959-1-shile.zhang@linux.alibaba.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 3月, 2020 1 次提交
-
-
由 Sagi Grimberg 提交于
When we send PDU data, we want to optimize the tcp stack operation if we have more data to send. So when we set MSG_MORE when: - We have more fragments coming in the batch, or - We have a more data to send in this PDU - We don't have a data digest trailer - We optimize with the SUCCESS flag and omit the NVMe completion (used if sq_head pointer update is disabled) This addresses a regression in QD=1 with SUCCESS flag optimization as we unconditionally set MSG_MORE when we didn't actually have more data to send. Fixes: 70583295 ("nvmet-tcp: implement C2HData SUCCESS optimization") Reported-by: NMark Wunderlich <mark.wunderlich@intel.com> Tested-by: NMark Wunderlich <mark.wunderlich@intel.com> Signed-off-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NKeith Busch <kbusch@kernel.org>
-
- 20 3月, 2020 2 次提交
-
-
由 Mario Kleiner 提交于
Commit '16f17eda ("drm/amd/display: Send vblank and user events at vsartup for DCN")' introduces a new way of pageflip completion handling for DCN, and some trouble. The current implementation introduces a race condition, which can cause pageflip completion events to be sent out one vblank too early, thereby confusing userspace and causing flicker: prepare_flip_isr(): 1. Pageflip programming takes the ddev->event_lock. 2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED 3. Releases ddev->event_lock. --> Deadline for surface address regs double-buffering passes on target pipe. 4. dc_commit_updates_for_stream() MMIO programs the new pageflip into hw, but too late for current vblank. => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete in current vblank due to missing the double-buffering deadline by a tiny bit. 5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires, dm_dcn_crtc_high_irq() gets called. 6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the pageflip has been completed/will complete in this vblank and sends out pageflip completion event to userspace and resets pflip_status = AMDGPU_FLIP_NONE. => Flip completion event sent out one vblank too early. This behaviour has been observed during my testing with measurement hardware a couple of time. The commit message says that the extra flip event code was added to dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events in case the pflip irq doesn't fire, because the "DCH HUBP" component is clock gated and doesn't fire pflip irqs in that state. Also that this clock gating may happen if no planes are active. This suggests that the problem addressed by that commit can't happen if planes are active. The proposed solution is therefore to only execute the extra pflip completion code iff the count of active planes is zero and otherwise leave pflip completion handling to the pflip irq handler, for a more race-free experience. Note that i don't know if this fixes the problem the original commit tried to address, as i don't know what the test scenario was. It does fix the observed too early pageflip events though and points out the problem introduced. Fixes: 16f17eda ("drm/amd/display: Send vblank and user events at vsartup for DCN") Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Corentin Labbe 提交于
I have hit the following build error: armv7a-hardfloat-linux-gnueabi-ld: drivers/rtc/rtc-max8907.o: in function `max8907_rtc_probe': rtc-max8907.c:(.text+0x400): undefined reference to `regmap_irq_get_virq' max8907 should select REGMAP_IRQ Fixes: 94c01ab6 ("rtc: add MAX8907 RTC driver") Cc: stable <stable@vger.kernel.org> Signed-off-by: NCorentin Labbe <clabbe@baylibre.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 19 3月, 2020 3 次提交
-
-
由 James Zhu 提交于
fix typo for vcn2.5/jpeg2.5 idle check Signed-off-by: NJames Zhu <James.Zhu@amd.com> Reviewed-by: NLeo Liu <leo.liu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 James Zhu 提交于
fix typo for vcn2/jpeg2 idle check Signed-off-by: NJames Zhu <James.Zhu@amd.com> Reviewed-by: NLeo Liu <leo.liu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 James Zhu 提交于
fix typo for vcn1 idle check Signed-off-by: NJames Zhu <James.Zhu@amd.com> Reviewed-by: NLeo Liu <leo.liu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 18 3月, 2020 13 次提交
-
-
由 Qiujun Huang 提交于
drm_lease_create takes ownership of leases. And leases will be released by drm_master_put. drm_master_put ->drm_master_destroy ->idr_destroy So we needn't call idr_destroy again. Reported-and-tested-by: syzbot+05835159fe322770fe3d@syzkaller.appspotmail.com Signed-off-by: NQiujun Huang <hqjagain@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjagain@gmail.com
-
由 Eric Biggers 提交于
Commit 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start checking for the presence of the ->set_serial function pointer rather than ->get_serial. This appears to be a copy-and-paste error, since ->get_serial is the function pointer that is called as well as the pointer that is checked by the non-compat version of TIOCGSERIAL. Fix this by checking the correct function pointer. Fixes: 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: NEric Biggers <ebiggers@google.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Eric Biggers 提交于
Commit 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start copying a whole 'serial_struct32' to userspace rather than individual fields, but failed to initialize all padding and fields -- namely the hole after the 'iomem_reg_shift' field, and the 'reserved' field. Fix this by initializing the struct to zero. [v2: use sizeof, and convert the adjacent line for consistency.] Reported-by: syzbot+8da9175e28eadcb203ce@syzkaller.appspotmail.com Fixes: 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: NEric Biggers <ebiggers@google.com> Acked-by: NJiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-2-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Eric Biggers 提交于
The current version of the TTY code unlocks the tty_struct(s) before release_tty() rather than after. Moreover, tty_unlock_pair() no longer exists. Thus, remove the outdated comments regarding tty_unlock_pair(). Signed-off-by: NEric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20200224073359.292795-1-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Ricky Wu 提交于
The TX/RX register should not be treated the same way to allow for better support of tuning. Fix this by using a default initial value for TX. Signed-off-by: NRicky Wu <ricky_wu@realtek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com [Ulf: Updated changelog] Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shishkin 提交于
This adds support for the Trace Hub in Elkhart Lake CPU. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200317062215.15598-7-alexander.shishkin@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shishkin 提交于
There are a few places in the driver that end up returning ENOTSUPP to the user, replace those with EINVAL. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: ba82664c ("intel_th: Add Memory Storage Unit driver") Cc: stable@vger.kernel.org # v4.4+ Link: https://lore.kernel.org/r/20200317062215.15598-6-alexander.shishkin@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shishkin 提交于
The unexpected state warning should only warn on illegal state transitions. Fix that. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: 615c164d ("intel_th: msu: Introduce buffer interface") Cc: stable@vger.kernel.org # v5.4+ Link: https://lore.kernel.org/r/20200317062215.15598-5-alexander.shishkin@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Shishkin 提交于
The operands of time_after() are in a wrong order in both instances in the sys-t driver. Fix that. Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Fixes: 39f10239 ("stm class: p_sys-t: Add support for CLOCKSYNC packets") Fixes: d69d5e83 ("stm class: Add MIPI SyS-T protocol support") Cc: stable@vger.kernel.org # v4.20+ Link: https://lore.kernel.org/r/20200317062215.15598-3-alexander.shishkin@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Anthony Mallet 提交于
By default, tty_port_init() initializes those parameters to a multiple of HZ. For instance in line 69 of tty_port.c: port->close_delay = (50 * HZ) / 100; https://github.com/torvalds/linux/blob/master/drivers/tty/tty_port.c#L69 With e.g. CONFIG_HZ = 250 (as this is the case for Ubuntu 18.04 linux-image-4.15.0-37-generic), the default setting for close_delay is thus 125. When ioctl(fd, TIOCGSERIAL, &s) is executed, the setting returned in user space is '12' (125/10). When ioctl(fd, TIOCSSERIAL, &s) is then executed with the same setting '12', the value is interpreted as '120' which is different from the current setting and a EPERM error may be raised by set_serial_info() if !CAP_SYS_ADMIN. https://github.com/torvalds/linux/blob/master/drivers/usb/class/cdc-acm.c#L919 Fixes: ba2d8ce9 ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Signed-off-by: NAnthony Mallet <anthony.mallet@laas.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312133101.7096-2-anthony.mallet@laas.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Anthony Mallet 提交于
close_delay and closing_wait are specified in hundredth of a second but stored internally in jiffies. Use the jiffies_to_msecs() and msecs_to_jiffies() functions to convert from each other. Signed-off-by: NAnthony Mallet <anthony.mallet@laas.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312133101.7096-1-anthony.mallet@laas.frSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
We have been receiving bug reports that ethernet connections over RTL8153 based ethernet adapters stops working after a while with errors like these showing up in dmesg when the ethernet stops working: [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1 docks and with generic USB to ethernet dongles using the RTL8153 chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to the kernel commandline and all users who have tried this report that this fixes this. Also note that we already have an existing NO_LPM quirk for the RTL8153 used in the Microsoft Surface Dock (where it uses a different usb-id). This commit adds a NO_LPM quirk for the generic Realtek RTL8153 0bda:8153 usb-id, fixing the Tx timeout errors on these devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931 Cc: stable@vger.kernel.org Cc: russianneuromancer@ya.ru Signed-off-by: NHans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20200313120708.100339-1-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Peter Chen 提交于
The code calls pm_runtime_get_sync with irq disabled, it causes below warning: BUG: sleeping function called from invalid context at wer/runtime.c:1075 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: er/u8:1 CPU: 1 PID: 37 Comm: kworker/u8:1 Not tainted 20200304-00181-gbebfd2a5be98 #1588 Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) Workqueue: ci_otg ci_otg_work [<c010e8bd>] (unwind_backtrace) from [<c010a315>] 1/0x14) [<c010a315>] (show_stack) from [<c0987d29>] 5/0x94) [<c0987d29>] (dump_stack) from [<c013e77f>] +0xeb/0x118) [<c013e77f>] (___might_sleep) from [<c052fa1d>] esume+0x75/0x78) [<c052fa1d>] (__pm_runtime_resume) from [<c0627a33>] 0x23/0x74) [<c0627a33>] (ci_udc_pullup) from [<c062fb93>] nect+0x2b/0xcc) [<c062fb93>] (usb_gadget_connect) from [<c062769d>] _connect+0x59/0x104) [<c062769d>] (ci_hdrc_gadget_connect) from [<c062778b>] ssion+0x43/0x48) [<c062778b>] (ci_udc_vbus_session) from [<c062f997>] s_connect+0x17/0x9c) [<c062f997>] (usb_gadget_vbus_connect) from [<c062634d>] bd/0x128) [<c062634d>] (ci_otg_work) from [<c0134719>] rk+0x149/0x404) [<c0134719>] (process_one_work) from [<c0134acb>] 0xf7/0x3bc) [<c0134acb>] (worker_thread) from [<c0139433>] x118) [<c0139433>] (kthread) from [<c01010bd>] (ret_from_fork+0x11/0x34) Tested-by: NDmitry Osipenko <digetx@gmail.com> Cc: <stable@vger.kernel.org> #v5.5 Fixes: 72dc8df7 ("usb: chipidea: udc: protect usb interrupt enable") Reported-by: NDmitry Osipenko <digetx@gmail.com> Signed-off-by: NPeter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20200316031034.17847-2-peter.chen@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 3月, 2020 9 次提交
-
-
由 Michael Straube 提交于
This device was added to the stand-alone driver on github. Add it to the staging driver as well. Link: https://github.com/lwfinger/rtl8188eu/commit/2141f244c3e7Signed-off-by: NMichael Straube <straube.linux@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312093652.13918-1-straube.linux@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Newer GCC warns about possible truncations of two generated path names as we're concatenating the configurable sysfs and debugfs path prefixes with a filename and placing the results in buffers of the same size as the maximum length of the prefixes. snprintf(d->name, MAX_STR_LEN, "gb_loopback%u", dev_id); snprintf(d->sysfs_entry, MAX_SYSFS_PATH, "%s%s/", t->sysfs_prefix, d->name); snprintf(d->debugfs_entry, MAX_SYSFS_PATH, "%sraw_latency_%s", t->debugfs_prefix, d->name); Fix this by separating the maximum path length from the maximum prefix length and reducing the latter enough to fit the generated strings. Note that we also need to reduce the device-name buffer size as GCC isn't smart enough to figure out that we ever only used MAX_STR_LEN bytes of it. Fixes: 6b0658f6 ("greybus: tools: Add tools directory to greybus repo and add loopback") Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200312110151.22028-4-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Newer GCC warns about a possible truncation of a generated sysfs path name as we're concatenating a directory path with a file name and placing the result in a buffer that is half the size of the maximum length of the directory path (which is user controlled). loopback_test.c: In function 'open_poll_files': loopback_test.c:651:31: warning: '%s' directive output may be truncated writing up to 511 bytes into a region of size 255 [-Wformat-truncation=] 651 | snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count"); | ^~ loopback_test.c:651:3: note: 'snprintf' output between 16 and 527 bytes into a destination of size 255 651 | snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by making sure the buffer is large enough the concatenated strings. Fixes: 6b0658f6 ("greybus: tools: Add tools directory to greybus repo and add loopback") Fixes: 9250c0ee ("greybus: Loopback_test: use poll instead of inotify") Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200312110151.22028-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
A scripted conversion from userland POLL* to kernel EPOLL* constants mistakingly replaced the poll flags in the loopback_test tool, which therefore no longer builds. Fixes: a9a08845 ("vfs: do bulk POLL* -> EPOLL* replacement") Cc: stable <stable@vger.kernel.org> # 4.16 Signed-off-by: NJohan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200312110151.22028-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Michał Mirosław 提交于
SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least SAMA5D27 doesn't). Fix this by forcing card-detect in the module if module-controlled CD is not used. Fixed commit addresses the problem only for non-removable cards. This amends it to also cover gpio-cd case. Cc: stable@vger.kernel.org Fixes: 7a1e3f14 ("mmc: sdhci-of-at91: force card detect value for non removable devices") Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.plSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Masahiro Yamada 提交于
The SDHCI_PRESET_FOR_* registers are not set for the UniPhier platform integration. (They are all read as zeros). Set the SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk flag. Otherwise, the High Speed DDR mode on the eMMC controller (MMC_TIMING_MMC_DDR52) would not work. I split the platform data to give no impact to other platforms, although the UniPhier platform is currently only the upstream user of this IP. The SDHCI_QUIRK2_PRESET_VALUE_BROKEN flag is set if the compatible string matches to "socionext,uniphier-sd4hc". Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200312104257.21017-1-yamada.masahiro@socionext.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Hans de Goede 提交于
On the Acer Aspire Switch 10 (SW5-012) microSD slot always reports the card being write-protected even though microSD cards do not have a write-protect switch at all. Add a new DMI_QUIRK_SD_NO_WRITE_PROTECT quirk which when set sets the MMC_CAP2_NO_WRITE_PROTECT flag on the controller for the external SD slot; and add a DMI quirk table entry which selects this quirk for the Acer SW5-012. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200316184753.393458-2-hdegoede@redhat.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Hans de Goede 提交于
mmc: sdhci-acpi: Switch signal voltage back to 3.3V on suspend on external microSD on Lenovo Miix 320 Based on a sample of 7 DSDTs from Cherry Trail devices using an AXP288 PMIC depending on the design one of 2 possible LDOs on the PMIC is used for the MMC signalling voltage, either DLDO3 or GPIO1LDO (GPIO1 pin in low noise LDO mode). The Lenovo Miix 320-10ICR uses GPIO1LDO in the SHC1 ACPI device's DSM methods to set 3.3 or 1.8 signalling voltage and this appears to work as advertised, so presumably the device is actually using GPIO1LDO for the external microSD signalling voltage. But this device has a bug in the _PS0 method of the SHC1 ACPI device, the DSM remembers the last set signalling voltage and the _PS0 restores this after a (runtime) suspend-resume cycle, but it "restores" the voltage on DLDO3 instead of setting it on GPIO1LDO as the DSM method does. DLDO3 is used for the LCD and setting it to 1.8V causes the LCD to go black. This commit works around this issue by calling the Intel DSM to reset the signal voltage to 3.3V after the host has been runtime suspended. This will make the _PS0 method reprogram the DLDO3 voltage to 3.3V, which leaves it at its original setting fixing the LCD going black. This commit adds and uses a DMI quirk mechanism to only trigger this workaround on the Lenovo Miix 320 while leaving the behavior of the driver unchanged on other devices. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=111294 BugLink: https://gitlab.freedesktop.org/drm/intel/issues/355Reported-by: Nrussianneuromancer <russianneuromancer@ya.ru> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200316184753.393458-1-hdegoede@redhat.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Tony Fischetti 提交于
A lenovo pixart mouse (17ef:608d) is afflicted common the the malfunction where it disconnects and reconnects every minute--each time incrementing the device number. This patch adds the device id of the device and specifies that it needs the HID_QUIRK_ALWAYS_POLL quirk in order to work properly. Signed-off-by: NTony Fischetti <tony.fischetti@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 16 3月, 2020 2 次提交
-
-
由 Chen-Tsung Hsieh 提交于
Add 1 additional hammer-like device. Signed-off-by: NChen-Tsung Hsieh <chentsung@chromium.org> Reviewed-by: NNicolas Boichat <drinkcat@chromium.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Matt Roper 提交于
The bspec documents multiple MCR ranges; make sure they're all captured by the driver. Bspec: 13991, 52079 Fixes: 592a7c5e ("drm/i915: Extend non readable mcr range") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-2-matthew.d.roper@intel.comReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> (cherry picked from commit 415d1269) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-