- 15 May, 2020 3 commits
-
-
Vinod Koul authored
Some rensas controller like uPD720201 and uPD720202 need firmware to be loaded. Add these devices in table and invoke renesas firmware loader functions to check and load the firmware into device memory when required. Signed-off-by:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-4-vkoul@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Christian Lamparter authored
This add a new driver for renesas xhci which is basically a firmware loader for uPD720201 and uPD720202 w/o ROM. The xhci-pci driver will invoke this driver for loading/unloading on relevant devices. This patch adds a firmware loader for the uPD720201K8-711-BAC-A and uPD720202K8-711-BAA-A variant. Both of these chips are listed in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as devices which need the firmware loader on page 2 in order to work as they "do not support the External ROM". The "Firmware Download Sequence" is describe in chapter "7.1 FW Download Interface" R19UH0078EJ0500 Rev.5.00 page 131. The firmware "K2013080.mem" is available from a USB3.0 Host to PCIe Adapter (PP2U-E card) "Firmware download" archive. An alternative version can be sourced from Netgear's WNDR4700 GPL archives. The release notes of the PP2U-E's "Firmware Download" ver 2.0.1.3 (2012-06-15) state that the firmware is for the following devices: - uPD720201 ES 2.0 sample whose revision ID is 2. - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3. - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2. [vkoul: fixed comments: used macros for timeout count and delay removed renesas_fw_alive_check cleaned renesas_fw_callback removed recursion for renesas_fw_download add register defines and field names move to a separate file make fw loader as sync probe so that we execute in probe and prevent race make xhci-pci-renesas a seprate module] Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-3-vkoul@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vinod Koul authored
usb_hcd_pci_probe expects users to call this with driver_data set as hc_driver, that limits the possibility of using the driver_data for driver data. Add hc_driver as argument to usb_hcd_pci_probe and modify the callers ehci/ohci/xhci/uhci to pass hc_driver as argument and freeup the driver_data used Tested xhci driver on Dragon-board RB3, compile tested ehci, ohci and uhci. [For all but the xHCI parts] [For the xhci part] Suggested-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-2-vkoul@kernel.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 May, 2020 18 commits
-
-
Al Cooper authored
Add the build system changes needed to get the Broadcom STB XHCI, EHCI and OHCI functionality working. The OHCI support does not require anything unique to Broadcom so the standard ohci-platform driver is being used. Also update MAINTAINERS. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200512150019.25903-6-alcooperx@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Al Cooper authored
Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver was created instead of adding support to the existing ehci platform driver because of the code required to work around bugs in the EHCI controller. The primary workaround is for a bug where the Core violates the SOF interval between the first two SOFs transmitted after resume. This only happens if the resume occurs near the end of a microframe. The fix is to intercept the ehci-hcd request to complete RESUME and align it to the start of the next microframe. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200512150019.25903-5-alcooperx@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Al Cooper authored
Add support for Broadcom STB SoC's to the xhci platform driver Signed-off-by:
Al Cooper <alcooperx@gmail.com> Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200512150019.25903-4-alcooperx@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Al Cooper authored
Add DT bindings for Broadcom STB USB EHCI and XHCI drivers. NOTE: The OHCI driver is not included because it uses the generic platform driver. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200512150019.25903-3-alcooperx@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bryan O'Donoghue authored
This patch adds USB role switch support to the tps6598x. The setup to initiate or accept a data-role switch is both assumed and currently required to be baked-into the firmware as described in TI's document here. Link: https://www.ti.com/lit/an/slva843a/slva843a.pdf With this change its possible to use the USB role-switch API to detect and notify role-switches to downstream consumers. Tested with a ChipIdea controller on a Qualcomm MSM8939. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Gustavo A. R. Silva <garsilva@embeddedor.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20200511231930.2825183-2-bryan.odonoghue@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bryan O'Donoghue authored
Adds a MODULE_DEVICE_TABLE() to allow probing of this driver from a DTS setting. Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Gustavo A. R. Silva <garsilva@embeddedor.com> Cc: Kees Cook <keescook@chromium.org> Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200507214733.1982696-3-bryan.odonoghue@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bryan O'Donoghue authored
Add device tree binding documentation for the Texas Instruments tps6598x Type-C chip driver. Cc: Rob Herring <robh+dt@kernel.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20200507214733.1982696-2-bryan.odonoghue@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
I will be maintaining the Intel PMC mux control driver. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200507150900.12102-5-heikki.krogerus@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
Adding documentation that describes how the PMC mux-agent function is described in the ACPI tables. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200507150900.12102-4-heikki.krogerus@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
The SBU and HSL orientation may be fixed/static from the mux PoW. Apparently the retimer may take care of the orientation of these lines. Handling the static SBU (AUX) and HSL orientation with device properties. If the SBU orientation is static, a device property "sbu-orintation" can be used. When the property exists, the driver always sets the SBU orientation according to the property value, and when it's not set, the driver uses the cable plug orientation with SBU. And with static HSL orientation, "hsl-orientation" device property can be used in the same way. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200507150900.12102-3-heikki.krogerus@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
Function that converts orientation string into orientation value. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200507150900.12102-2-heikki.krogerus@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bryan O'Donoghue authored
Right now we don't report to user-space a role switch when doing a usb_role_switch_set_role() despite having registered the uevent callbacks. This patch switches on the notifications allowing user-space to see role-switch change notifications and subsequently determine the current controller data-role. example: PFX=/devices/platform/soc/78d9000.usb/ci_hdrc.0 root@somebox# udevadm monitor -p KERNEL[49.894994] change $PFX/usb_role/ci_hdrc.0-role-switch (usb_role) ACTION=change DEVPATH=$PFX/usb_role/ci_hdrc.0-role-switch SUBSYSTEM=usb_role DEVTYPE=usb_role_switch USB_ROLE_SWITCH=ci_hdrc.0-role-switch SEQNUM=2432 Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Wen Yang <wenyang@linux.alibaba.com> Cc: chenqiwu <chenqiwu@xiaomi.com> Cc: linux-kernel@vger.kernel.org Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20200508162937.2566818-1-bryan.odonoghue@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei Yongjun authored
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 7d9e6f5a ("usb: host: ohci-sm501: init genalloc for local memory") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200506135625.106910-1-weiyongjun1@huawei.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tang Bin authored
If the function platform_get_irq() failed, the negative value returned will not be detected here. So fix error handling in mv_ehci_probe(). And when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Signed-off-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20200508114305.15740-1-tangbin@cmss.chinamobile.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tang Bin authored
Delete unused initialized value, because 'retval' will be assigined by the function mv_ehci_enable(). And delete the extra blank lines. Signed-off-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200508142136.4232-1-tangbin@cmss.chinamobile.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tang Bin authored
Use the defined variable "dev" to make the code cleaner. And delete an extra blank line. Signed-off-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200508144024.7836-1-tangbin@cmss.chinamobile.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Oliver Neukum authored
syzkaller reported an URB that should have been killed to be active. We do not understand it, but this should fix the issue if it is real. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-by: syzbot+be5b5f86a162a6c281e6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200507085806.5793-1-oneukum@suse.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hannes Reinecke authored
scsi_get_host_dev() will create a virtual device such that either the target id is ignored from scanning (if 'this_id' is set to something which can be reached during scanning) or if the driver needs a scsi device for the HBA to send commands to. Neither is true for sierra-ms; 'this_id' remains at the default value '-1' and the created device is never ever used within the driver. So kill it. Signed-off-by:
Hannes Reinecke <hare@suse.de> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20200505143019.57418-1-hare@suse.deSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 May, 2020 1 commit
-
-
Greg Kroah-Hartman authored
We want the USB fixes in here too. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 May, 2020 7 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "A set of fixes for x86: - Ensure that direct mapping alias is always flushed when changing page attributes. The optimization for small ranges failed to do so when the virtual address was in the vmalloc or module space. - Unbreak the trace event registration for syscalls without arguments caused by the refactoring of the SYSCALL_DEFINE0() macro. - Move the printk in the TSC deadline timer code to a place where it is guaranteed to only be called once during boot and cannot be rearmed by clearing warn_once after boot. If it's invoked post boot then lockdep rightfully complains about a potential deadlock as the calling context is different. - A series of fixes for objtool and the ORC unwinder addressing variety of small issues: - Stack offset tracking for indirect CFAs in objtool ignored subsequent pushs and pops - Repair the unwind hints in the register clearing entry ASM code - Make the unwinding in the low level exit to usermode code stop after switching to the trampoline stack. The unwind hint is no longer valid and the ORC unwinder emits a warning as it can't find the registers anymore. - Fix unwind hints in switch_to_asm() and rewind_stack_do_exit() which caused objtool to generate bogus ORC data. - Prevent unwinder warnings when dumping the stack of a non-current task as there is no way to be sure about the validity because the dumped stack can be a moving target. - Make the ORC unwinder behave the same way as the frame pointer unwinder when dumping an inactive tasks stack and do not skip the first frame. - Prevent ORC unwinding before ORC data has been initialized - Immediately terminate unwinding when a unknown ORC entry type is found. - Prevent premature stop of the unwinder caused by IRET frames. - Fix another infinite loop in objtool caused by a negative offset which was not catched. - Address a few build warnings in the ORC unwinder and add missing static/ro_after_init annotations" * tag 'x86-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/unwind/orc: Move ORC sorting variables under !CONFIG_MODULES x86/apic: Move TSC deadline timer debug printk ftrace/x86: Fix trace event registration for syscalls without arguments x86/mm/cpa: Flush direct map alias during cpa objtool: Fix infinite loop in for_offset_range() x86/unwind/orc: Fix premature unwind stoppage due to IRET frames x86/unwind/orc: Fix error path for bad ORC entry type x86/unwind/orc: Prevent unwinding before ORC initialization x86/unwind/orc: Don't skip the first frame for inactive tasks x86/unwind: Prevent false warnings for non-current tasks x86/unwind/orc: Convert global variables to static x86/entry/64: Fix unwind hints in rewind_stack_do_exit() x86/entry/64: Fix unwind hints in __switch_to_asm() x86/entry/64: Fix unwind hints in kernel exit path x86/entry/64: Fix unwind hints in register clearing code objtool: Fix stack offset tracking for indirect CFAs
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull objtool fix from Thomas Gleixner: "A single fix for objtool to prevent an infinite loop in the jump table search which can be triggered when building the kernel with '-ffunction-sections'" * tag 'objtool-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool: Fix infinite loop in find_jump_table()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fix from Thomas Gleixner: "A single fix for the fallout of the recent futex uacess rework. With those changes GCC9 fails to analyze arch_futex_atomic_op_inuser() correctly and emits a 'maybe unitialized' warning. While we usually ignore compiler stupidity the conditional store is pointless anyway because the correct case has to store. For the fault case the extra store does no harm" * tag 'locking-urgent-2020-05-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ARM: futex: Address build warning
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull iommu fixes from Joerg Roedel: - Race condition fixes for the AMD IOMMU driver. These are five patches fixing two race conditions around increase_address_space(). The first race condition was around the non-atomic update of the domain page-table root pointer and the variable containing the page-table depth (called mode). This is fixed now be merging page-table root and mode into one 64-bit field which is read/written atomically. The second race condition was around updating the page-table root pointer and making it public before the hardware caches were flushed. This could cause addresses to be mapped and returned to drivers which are not reachable by IOMMU hardware yet, causing IO page-faults. This is fixed too by adding the necessary flushes before a new page-table root is published. Related to the race condition fixes these patches also add a missing domain_flush_complete() barrier to update_domain() and a fix to bail out of the loop which tries to increase the address space when the call to increase_address_space() fails. Qian was able to trigger the race conditions under high load and memory pressure within a few days of testing. He confirmed that he has seen no issues anymore with the fixes included here. - Fix for a list-handling bug in the VirtIO IOMMU driver. * tag 'iommu-fixes-v5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/virtio: Reverse arguments to list_add iommu/amd: Do not flush Device Table in iommu_map_page() iommu/amd: Update Device Table in increase_address_space() iommu/amd: Call domain_flush_complete() in update_domain() iommu/amd: Do not loop forever when trying to increase address space iommu/amd: Fix race in increase_address_space()/fetch_pte()
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: - a small series fixing a use-after-free of bdi name (Christoph,Yufen) - NVMe fix for a regression with the smaller CQ update (Alexey) - NVMe fix for a hang at namespace scanning error recovery (Sagi) - fix race with blk-iocost iocg->abs_vdebt updates (Tejun) * tag 'block-5.7-2020-05-09' of git://git.kernel.dk/linux-block: nvme: fix possible hang when ns scanning fails during error recovery nvme-pci: fix "slimmer CQ head update" bdi: add a ->dev_name field to struct backing_dev_info bdi: use bdi_dev_name() to get device name bdi: move bdi_dev_name out of line vboxsf: don't use the source name in the bdi name iocost: protect iocg->abs_vdebt with iocg->waitq.lock
-
Linus Torvalds authored
It seems that for whatever reason, gcc-10 ends up not inlining a couple of functions that used to be inlined before. Even if they only have one single callsite - it looks like gcc may have decided that the code was unlikely, and not worth inlining. The code generation difference is harmless, but caused a few new section mismatch errors, since the (now no longer inlined) function wasn't in the __init section, but called other init functions: Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem() Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap() Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap() So add the appropriate __init annotation to make modpost not complain. In both cases there were trivially just a single callsite from another __init function. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 09 May, 2020 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Palmer Dabbelt: "A smattering of fixes and cleanups: - Dead code removal. - Exporting riscv_cpuid_to_hartid_mask for modules. - Per-CPU tracking of ISA features. - Setting max_pfn correctly when probing memory. - Adding a note to the VDSO so glibc can check the kernel's version without a uname(). - A fix to force the bootloader to initialize the boot spin tables, which still get used as a fallback when SBI-0.1 is enabled" * tag 'riscv-for-linus-5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Remove unused code from STRICT_KERNEL_RWX riscv: force __cpu_up_ variables to put in data section riscv: add Linux note to vdso riscv: set max_pfn to the PFN of the last page RISC-V: Remove N-extension related defines RISC-V: Add bitmap reprensenting ISA features common across CPUs RISC-V: Export riscv_cpuid_to_hartid_mask() API
-
Linus Torvalds authored
gcc-10 has started warning about conflicting types for a few new built-in functions, particularly 'free()'. This results in warnings like: crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch] because the crypto layer had its local freeing functions called 'free()'. Gcc-10 is in the wrong here, since that function is marked 'static', and thus there is no chance of confusion with any standard library function namespace. But the simplest thing to do is to just use a different name here, and avoid this gcc mis-feature. [ Side note: gcc knowing about 'free()' is in itself not the mis-feature: the semantics of 'free()' are special enough that a compiler can validly do special things when seeing it. So the mis-feature here is that gcc thinks that 'free()' is some restricted name, and you can't shadow it as a local static function. Making the special 'free()' semantics be a function attribute rather than tied to the name would be the much better model ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
gcc-10 now warns about passing aliasing pointers to functions that take restricted pointers. That's actually a great warning, and if we ever start using 'restrict' in the kernel, it might be quite useful. But right now we don't, and it turns out that the only thing this warns about is an idiom where we have declared a few functions to be "printf-like" (which seems to make gcc pick up the restricted pointer thing), and then we print to the same buffer that we also use as an input. And people do that as an odd concatenation pattern, with code like this: #define sysfs_show_gen_prop(buffer, fmt, ...) \ snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__) where we have 'buffer' as both the destination of the final result, and as the initial argument. Yes, it's a bit questionable. And outside of the kernel, people do have standard declarations like int snprintf( char *restrict buffer, size_t bufsz, const char *restrict format, ... ); where that output buffer is marked as a restrict pointer that cannot alias with any other arguments. But in the context of the kernel, that 'use snprintf() to concatenate to the end result' does work, and the pattern shows up in multiple places. And we have not marked our own version of snprintf() as taking restrict pointers, so the warning is incorrect for now, and gcc picks it up on its own. If we do start using 'restrict' in the kernel (and it might be a good idea if people find places where it matters), we'll need to figure out how to avoid this issue for snprintf and friends. But in the meantime, this warning is not useful. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
This is the final array bounds warning removal for gcc-10 for now. Again, the warning is good, and we should re-enable all these warnings when we have converted all the legacy array declaration cases to flexible arrays. But in the meantime, it's just noise. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Sagi Grimberg authored
When the controller is reconnecting, the host fails I/O and admin commands as the host cannot reach the controller. ns scanning may revalidate namespaces during that period and it is wrong to remove namespaces due to these failures as we may hang (see 205da243). One command that may fail is nvme_identify_ns_descs. Since we return success due to having ns identify descriptor list optional, we continue to compare ns identifiers in nvme_revalidate_disk, obviously fail and return -ENODEV to nvme_validate_ns, which will remove the namespace. Exactly what we don't want to happen. Fixes: 22802bf7 ("nvme: Namepace identification descriptor list is optional") Tested-by:
Anton Eidelman <anton@lightbitslabs.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Reviewed-by:
Keith Busch <kbusch@kernel.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Alexey Dobriyan authored
Pre-incrementing ->cq_head can't be done in memory because OOB value can be observed by another context. This devalues space savings compared to original code :-\ $ ./scripts/bloat-o-meter ../vmlinux-000 ../obj/vmlinux add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-32 (-32) Function old new delta nvme_poll_irqdisable 464 456 -8 nvme_poll 455 447 -8 nvme_irq 388 380 -8 nvme_dev_disable 955 947 -8 But the code is minimal now: one read for head, one read for q_depth, one increment, one comparison, single instruction phase bit update and one write for new head. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reported-by:
John Garry <john.garry@huawei.com> Tested-by:
John Garry <john.garry@huawei.com> Fixes: e2a366a4 ("nvme-pci: slimmer CQ head update") Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Christoph Hellwig authored
Cache a copy of the name for the life time of the backing_dev_info structure so that we can reference it even after unregistering. Fixes: 68f23b89 ("memcg: fix a crash in wb_workfn when a device disappears") Reported-by:
Yufen Yu <yuyufen@huawei.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Yufen Yu authored
Use the common interface bdi_dev_name() to get device name. Signed-off-by:
Yufen Yu <yuyufen@huawei.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Add missing <linux/backing-dev.h> include BFQ Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
Linus Torvalds authored
This is another fine warning, related to the 'zero-length-bounds' one, but hitting the same historical code in the kernel. Because C didn't historically support flexible array members, we have code that instead uses a one-sized array, the same way we have cases of zero-sized arrays. The one-sized arrays come from either not wanting to use the gcc zero-sized array extension, or from a slight convenience-feature, where particularly for strings, the size of the structure now includes the allocation for the final NUL character. So with a "char name[1];" at the end of a structure, you can do things like v = my_malloc(sizeof(struct vendor) + strlen(name)); and avoid the "+1" for the terminator. Yes, the modern way to do that is with a flexible array, and using 'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That also technically gets the size "more correct" in that it avoids any alignment (and thus padding) issues, but this is another long-term cleanup thing that will not happen for 5.7. So disable the warning for now, even though it's potentially quite useful. Having a slew of warnings that then hide more urgent new issues is not an improvement. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
This is a fine warning, but we still have a number of zero-length arrays in the kernel that come from the traditional gcc extension. Yes, they are getting converted to flexible arrays, but in the meantime the gcc-10 warning about zero-length bounds is very verbose, and is hiding other issues. I missed one actual build failure because it was hidden among hundreds of lines of warning. Thankfully I caught it on the second go before pushing things out, but it convinced me that I really need to disable the new warnings for now. We'll hopefully be all done with our conversion to flexible arrays in the not too distant future, and we can then re-enable this warning. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
We have some rather random rules about when we accept the "maybe-initialized" warnings, and when we don't. For example, we consider it unreliable for gcc versions < 4.9, but also if -O3 is enabled, or if optimizing for size. And then various kernel config options disabled it, because they know that they trigger that warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES). And now gcc-10 seems to be introducing a lot of those warnings too, so it falls under the same heading as 4.9 did. At the same time, we have a very straightforward way to _enable_ that warning when wanted: use "W=2" to enable more warnings. So stop playing these ad-hoc games, and just disable that warning by default, with the known and straight-forward "if you want to work on the extra compiler warnings, use W=123". Would it be great to have code that is always so obvious that it never confuses the compiler whether a variable is used initialized or not? Yes, it would. In a perfect world, the compilers would be smarter, and our source code would be simpler. That's currently not the world we live in, though. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-