- 23 May, 2020 4 commits
-
-
Jonathan Marek authored
Also skip the newly added HFI set freq path if the GMU is powered down, which was missing because of patches crossing paths. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Instead of using a bare unsigned type for the length value for map/unmap functions pass in a size_t to more correctly match up with the underlying APIs. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Refactor how address space initialization works. Instead of having the address space function create the MMU object (and thus require separate but equal functions for gpummu and iommu) use a single function and pass the MMU struct in. Make the generic code cleaner by using target specific functions to create the address space so a2xx can do its own thing in its own space. For all the other targets use a generic helper to initialize IOMMU but leave the door open for newer targets to use customization if they need it. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> [squash in rebase fixups] Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Everywhere an IOMMU object is created by msm_gpu_create_address_space the IOMMU device is attached immediately after. Instead of carrying around the infrastructure to do the attach from the device specific code do it directly in the msm_iommu_init() function. This gets it out of the way for more aggressive cleanups that follow. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> [squash in rebase fixups and fix for unused fxn] Signed-off-by: Rob Clark <robdclark@chromium.org>
-
- 22 May, 2020 2 commits
-
-
kbuild test robot authored
Fixes: 4259ff7a ("drm/msm/dpu: add support for pcc color block in dpu driver") Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
kbuild test robot authored
Fixes: 8167e6fa ("drm/msm/a6xx: HFI v2 for A640 and A650") Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
- 18 May, 2020 23 commits
-
-
Shawn Guo authored
A405 device has a different set of registers than a4xx_registers. It has no VMIDMT or XPU registers, and VBIF registers are different. Let's add a405_registers for a405 device. As adreno_is_a405() works only after adreno_gpu_init() gets called, the assignments get moved down after adreno_gpu_init(). Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Jordan Crouse <jcrouse@codeauorora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Shawn Guo authored
It adds support for adreno a405 found on MSM8939. The adreno_is_a430() check in adreno_submit() needs an extension to cover a405. The downstream driver suggests it should cover the whole a4xx generation. That's why it gets changed to adreno_is_a4xx(), while a420 is not tested though. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
Adreno 640 and 650 GPUs need some registers set differently. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
This is required for a650 to work. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
Update the gmu_pdc registers for A640 and A650. Some of the RSCC registers on A650 are in a separate region. Note this also changes the address of these registers: RSCC_TCS1_DRV0_STATUS RSCC_TCS2_DRV0_STATUS RSCC_TCS3_DRV0_STATUS Based on the values in msm-4.14 and msm-4.19 kernels. v3: replaced adreno_is_a650 around ->rscc with checks for "rscc" resource Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
Newer GPUs have different GMU firmware path. v3: updated a6xx_gmu_fw_load based on feedback, including gmu_write_bulk, and removed extra whitespace change Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
Add HFI v2 code paths required by Adreno 640 and 650 GPUs. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
Add Adreno 640 and 650 GPU info to the gpulist. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
This gives more fine-grained control over how memory is allocated over the DMA api. In particular, it allows using an address range or pinning to a fixed address. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
This flag sets IOMMU_PRIV, which is required for some a6xx GMU objects. Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeauorora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jonathan Marek authored
This function allows pinning iova to a specific page range (for a6xx GMU). Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Writing to the devfreq sysfs nodes while the GPU is powered down can result in a system crash (on a5xx) or a nasty GMU error (on a6xx): $ /sys/class/devfreq/5000000.gpu# echo 500000000 > min_freq [ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0 Despite the fact that we carefully try to suspend the devfreq device when the hardware is powered down there are lots of holes in the governors that don't check for the suspend state and blindly call into the devfreq callbacks that end up triggering hardware reads in the GPU driver. Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq() callbacks to skip the hardware access if it isn't active. v3: Only check pm_runtime_get_if_in_use() for == 0 per Eric Anholt v2: Use pm_runtime_get_if_in_use() per Eric Anholt Cc: stable@vger.kernel.org Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Krishna Manikandan authored
Maximum allowed bandwidth has no dependency on the type of panel used. Hence, cleanup the code to use max_bw_high as the threshold value for bandwidth checks. Update the maximum allowed bandwidth as 6.8Gbps for SC7180 target. Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kalyan Thota authored
This change adds support to scale src clk and bandwidth as per composition requirements. Interconnect registration for bw has been moved to mdp device node from mdss to facilitate the scaling. Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kalyan Thota authored
This change adds support for color correction sub block for SC7180 device. Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Tested-by: Fritz Koenig <frkoenig@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kalyan Thota authored
This change adds support to configure dspp blocks in the dpu driver. Macro description of the changes coming in this patch. 1) Add dspp definitions in the hw catalog. 2) Add capability to reserve dspp blocks in the display data path. 3) Attach the reserved block to the encoder. Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org> Tested-by: Fritz Koenig <frkoenig@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Roy Spliet authored
When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet <nouveau@spliet.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Christophe JAILLET authored
Duplicated 'we' Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Bjorn Andersson authored
rd_full should be defined outside the CONFIG_DEBUG_FS region, in order to be able to link the msm driver even when CONFIG_DEBUG_FS is disabled. Fixes: e515af8d ("drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP buffers") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Bas Nieuwenhuizen authored
This 1) Enables core DRM syncobj support. 2) Adds options to the submission ioctl to wait/signal syncobjs. Just like the wait fence fd, this does inline waits. Using the scheduler would be nice but I believe it is out of scope for this work. Support for timeline syncobjs is implemented and the interface is ready for it, but I'm not enabling it yet until there is some code for turnip to use it. The reset is mostly in there because in the presence of waiting and signalling the same semaphores, resetting them after signalling can become very annoying. v2: - Fixed style issues - Removed a cleanup issue in a failure case - Moved to a copy_from_user per syncobj v3: - Fixed a missing declaration introduced in v2 - Reworked to use ERR_PTR/PTR_ERR - Simplified failure gotos. Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2769Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Hongbo Yao authored
Using the following command will get compile warnings: make W=1 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.o ARCH=arm64 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘_dpu_crtc_program_lm_output_roi’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:91:19: warning: variable ‘dpu_crtc’ set but not used [-Wunused-but-set-variable] struct dpu_crtc *dpu_crtc; ^~~~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_atomic_begin’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:428:35: warning: variable ‘smmu_state’ set but not used [-Wunused-but-set-variable] struct dpu_crtc_smmu_state_data *smmu_state; ^~~~~~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_atomic_flush’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:489:25: warning: variable ‘event_thread’ set but not used [-Wunused-but-set-variable] struct msm_drm_thread *event_thread; ^~~~~~~~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_destroy_state’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:565:19: warning: variable ‘dpu_crtc’ set but not used [-Wunused-but-set-variable] struct dpu_crtc *dpu_crtc; ^~~~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_duplicate_state’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:664:19: warning: variable ‘dpu_crtc’ set but not used [-Wunused-but-set-variable] struct dpu_crtc *dpu_crtc; ^~~~~~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_disable’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:693:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] struct msm_drm_private *priv; ^~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:691:27: warning: variable ‘mode’ set but not used [-Wunused-but-set-variable] struct drm_display_mode *mode; ^~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_enable’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:766:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] struct msm_drm_private *priv; ^~~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c: In function ‘dpu_crtc_init’: drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:1292:18: warning: variable ‘kms’ set but not used [-Wunused-but-set-variable] struct dpu_kms *kms = NULL; ^~~ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:663: warning: Excess function parameter 'Returns' description in 'dpu_crtc_duplicate_state' Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Hongbo Yao <yaohongbo@huawei.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Christophe JAILLET authored
'in' is duplicated in the error message. Axe one of them. While at it, slighly improve indentation. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Konrad Dybcio authored
This change adds MDP5 configuration for MSM8x36-based SoCs, like MSM8936, 8939 and their APQ variants. The configuration is based on MSM8916's, but adds some notable features, like ad and pp blocks, along with some register changes. changes since v1: - add an ad block - add a second mixer @ 0x47000 - adjust .max_width - write a more descriptive commit message Signed-off-by: Konrad Dybcio <konradybcio@gmail.com> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.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 4 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>
-