- 01 Dec, 2019 40 commits
-
-
Christoph Hellwig authored
[ Upstream commit 3a5bd702 ] We can't just transfer ownership to the CPU and then unmap, as this will break with swiotlb. Instead unmap the command and sense buffer a little earlier in the I/O completion handler and get rid of the pci_dma_sync_sg_for_cpu call entirely. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marcel Ziswiler authored
[ Upstream commit a85227da ] Similar to the following: commit 43217236 ("ASoC: tegra_alc5632: fix device_node refcounting") commit 7c5dfd54 ("ASoC: tegra: fix device_node refcounting") Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Acked-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 7fa75007 ] The allocation for the audio pmc is using the size of struct clk_audio_pad instead of struct clk_audio_pmc. This works fine because the former is larger than the latter but it is safer to be correct. Fixes: ("0865805d clk: at91: add audio pll clock drivers") Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit 4917fb90 ] A typo that makes it impossible to get the correct clocks for MMP2_CLK_SDH2 and MMP2_CLK_SDH3. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Fixes: 1ec770d9 ("clk: mmp: add mmp2 DT support for clock driver") Signed-off-by:
-
Honghui Zhang authored
[ Upstream commit 3828d60f ] Commit 43e6409d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") added MSI support but enabled MSI in the wrong place, at a step in the probe sequence where clocks were not still enabled. Fix this issue by calling mtk_pcie_enable_msi() in mtk_pcie_startup_port_v2() since clocks are enabled when mtk_pcie_startup_port_v2() is called. To avoid forward declaration of mtk_pcie_enable_msi(), move the mtk_pcie_startup_port_v2() function definition in the file. Fixes: 43e6409d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by:
Honghui Zhang <honghui.zhang@mediatek.com> [lorenzo.pieralisi@arm.com: squashed commit and adapted log] Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit cb4bfda6 ] A removal waits for the reset_work to complete. If a surprise removal occurs around the same time as an error triggered controller reset, and reset work happened to dispatch a command to the removed controller, the command won't be recovered since the timeout work doesn't do anything during error recovery. We wouldn't want to wait for timeout handling anyway, so this patch fixes this by disabling the controller and killing admin queues prior to syncing with the reset_work. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 1216e9ef ] Building with W=1 enables the compiler warning -Wimplicit-fallthrough=3. That option does not recognize the fall-through comment in the fcloop driver. Add a fall-through comment that is recognized for -Wimplicit-fallthrough=3. This patch avoids that the compiler reports the following warning when building with W=1: drivers/nvme/target/fcloop.c:647:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (op == NVMET_FCOP_READDATA) ^ Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 8eacd1bd ] Although I'm not sure whether it is a good idea to support large discard commands, I think integer overflow for discard ranges larger than 4 GB should be avoided. This patch avoids that smatch reports the following: drivers/nvme/target/io-cmd-file.c:249:1 nvmet_file_execute_discard() warn: should '((range.nlb)) << req->ns->blksize_shift' be a 64 bit type? Fixes: d5eff33e ("nvmet: add simple file backed ns support") Signed-off-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 18e732b8 ] Clang warns when one enumerated type is implicitly converted to another and this happens in several locations in this driver, ultimately related to the set_cipher_{mode,config0} functions. set_cipher_mode expects a mode of type drv_cipher_mode and set_cipher_config0 expects a mode of type drv_crypto_direction. drivers/crypto/ccree/cc_ivgen.c:58:35: warning: implicit conversion from enumeration type 'enum cc_desc_direction' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(&iv_seq[idx], DESC_DIRECTION_ENCRYPT_ENCRYPT); drivers/crypto/ccree/cc_hash.c:99:28: warning: implicit conversion from enumeration type 'enum cc_hash_conf_pad' to different enumeration type 'enum drv_crypto_direction' [-Wenum-conversion] set_cipher_config0(desc, HASH_DIGEST_RESULT_LITTLE_ENDIAN); drivers/crypto/ccree/cc_aead.c:1643:30: warning: implicit conversion from enumeration type 'enum drv_hash_hw_mode' to different enumeration type 'enum drv_cipher_mode' [-Wenum-conversion] set_cipher_mode(&desc[idx], DRV_HASH_HW_GHASH); Since this fundamentally isn't a problem because these values just represent simple integers for a shift operation, make it clear to Clang that this is okay by making the mode parameter in both functions an int. Link: https://github.com/ClangBuiltLinux/linux/issues/46Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Gilad Ben-Yossef <gilad@benyossef.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 20054597 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/iscsi_tcp.c:803:15: warning: implicit conversion from enumeration type 'enum iscsi_host_param' to different enumeration type 'enum iscsi_param' [-Wenum-conversion] &addr, param, buf); ^~~~~ 1 warning generated. iscsi_conn_get_addr_param handles ISCSI_HOST_PARAM_IPADDRESS just fine so add an explicit cast to iscsi_param to make it clear to Clang that this is expected behavior. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 761c830e ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/bfa/bfa_fcs_lport.c:379:26: warning: implicit conversion from enumeration type 'enum bfa_lport_aen_event' to different enumeration type 'enum bfa_ioc_aen_event' [-Wenum-conversion] BFA_AEN_CAT_LPORT, event); ^~~~~ The root cause of these warnings is the bfad_im_post_vendor_event function, which expects a value from enum bfa_ioc_aen_event but there are multiple instances of values from enums bfa_port_aen_event, bfa_audit_aen_event, and bfa_lport_aen_event being used in this function. Given that this doesn't appear to be a problem since cat helps with differentiating the events, just change evt's type to int so that no conversion needs to happen and Clang won't warn. Update aen_type's type in bfa_aen_entry_s as members that hold enumerated types should be int. Link: https://github.com/ClangBuiltLinux/linux/issues/147Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 362b5da3 ] Clang warns when an enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:3476:13: warning: implicit conversion from enumeration type 'enum sci_task_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = sci_controller_start_task(ihost, ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/host.c:2744:10: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return SCI_SUCCESS; ~~~~~~ ^~~~~~~~~~~ drivers/scsi/isci/host.c:2753:9: warning: implicit conversion from enumeration type 'enum sci_status' to different enumeration type 'enum sci_task_status' [-Wenum-conversion] return status; ~~~~~~ ^~~~~~ Avoid all of these implicit conversion by just making sci_controller_start_task use sci_status. This silences Clang and has no functional change since sci_task_status has all of its values mapped to something in sci_status. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit e9e9a103 ] Clang warns when one enumerated type is implicitly converted to another. drivers/scsi/isci/request.c:1629:13: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/isci/request.c:1631:12: warning: implicit conversion from enumeration type 'enum sci_io_status' to different enumeration type 'enum sci_status' [-Wenum-conversion] status = SCI_IO_FAILURE_RESPONSE_VALID; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ status is of type sci_status but SCI_IO_FAILURE_RESPONSE_VALID is of type sci_io_status. Use SCI_FAILURE_IO_RESPONSE_VALID, which is from sci_status and has SCI_IO_FAILURE_RESPONSE_VALID's exact value since that is what SCI_IO_FAILURE_RESPONSE_VALID is mapped to in the isci.h file. Link: https://github.com/ClangBuiltLinux/linux/issues/153Signed-off-by:
-
Joseph Lo authored
[ Upstream commit a4dbbcee ] Fix some incorrect data in LVL2 offset and bit mask. Fixes: e403d005 ("clk: tegra: MBIST work around for Tegra210") Signed-off-by:
Joseph Lo <josephl@nvidia.com> Signed-off-by:
Peter De Schrijver <pdeschrijver@nvidia.com> Acked-by:
-
Uros Bizjak authored
[ Upstream commit 5ebb272b ] Register operand size of invvpid and invept instruction in 64-bit mode has always 64 bits. Adjust inline function argument type to reflect correct size. Signed-off-by:
Uros Bizjak <ubizjak@gmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Sean Christopherson authored
[ Upstream commit 7671ce21 ] In preparation of supporting checkpoint/restore for nested state, commit ca0bde28 ("kvm: nVMX: Split VMCS checks from nested_vmx_run()") modified check_vmentry_postreqs() to only perform the guest EFER consistency checks when nested_run_pending is true. But, in the normal nested VMEntry flow, nested_run_pending is only set after check_vmentry_postreqs(), i.e. the consistency check is being skipped. Alternatively, nested_run_pending could be set prior to calling check_vmentry_postreqs() in nested_vmx_run(), but placing the consistency checks in nested_vmx_enter_non_root_mode() allows us to split prepare_vmcs02() and interleave the preparation with the consistency checks without having to change the call sites of nested_vmx_enter_non_root_mode(). In other words, the rest of the consistency check code in nested_vmx_run() will be joining the postreqs checks in future patches. Fixes: ca0bde28 ("kvm: nVMX: Split VMCS checks from nested_vmx_run()") Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Cc: Jim Mattson <jmattson@google.com> Reviewed-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
-
Sean Christopherson authored
[ Upstream commit b7031fd4 ] Reset the vm_{entry,exit}_controls_shadow variables as well as the segment cache after loading a new VMCS in vmx_switch_vmcs(). The shadows/cache track VMCS data, i.e. they're stale every time we switch to a new VMCS regardless of reason. This fixes a bug where stale control shadows would be consumed after a nested VMExit due to a failed consistency check. Suggested-by:
-
Jakub Kicinski authored
[ Upstream commit 527db74b ] Atomic operations on the NFP are currently always in big endian. The driver keeps track of regions of memory storing atomic values and byte swaps them accordingly. There are corner cases where the map values may be initialized before the driver knows they are used as atomic counters. This can happen either when the datapath is performing the update and the stack contents are unknown or when map is updated before the program which will use it for atomic values is loaded. To avoid situation where user initializes the value to 0 1 2 3 and then after loading a program which uses the word as an atomic counter starts reading 3 2 1 0 - only allow atomic counters to be initialized to endian-neutral values. For updates from the datapath the stack information may not be as precise, so just allow initializing such values to 0. Example code which would break: struct bpf_map_def SEC("maps") rxcnt = { .type = BPF_MAP_TYPE_HASH, .key_size = sizeof(__u32), .value_size = sizeof(__u64), .max_entries = 1, }; int xdp_prog1() { __u64 nonzeroval = 3; __u32 key = 0; __u64 *value; value = bpf_map_lookup_elem(&rxcnt, &key); if (!value) bpf_map_update_elem(&rxcnt, &key, &nonzeroval, BPF_ANY); else __sync_fetch_and_add(value, 1); return XDP_PASS; } $ offload bpftool map dump key: 00 00 00 00 value: 00 00 00 03 00 00 00 00 should be: $ offload bpftool map dump key: 00 00 00 00 value: 03 00 00 00 00 00 00 00 Reported-by:
David Beckett <david.beckett@netronome.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 5d25ff7a ] Add missing break statement in order to prevent the code from falling through to case TEST_UNIT_READY. Addresses-Coverity-ID: 1357338 ("Missing break in switch") Suggested-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Rahul Verma authored
[ Upstream commit 706d0891 ] Align the use of local PTT to propagate through the qed_mcp* API's. Global ptt should not be used. Register access should be done through layers. Register address is mapped into a PTT, PF translation table. Several interface functions require a PTT to direct read/write into register. There is a pool of PTT maintained, and several PTT are used simultaneously to access device registers in different flows. Same PTT should not be used in flows that can run concurrently. To avoid running out of PTT resources, too many PTT should not be acquired without releasing them. Every PF has a global PTT, which is used throughout the life of PF, in most important flows for register access. Generic functions acquire the PTT locally and release after the use. This patch aligns the use of Global PTT and Local PTT accordingly. Signed-off-by:
Rahul Verma <rahul.verma@cavium.com> Signed-off-by:
Ariel Elior <ariel.elior@cavium.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Omar Sandoval authored
[ Upstream commit 53d0f8db ] The error handling in fd_probe_drives() doesn't clean up at all. Fix it up in preparation for converting to blk-mq. While we're here, get rid of the commented out amiga_floppy_remove(). Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 2153bbc1 ] According to the datasheet the update bit must be set if the on-time-div or the base-unit changes. Now that we properly order device resume on Cherry Trail so that the GFX0 _PS0 method no longer exits with an error, we end up with a sequence of events where we are writing the same values twice in a row. First the _PS0 method restores the duty cycle of 0% the GPU driver set on suspend and then the GPU driver first updates just the enabled bit in the pwm_state from 0 to 1, causing us to write the same values again, before restoring the pre-suspend duty-cycle in a separate pwm_apply call. When writing the update bit the second time, without changing any of the values the update bit clears immediately / instantly, instead of staying 1 for a while as usual. After this the next setting of the update bit seems to be ignored, causing the restoring of the pre-suspend duty-cycle to not get applied. This makes the backlight come up with a 0% dutycycle after suspend/resume. Any further brightness changes after this do work. This commit moves the setting of the update bit into pwm_lpss_prepare() and only sets the bit if we have actually changed any of the values. This avoids the setting of the update bit the second time we configure the PWM to 0% dutycycle, this fixes the backlight coming up with 0% duty-cycle after a suspend/resume. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit a93a676b ] If 'krealloc()' fails, 'pctl->functions' is set to NULL. We should instead use a temp variable in order to be able to free the previously allocated memeory, in case of OOM. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Selvin Xavier authored
[ Upstream commit 5df95099 ] In case the NQ alloc/enable fails, free up the already allocated/enabled NQ before reporting failure. Also, track the alloc/enable using proper state checking. Signed-off-by:
Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Devesh Sharma authored
[ Upstream commit 4c01f2e3 ] Reports affiliated async event on the qp-async event channel instead of global event channel. Signed-off-by:
Devesh Sharma <devesh.sharma@broadcom.com> Signed-off-by:
-
Selvin Xavier authored
[ Upstream commit eae4ad1b ] This is reported by smatch check. rcfw->creq_bar_reg_iomem is accessed in bnxt_qplib_rcfw_stop_irq and this variable check afterwards doesn't make sense. Also, rcfw->creq_bar_reg_iomem will never be NULL. So Removing this check. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 6e04b103 ("RDMA/bnxt_re: Fix broken RoCE driver due to recent L2 driver changes") Signed-off-by:
-
Xiang Chen authored
[ Upstream commit 3e178f3e ] If an SSP/SMP IO times out, it may be actually in reality be simultaneously processing completion of the slot in slot_complete_vx_hw(). Then if the slot is freed in slot_complete_vx_hw() (this IPTT is freed and it may be re-used by other slot), and we may abort the wrong slot in hisi_sas_abort_task(). So to solve the issue, free the slot after the check of SAS_TASK_STATE_ABORTED in slot_complete_vx_hw(). Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Xiang Chen authored
[ Upstream commit 584f53fe ] If SMP/internal IO times out, we will possibly free the task immediately. However if the IO actually completes at the same time, the IO completion may refer to task which has been freed. So to solve the issue, flush the tasklet to finish IO completion before free'ing slot/task. Signed-off-by:
-
Luo Jiaxing authored
[ Upstream commit 5a54691f ] At directly attached situation, if the user modifies the sysfs interface of maximum_linkrate and minimum_linkrate to renegotiate the linkrate between SAS controller and target, the value of both files mentioned above should have change to user setting after renegotiate is over, but it remains unchanged. To fix this bug, maximum_linkrate and minimum_linkrate will be directly fed back to relevant sas_phy structure. Signed-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
-
Angelo Dureghello authored
[ Upstream commit 381fdd62 ] This patch fixes command_line array zero-terminated one byte over the end of the array, causing boot to hang. Signed-off-by:
Angelo Dureghello <angelo@sysam.it> Signed-off-by:
Greg Ungerer <gerg@linux-m68k.org> Signed-off-by:
-
Julien Folly authored
w1: IAD Register is yet readable trough iad sys file. Fix snprintf (%u for unsigned, count for max size). [ Upstream commit 6eaafbb6 ] IAD Register is yet readable trough the "iad" sys file. A write to the "iad" sys file enables or disables the current measurement, but it was not possible to get the measured value by reading it. Fix: %u in snprintf for unsigned values (vdd and vad) Fix: Avoid possibles overflows (Usage of the 'count' variables) Signed-off-by:
Julien Folly <julien.folly@gmail.com> Acked-by:
Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Wenwen Wang authored
[ Upstream commit 6b995f4e ] In _scif_prog_signal(), the boolean variable 'x100' is used to indicate whether the MIC Coprocessor is X100. If 'x100' is true, the status descriptor will be used to write the value to the destination. Otherwise, a DMA pool will be allocated for this purpose. Specifically, if the DMA pool is allocated successfully, two memory addresses will be returned. One is for the CPU and the other is for the device to access the DMA pool. The former is stored to the variable 'status' and the latter is stored to the variable 'src'. After the allocation, the address in 'src' is saved to 'status->src_dma_addr', which is actually in the DMA pool, and 'src' is then modified. Later on, if an error occurs, the execution flow will transfer to the label 'dma_fail', which will check 'x100' and free up the allocated DMA pool if 'x100' is false. The point here is that 'status->src_dma_addr' is used for freeing up the DMA pool. As mentioned before, 'status->src_dma_addr' is in the DMA pool. And thus, the device is able to modify this data. This can potentially cause failures when freeing up the DMA pool because of the modified device address. This patch avoids the above issue by using the variable 'src' (with necessary calculation) to free up the DMA pool. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Signed-off-by:
-
Duncan Laurie authored
[ Upstream commit 655603de ] The sysfs handler should return the number of bytes consumed, which in the case of a successful write is the entire buffer. Also fix a bug where param.data_len was being set to (count - (2 * sizeof(u32))) instead of just (count - sizeof(u32)). The latter is correct because we skip over the leading u32 which is our param.type, but we were also incorrectly subtracting sizeof(u32) on the line where we were actually setting param.data_len: param.data_len = count - sizeof(u32); This meant that for our example event.kernel_software_watchdog with total length 10 bytes, param.data_len was just 2 prior to this change. To test, successfully append an event to the log with gsmi sysfs. This sample event is for a "Kernel Software Watchdog" > xxd -g 1 event.kernel_software_watchdog 0000000: 01 00 00 00 ad de 06 00 00 00 > cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog > mosys eventlog list | tail -1 14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog Signed-off-by:
Duncan Laurie <dlaurie@chromium.org> Reviewed-by:
Vadim Bendebury <vbendeb@chromium.org> Reviewed-by:
Stefan Reinauer <reinauer@chromium.org> Signed-off-by:
Furquan Shaikh <furquan@google.com> Tested-by:
Furquan Shaikh <furquan@chromium.org> Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Reviewed-by:
Justin TerAvest <teravest@chromium.org> [zwisler: updated changelog for 2nd bug fix and upstream] Signed-off-by:
Ross Zwisler <zwisler@google.com> Reviewed-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Nikolay Borisov authored
[ Upstream commit 315bed43 ] In btrfs_search_old_slot get_old_root is always used with the assumption it cannot fail. However, this is not true in rare circumstance it can fail and return null. This will lead to null point dereference when the header is read. Fix this by checking the return value and properly handling NULL by setting ret to -EIO and returning gracefully. Coverity-id: 1087503 Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
Lu Fengqi <lufq.fnst@cn.fujitsu.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Su Yue authored
[ Upstream commit 28c4a3e2 ] Since commit 8b62f87b ("Btrfs: rework outstanding_extents"), manual operations of outstanding_extent in btrfs_inode are replaced by btrfs_mod_outstanding_extents(). The one in cluster_pages_for_defrag seems to be lost, so replace it of btrfs_mod_outstanding_extents(). Fixes: 8b62f87b ("Btrfs: rework outstanding_extents") Signed-off-by:
Su Yue <suy.fnst@cn.fujitsu.com> Reviewed-by:
-
Honghui Zhang authored
[ Upstream commit a7f172ab ] commit 101c92dc ("PCI: mediatek: Set up vendor ID and class type for MT7622") erroneously set the class type for MT7622 to PCI_CLASS_BRIDGE_HOST. The PCIe controller of MT7622 integrates a Root Port that has type 1 configuration space header and related bridge windows. The HW default value of this bridge's class type is invalid. Fix its class type and set it to PCI_CLASS_BRIDGE_PCI to match the hardware implementation. Fixes: 101c92dc ("PCI: mediatek: Set up vendor ID and class type for MT7622") Signed-off-by:
-
Chaotian Jing authored
[ Upstream commit f38a9774 ] when msdc_cmd_is_ready return fail, the req_timeout work has not been inited and cancel_delayed_work() will return false, then, the request return directly and never call mmc_request_done(). so need call mod_delayed_work() before msdc_cmd_is_ready() Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Chaotian Jing authored
[ Upstream commit 56f6cbbe ] as the mmc core layer has the mmc->actual_clock, so fill it and drop msdc_host->sclk. Signed-off-by:
-
Sergei Shtylyov authored
[ Upstream commit f34c6e62 ] Since commit 9ec36caf ("of/irq: do irq resolution in platform_get_irq") platform_get_irq() can return -EPROBE_DEFER. However, the driver overrides an error returned by that function with -ENOENT which breaks the deferred probing. Propagate upstream an error code returned by platform_get_irq() and remove the bogus "platform" from the error message, while at it... Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Jens Axboe authored
[ Upstream commit 8f94004e ] We can't modify cdo->capability as it is defined as a const. Change the modification hack to just WARN_ON_ONCE() if we hit any of the invalid combinations. This fixes a regression for pcd, which doesn't work after the constify patch. Fixes: 853fe1bf ("cdrom: Make device operations read-only") Tested-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
