summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-12PCI: Add Loongson vendor IDTiezhu Yang
Add the Loongson vendor ID to pci_ids.h to be used by the controller driver in the future. The Loongson vendor ID can be found at the following link: https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: cleanup comment for blk_flush_complete_seqGuoqing Jiang
Remove the comment about return value, since it is not valid after commit 404b8f5a03d84 ("block: cleanup kick/queued handling"). Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: remove unneeded argument from blk_alloc_flush_queueGuoqing Jiang
Remove 'q' from arguments since it is not used anymore after commit 7e992f847a08e ("block: remove non mq parts from the flush code"). Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: cleanup for _blk/blk_rq_prep_cloneGuoqing Jiang
Both cmd and sense had been moved to scsi_request, so remove the related comments to avoid confusion. And as Bart suggested, move _blk_rq_prep_clone into the only caller (blk_rq_prep_clone). Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: remove redundant setting of QUEUE_FLAG_DYINGGuoqing Jiang
Previously, blk_cleanup_queue has called blk_set_queue_dying to set the flag, no need to do it again. Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: use bio_{wouldblock,io}_error in direct_make_requestGuoqing Jiang
Use the two functions to simplify code. Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Reviewed-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: fix comment for blk_cloned_rq_check_limitsGuoqing Jiang
Since the later description mentioned "checked against the new queue limits", so make the change to avoid confusion. Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com> Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12lightnvm: pblk: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12block: aoe: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12libata: transport: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12rtlwifi: rtl8188ee: Fix regression due to commit d1d1a96bdb44Larry Finger
For some unexplained reason, commit d1d1a96bdb44 ("rtlwifi: rtl8188ee: Remove local configuration variable") broke at least one system. As the only net effect of the change was to remove 2 bytes from the start of struct phy_status_rpt, this patch adds 2 bytes of padding at the beginning of the struct. Fixes: d1d1a96bdb44 ("rtlwifi: rtl8188ee: Remove local configuration variable") Cc: Stable <stable@vger.kernel.org> # V5.4+ Reported-by: Ashish <ashishkumar.yadav@students.iiserpune.ac.in> Tested-by: Ashish <ashishkumar.yadav@students.iiserpune.ac.in> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-03-12blk-mq: insert flush request to the front of dispatch queueMing Lei
commit 01e99aeca397 ("blk-mq: insert passthrough request into hctx->dispatch directly") may change to add flush request to the tail of dispatch by applying the 'add_head' parameter of blk_mq_sched_insert_request. Turns out this way causes performance regression on NCQ controller because flush is non-NCQ command, which can't be queued when there is any in-flight NCQ command. When adding flush rq to the front of hctx->dispatch, it is easier to introduce extra time to flush rq's latency compared with adding to the tail of dispatch queue because of S_SCHED_RESTART, then chance of flush merge is increased, and less flush requests may be issued to controller. So always insert flush request to the front of dispatch queue just like before applying commit 01e99aeca397 ("blk-mq: insert passthrough request into hctx->dispatch directly"). Cc: Damien Le Moal <Damien.LeMoal@wdc.com> Cc: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> Fixes: 01e99aeca397 ("blk-mq: insert passthrough request into hctx->dispatch directly") Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12s390/dasd: fix data corruption for thin provisioned devicesStefan Haberland
Devices are formatted in multiple of tracks. For an Extent Space Efficient (ESE) volume we get errors when accessing unformatted tracks. In this case the driver either formats the track on the flight for write requests or returns zero data for read requests. In case a request spans multiple tracks, the indication of an unformatted track presented for the first track is incorrectly applied to all tracks covered by the request. As a result, tracks containing data will be handled as empty, resulting in zero data being returned on read, or overwriting existing data with zero on write. Fix by determining the track that gets the NRF error. For write requests only format the track that is surely not formatted. For Read requests all tracks before have returned valid data and should not be touched. All tracks after the unformatted track might be formatted or not. Those are returned to the blocklayer to build a new request. When using alias devices there is a chance that multiple write requests trigger a format of the same track which might lead to data loss. Ensure that a track is formatted only once by maintaining a list of currently processed tracks. Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12perf/amd/uncore: Replace manual sampling check with CAP_NO_INTERRUPT flagKim Phillips
Enable the sampling check in kernel/events/core.c::perf_event_open(), which returns the more appropriate -EOPNOTSUPP. BEFORE: $ sudo perf record -a -e instructions,l3_request_g1.caching_l3_cache_accesses true Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (l3_request_g1.caching_l3_cache_accesses). /bin/dmesg | grep -i perf may provide additional information. With nothing relevant in dmesg. AFTER: $ sudo perf record -a -e instructions,l3_request_g1.caching_l3_cache_accesses true Error: l3_request_g1.caching_l3_cache_accesses: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat' Fixes: c43ca5091a37 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters") Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Peter Zijlstra <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200311191323.13124-1-kim.phillips@amd.com
2020-03-12block: Fix use-after-free issue accessing struct io_cqSahitya Tummala
There is a potential race between ioc_release_fn() and ioc_clear_queue() as shown below, due to which below kernel crash is observed. It also can result into use-after-free issue. context#1: context#2: ioc_release_fn() __ioc_clear_queue() gets the same icq ->spin_lock(&ioc->lock); ->spin_lock(&ioc->lock); ->ioc_destroy_icq(icq); ->list_del_init(&icq->q_node); ->call_rcu(&icq->__rcu_head, icq_free_icq_rcu); ->spin_unlock(&ioc->lock); ->ioc_destroy_icq(icq); ->hlist_del_init(&icq->ioc_node); This results into below crash as this memory is now used by icq->__rcu_head in context#1. There is a chance that icq could be free'd as well. 22150.386550: <6> Unable to handle kernel write to read-only memory at virtual address ffffffaa8d31ca50 ... Call trace: 22150.607350: <2> ioc_destroy_icq+0x44/0x110 22150.611202: <2> ioc_clear_queue+0xac/0x148 22150.615056: <2> blk_cleanup_queue+0x11c/0x1a0 22150.619174: <2> __scsi_remove_device+0xdc/0x128 22150.623465: <2> scsi_forget_host+0x2c/0x78 22150.627315: <2> scsi_remove_host+0x7c/0x2a0 22150.631257: <2> usb_stor_disconnect+0x74/0xc8 22150.635371: <2> usb_unbind_interface+0xc8/0x278 22150.639665: <2> device_release_driver_internal+0x198/0x250 22150.644897: <2> device_release_driver+0x24/0x30 22150.649176: <2> bus_remove_device+0xec/0x140 22150.653204: <2> device_del+0x270/0x460 22150.656712: <2> usb_disable_device+0x120/0x390 22150.660918: <2> usb_disconnect+0xf4/0x2e0 22150.664684: <2> hub_event+0xd70/0x17e8 22150.668197: <2> process_one_work+0x210/0x480 22150.672222: <2> worker_thread+0x32c/0x4c8 Fix this by adding a new ICQ_DESTROYED flag in ioc_destroy_icq() to indicate this icq is once marked as destroyed. Also, ensure __ioc_clear_queue() is accessing icq within rcu_read_lock/unlock so that icq doesn't get free'd up while it is still using it. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Co-developed-by: Pradeep P V K <ppvk@codeaurora.org> Signed-off-by: Pradeep P V K <ppvk@codeaurora.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-03-12media: venus: support frame rate controlJeffrey Kardatzke
Add encoder control for enabling/disabling frame rate control via V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE. It is enabled by default. Signed-off-by: Jeffrey Kardatzke <jkardatzke@google.com> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12mmc: core: Respect MMC_CAP_NEED_RSP_BUSY for eMMC sleep commandUlf Hansson
The busy timeout for the CMD5 to put the eMMC into sleep state, is specific to the card. Potentially the timeout may exceed the host->max_busy_timeout. If that becomes the case, mmc_sleep() converts from using an R1B response to an R1 response, as to prevent the host from doing HW busy detection. However, it has turned out that some hosts requires an R1B response no matter what, so let's respect that via checking MMC_CAP_NEED_RSP_BUSY. Note that, if the R1B gets enforced, the host becomes fully responsible of managing the needed busy timeout, in one way or the other. Suggested-by: Sowjanya Komatineni <skomatineni@nvidia.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200311092036.16084-1-ulf.hansson@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-03-12staging: rtl8712: Fixes for simple typos in C commentsR Veera Kumar
Fixes for simple typos in C comments. Found using checkpatch.pl. Signed-off-by: R Veera Kumar <vkor@vkten.in> Link: https://lore.kernel.org/r/20200312091042.GA4246@tulip.local Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12USB: serial: pl2303: add device-id for HP LD381Scott Chen
Add a device id for HP LD381 Display LD381: 03f0:0f7f Signed-off-by: Scott Chen <scott@labau.com.tw> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-03-12USB: serial: option: add ME910G1 ECM composition 0x110bDaniele Palmas
Add ME910G1 ECM composition 0x110b: tty, tty, tty, ecm Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20200304104310.2938-1-dnlplm@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-03-12x86/cpu/amd: Call init_amd_zn() om Family 19h processors tooKim Phillips
Family 19h CPUs are Zen-based and still share most architectural features with Family 17h CPUs, and therefore still need to call init_amd_zn() e.g., to set the RECLAIM_DISTANCE override. init_amd_zn() also sets X86_FEATURE_ZEN, which today is only used in amd_set_core_ssb_state(), which isn't called on some late model Family 17h CPUs, nor on any Family 19h CPUs: X86_FEATURE_AMD_SSBD replaces X86_FEATURE_LS_CFG_SSBD on those later model CPUs, where the SSBD mitigation is done via the SPEC_CTRL MSR instead of the LS_CFG MSR. Family 19h CPUs also don't have the erratum where the CPB feature bit isn't set, but that code can stay unchanged and run safely on Family 19h. Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200311191451.13221-1-kim.phillips@amd.com
2020-03-12media: venus: vdec: Fix forgotten mutex unlock in start streamingStanimir Varbanov
This fixes the following smatch warning in the error path: drivers/media/platform/qcom/venus/vdec.c:968 vdec_start_streaming() warn: inconsistent returns 'mutex:&inst->lock'. Locked on: line 952 Unlocked on: line 963 line 968 by goto mutex unlock. Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12cpufreq: dt: Allow platform specific intermediate callbacksPeng Fan
Platforms may need to implement platform specific get_intermediate and target_intermediate hooks. Update cpufreq-dt driver's platform data to contain those for such platforms. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-03-12usb: phy: Add driver for the Ingenic JZ4770 USB transceiverPaul Cercueil
Add a driver to support the USB PHY found in the JZ4770 SoC from Ingenic. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20200229161820.17824-2-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12dt-bindings: Document JZ4770 PHY bindingsPaul Cercueil
Add documentation for the devicetree bindings of the Ingenic JZ4770 USB transceiver. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200229161820.17824-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12USB: EHCI: ehci-mv: use a unique bus nameLubomir Rintel
In case there are multiple Marvell EHCI blocks in system, we need a different bus name for each one. Otherwise debugfs gets mildly upset about a directory name in usb/ehci: debugfs: Directory 'mv ehci' with parent 'ehci' already present! Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200309130014.548168-2-lkundrak@v3.sk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12USB: EHCI: ehci-mv: switch the HSIC HCI to HSIC modeLubomir Rintel
Turns out the undocumented and reserved bits of port status/control register of the root port need to be set to use the HCI in HSIC mode. Typically the firmware does this, but that is not always good enough, because the bits get lost if the HSIC clock is disabled (e.g. when ehci-mv is build as a module). This supplements commit 7b104f890ade ("USB: EHCI: ehci-mv: add HSIC support"). Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200309130014.548168-1-lkundrak@v3.sk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12usb: typec: ucsi_ccg: workaround for NVIDIA test deviceAjay Gupta
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. NVIDIA test device FTB (Function Test Board) reports altmode list with vdo=0x3 first and then vdo=0x1. The list is: SVID VDO 0xff01 0xc05 0x28de 0x8085 0x955 0x3 0x955 0x1 Current logic to assign mode value is based on order in altmode list. This causes a mismatch of CON and SOP altmodes since NVIDIA GPU connector has order of vdo=0x1 first and then vdo=0x3. Fixing this by changing the order of vdo values reported by NVIDIA test device. the new list will be: SVID VDO 0xff01 0xc05 0x28de 0x8085 0x955 0x1085 0x955 0x3 Also NVIDIA VirtualLink (svid 0x955) uses pin E for display mode. NVIDIA test device reports vdo of 0x1 so make sure vdo values always have pin E assignement. Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200310121912.57879-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12USB: mon: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311093003.24604-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12media: lmedm04: remove redundant assignment to variable gateColin Ian King
The variable gate is being initialized and also checked and re-assigned with values that are never read as it is being re-assigned later in a for-loop with a new value. The assignments are redundant and can be removed. Addresses Coverity ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12media: tda10071: fix unsigned sign extension overflowColin Ian King
The shifting of buf[3] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an unsigned long. In the unlikely event that the the top bit of buf[3] is set then all then all the upper bits end up as also being set because of the sign-extension and this affect the ev->post_bit_error sum. Fix this by using the temporary u32 variable bit_error to avoid the sign-extension promotion. This also removes the need to do the computation twice. Addresses-Coverity: ("Unintended sign extension") Fixes: 267897a4708f ("[media] tda10071: implement DVBv5 statistics") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12usb: host: xhci-plat: add a shutdownRan Wang
When loading new kernel via kexec, we need to shutdown host controller to avoid any un-expected memory accessing during new kernel boot. Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Cc: stable <stable@vger.kernel.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12usb: typec: ucsi: displayport: Fix a potential race during registrationHeikki Krogerus
Locking the connector in ucsi_register_displayport() to make sure that nothing can access the displayport alternate mode before the function has finished and the alternate mode is actually ready. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200311130006.41288-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12usb: typec: ucsi: displayport: Fix NULL pointer dereferenceHeikki Krogerus
If the registration of the DisplayPort was not successful, or if the port does not support DisplayPort alt mode in the first place, the function ucsi_displayport_remove_partner() will fail with NULL pointer dereference when it attempts to access the driver data. Adding a check to the function to make sure there really is driver data for the device before modifying it. Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode") Reported-by: Andrea Gagliardi La Gala <andrea.lagala@gmail.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365 Cc: stable@vger.kernel.org Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200311130006.41288-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12USB: Disable LPM on WD19's Realtek HubKai-Heng Feng
Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the bus when bringing underlying ports from U3 to U0. Disabling LPM on the hub during setting link state is not enough, so let's disable LPM completely for this hub. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200205112633.25995-3-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12Staging: rtl8188eu: rtw_mlme: Add space around operatorsShreeya Patel
Add space around operators for improving the code readability. Reported by checkpatch.pl git diff -w shows no difference. diff of the .o files before and after the changes shows no difference. Signed-off-by: Shreeya Patel <shreeya.patel23498@gmail.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Link: https://lore.kernel.org/r/20200311131742.31068-1-shreeya.patel23498@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12thunderbolt: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-03-12media: dw2102: probe for demodulator i2c addressBrad Love
This is required to support the Terratec S2 USB Box Revision 4, which reused usb vid:pid, but has a different demodulator (m88ds3103b) at i2c address 0x6a. [fixed checkpatch issues] Signed-off-by: Michael Bunk <micha@freedict.org> Signed-off-by: Brad Love <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12media: em28xx: Enable Hauppauge 461e rev2Brad Love
Hauppauge 461e rev2 is a DVB-S/S2 usb device containing: - m88ds3103b demod - ts2022 tuner - A8293 SEC Device is the same as Hauppauge 461e, except it contains updated m88ds3103b demod. Signed-off-by: Brad Love <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12media: m88ds3103: Add support for ds3103b demodBrad Love
The ds3103b demodulator identifies as an m88rs600, but requires different clock settings and firmware, along with differences in register settings. Changes were reverse engineered using an instrumented downstream GPLv2 driver to compare i2c traffic and clocking. The mclk functions are from the downstream GPLv2 driver. Signed-off-by: Brad Love <brad@nextdimension.cc> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12staging: rtl8723bs: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311092451.23933-4-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12staging: rtl8192e: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311092451.23933-3-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12staging: rtl8188eu: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311092451.23933-2-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12staging: most: core: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20200311091944.23185-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12staging: wilc1000: updated DT binding documentationAjay Singh
Merged the DT binding documentation of SDIO and SPI into a single file. Removed documentation for some of the properties which are not required and handled review comments received in [1] & [2]. [1]. https://lore.kernel.org/linux-wireless/20200303020230.GA15543@bogus [2]. https://lore.kernel.org/linux-wireless/20200303015558.GA6876@bogus Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Link: https://lore.kernel.org/r/20200307085523.7320-4-ajay.kathat@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12staging: wilc1000: modified 'clock-names' and 'compatible' propertyAjay Singh
Modified the 'clock-names' property by removing '_clk' from its name and remove '_spi/sdio' from 'compatible' string. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Link: https://lore.kernel.org/r/20200307085523.7320-3-ajay.kathat@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12staging: wilc1000: use 'interrupts' property instead of 'irq-gpio'Ajay Singh
Make use of 'interrupts' property instead of using gpio for handling the interrupt as suggested in [1]. [1]. https://lore.kernel.org/linux-wireless/20200303015558.GA6876@bogus Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Link: https://lore.kernel.org/r/20200307085523.7320-2-ajay.kathat@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-12media: rc: make scancodes 64 bitSean Young
There are many protocols that encode more than 32 bit. We want 64 bit support so that BPF IR decoders can decode more than 32 bit. None of the existing kernel IR decoders/encoders support 64 bit, for now. The MSC_SCAN event can only contain 32 bit scancodes, so we only generate MSC_SCAN events if the scancode fits into 32 bits. The full 64 bit scancode can be read from the lirc chardev. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-12misc: eeprom: at24: fix regulator underflowMichael Auchter
The at24 driver attempts to read a byte from the device to validate that it's actually present, and if not, disables the vcc regulator and returns -ENODEV. However, between the read and the error handling path, pm_runtime_idle() is called and invokes the driver's suspend callback, which also disables the vcc regulator. This leads to an underflow of the regulator enable count if the EEPROM is not present. Move the pm_runtime_suspend() call to be after the error handling path to resolve this. Fixes: cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") Signed-off-by: Michael Auchter <michael.auchter@ni.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2020-03-12net: mvmdio: avoid error message for optional IRQChris Packham
Per the dt-binding the interrupt is optional so use platform_get_irq_optional() instead of platform_get_irq(). Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()") platform_get_irq() produces an error message orion-mdio f1072004.mdio: IRQ index 0 not found which is perfectly normal if one hasn't specified the optional property in the device tree. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-16 02:41:23 +0000