- Sep 02, 2022
-
-
SeongJae Park authored
The advertisement of the persistent grants feature (writing 'feature-persistent' to xenbus) should mean not the decision for using the feature but only the availability of the feature. However, commit aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") made a field of blkback, which was a place for saving only the negotiation result, to be used for yet another purpose: caching of the 'feature_persistent' parameter value. As a result, the advertisement, which should follow only the parameter value, becomes inconsistent. This commit fixes the misuse of the semantic by making blkback saves the parameter value in a separate place and advertises the support based on only the saved value. Fixes: aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <stable@vger.kernel.org> # 5.10.x Suggested-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
SeongJae Park <sj@kernel.org> Tested-by:
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by:
-
- Aug 25, 2022
-
-
Juergen Gross authored
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages() potentially with pages being NULL, leading to a NULL dereference. Additionally lock_pages() doesn't check for pin_user_pages_fast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode. Fix all of that by calling unlock_pages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pin_user_pages_fast() matching the expected number of pages. Cc: <stable@vger.kernel.org> Fixes: ab520be8 ("xen/privcmd: Add IOCTL_PRIVCMD_DM_OP") Reported-by:
Rustam Subkhankulov <subkhankulov@ispras.ru> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Link: https://lore.kernel.org/r/20220825141918.3581-1-jgross@suse.com Signed-off-by:
-
Wolfram Sang authored
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
-
Lukas Bulwahn authored
Commit c70727a5 ("xen: allow more than 512 GB of RAM for 64 bit pv-domains") from July 2015 replaces the config XEN_MAX_DOMAIN_MEMORY with a new config XEN_512GB, but misses to adjust arch/x86/configs/xen.config. As XEN_512GB defaults to yes, there is no need to explicitly set any config in xen.config. Just remove setting the obsolete config XEN_MAX_DOMAIN_MEMORY. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
-
- Aug 12, 2022
-
-
Lukas Bulwahn authored
Make changes to the xen config fragments reach the XEN HYPERVISOR maintainers and mailing list. Signed-off-by:
-
Lukas Bulwahn authored
Commit 197ecb38 ("xen/balloon: add runtime control for scrubbing ballooned out pages") changed config XEN_SCRUB_PAGES to config XEN_SCRUB_PAGES_DEFAULT. As xen.config sets 'XEN_BALLOON=y' and XEN_SCRUB_PAGES_DEFAULT defaults to yes, there is no further need to set this config in the xen.config file. Remove setting XEN_SCRUB_PAGES in xen.config, which is without effect since the commit above anyway. Signed-off-by:
-
Jason Wang authored
The double `the' is duplicated in the comment, remove one. Signed-off-by:
Jason Wang <wangborong@cdjrlc.com> Reviewed-by:
-
Dan Carpenter authored
This code tries to store -EFAULT in an unsigned int. The xenbus_file_read() function returns type ssize_t so the negative value is returned as a positive value to the user. This change forces another change to the min() macro. Originally, the min() macro used "unsigned" type which checkpatch complains about. Also unsigned type would break if "len" were not capped at MAX_RW_COUNT. Use size_t for the min(). (No effect on runtime for the min_t() change). Fixes: 2fb3683e ("xen: Add xenbus device driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
SeongJae Park authored
In some use cases[1], the backend is created while the frontend doesn't support the persistent grants feature, but later the frontend can be changed to support the feature and reconnect. In the past, 'blkback' enabled the persistent grants feature since it unconditionally checked if frontend supports the persistent grants feature for every connect ('connect_ring()') and decided whether it should use persistent grans or not. However, commit aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") has mistakenly changed the behavior. It made the frontend feature support check to not be repeated once it shown the 'feature_persistent' as 'false', or the frontend doesn't support persistent grants. Similar behavioral change has made on 'blkfront' by commit 74a85247 ("xen-blkfront: add a parameter for disabling of persistent grants"). This commit changes the behavior of the parameter to make effect for every connect, so that the previous behavior of 'blkfront' can be restored. [1] https://lore.kernel.org/xen-devel/CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com/ Fixes: 74a85247 ("xen-blkfront: add a parameter for disabling of persistent grants") Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by:Maximilian Heyne <mheyne@amazon.de> Reviewed-by:
-
Maximilian Heyne authored
In some use cases[1], the backend is created while the frontend doesn't support the persistent grants feature, but later the frontend can be changed to support the feature and reconnect. In the past, 'blkback' enabled the persistent grants feature since it unconditionally checked if frontend supports the persistent grants feature for every connect ('connect_ring()') and decided whether it should use persistent grans or not. However, commit aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") has mistakenly changed the behavior. It made the frontend feature support check to not be repeated once it shown the 'feature_persistent' as 'false', or the frontend doesn't support persistent grants. This commit changes the behavior of the parameter to make effect for every connect, so that the previous workflow can work again as expected. [1] https://lore.kernel.org/xen-devel/CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com/ Reported-by:Andrii Chepurnyi <andrii.chepurnyi82@gmail.com> Fixes: aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by:
-
SeongJae Park authored
Persistent grants feature can be used only when both backend and the frontend supports the feature. The feature was always supported by 'blkback', but commit aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") has introduced a parameter for disabling it runtime. To avoid the parameter be updated while being used by 'blkback', the commit caches the parameter into 'vbd->feature_gnt_persistent' in 'xen_vbd_create()', and then check if the guest also supports the feature and finally updates the field in 'connect_ring()'. However, 'connect_ring()' could be called before 'xen_vbd_create()', so later execution of 'xen_vbd_create()' can wrongly overwrite 'true' to 'vbd->feature_gnt_persistent'. As a result, 'blkback' could try to use 'persistent grants' feature even if the guest doesn't support the feature. This commit fixes the issue by moving the parameter value caching to 'xen_blkif_alloc()', which allocates the 'blkif'. Because the struct embeds 'vbd' object, which will be used by 'connect_ring()' later, this should be called before 'connect_ring()' and therefore this should be the right and safe place to do the caching. Fixes: aac8a70d ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <stable@vger.kernel.org> # 5.10.x Signed-off-by:
-
Jane Malalane authored
Implement support for the HVMOP_set_evtchn_upcall_vector hypercall in order to set the per-vCPU event channel vector callback on Linux and use it in preference of HVM_PARAM_CALLBACK_IRQ. If the per-VCPU vector setup is successful on BSP, use this method for the APs. If not, fallback to the global vector-type callback. Also register callback_irq at per-vCPU event channel setup to trick toolstack to think the domain is enlightened. Suggested-by:
"Roger Pau Monné" <roger.pau@citrix.com> Signed-off-by:
Jane Malalane <jane.malalane@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20220729070416.23306-1-jane.malalane@citrix.com Signed-off-by:
-
- Aug 01, 2022
-
-
Juergen Gross authored
Commit fa1f5742 ("xen/virtio: Enable restricted memory access using Xen grant mappings") introduced a new requirement for using virtio devices: the backend now needs to support the VIRTIO_F_ACCESS_PLATFORM feature. This is an undue requirement for non-PV guests, as those can be operated with existing backends without any problem, as long as those backends are running in dom0. Per default allow virtio devices without grant support for non-PV guests. On Arm require VIRTIO_F_ACCESS_PLATFORM for devices having been listed in the device tree to use grants. Add a new config item to always force use of grants for virtio. Fixes: fa1f5742 ("xen/virtio: Enable restricted memory access using Xen grant mappings") Reported-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20220622063838.8854-4-jgross@suse.com Signed-off-by:
-
Juergen Gross authored
The only use case of the platform_has() infrastructure has been removed again, so remove the whole feature. Signed-off-by:
-
Juergen Gross authored
Instead of having a global flag to require restricted memory access for all virtio devices, introduce a callback which can select that requirement on a per-device basis. For convenience add a common function returning always true, which can be used for use cases like SEV. Per default use a callback always returning false. As the callback needs to be set in early init code already, add a virtio anchor which is builtin in case virtio is enabled. Signed-off-by:
-
Zhang Jiaming authored
Change 'maped' to 'mapped'. Change 'unmaped' to 'unmapped'. Signed-off-by:
Zhang Jiaming <jiaming@nfschina.com> Reviewed-by:
-
Ross Lagerwall authored
Currently when the toolstack issues a reboot, it gets translated into a call to ctrl_alt_del(). But tying reboot to ctrl-alt-del means rebooting may fail if e.g. the user has masked the ctrl-alt-del.target under systemd. A previous attempt to fix this issue made a change that sets the kernel.ctrl-alt-del sysctl to 1 before ctrl_alt_del() is called. However, this doesn't give userspace the opportunity to block rebooting or even do any cleanup or syncing. Instead, call orderly_reboot() which will call the "reboot" command, giving userspace the opportunity to block it or perform the usual reboot process while being independent of the ctrl-alt-del behaviour. It also matches what happens in the shutdown case. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linuxLinus Torvalds authored
Pull clk fix from Stephen Boyd: "One-liner fix of a NULL pointer deref in the Allwinner clk driver" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi-ng: Fix H6 RTC clock definition
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Borislav Petkov: - Update the 'mitigations=' kernel param documentation - Check the IBPB feature flag before enabling IBPB in firmware calls because cloud vendors' fantasy when it comes to creating guest configurations is unlimited - Unexport sev_es_ghcb_hv_call() before 5.19 releases now that HyperV doesn't need it anymore - Remove dead CONFIG_* items * tag 'x86_urgent_for_v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: docs/kernel-parameters: Update descriptions for "mitigations=" param with retbleed x86/bugs: Do not enable IBPB at firmware entry when IBPB is not available Revert "x86/sev: Expose sev_es_ghcb_hv_call() for use by HyperV" x86/configs: Update configs in x86_debug.config
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull locking fix from Borislav Petkov: - Avoid rwsem lockups in certain situations when handling the handoff bit * tag 'locking_urgent_for_v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/rwsem: Allow slowpath writer to ignore handoff bit if not set by first waiter
-
git://git.kernel.org/pub/scm/linux/kernel/git/ras/rasLinus Torvalds authored
Pull EDAC fixes from Borislav Petkov: - Relax the condition under which the DIMM label in ghes_edac is set in order to accomodate an HPE BIOS which sets only the device but not the bank - Two forgotten fixes to synopsys_edac when handling error interrupts * tag 'edac_urgent_for_v5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/ghes: Set the DIMM label unconditionally EDAC/synopsys: Re-enable the error interrupts on v3 hw EDAC/synopsys: Use the correct register to disable the error interrupt on v3 hw
-
- Jul 31, 2022
-
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: "Last set of ARM fixes for 5.19: - fix for MAX_DMA_ADDRESS overflow - fix for find_*_bit performing an out of bounds memory access" * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: findbit: fix overflowing offset ARM: 9216/1: Fix MAX_DMA_ADDRESS overflow
-
- Jul 30, 2022
-
-
Waiman Long authored
With commit d257cc8c ("locking/rwsem: Make handoff bit handling more consistent"), the writer that sets the handoff bit can be interrupted out without clearing the bit if the wait queue isn't empty. This disables reader and writer optimistic lock spinning and stealing. Now if a non-first writer in the queue is somehow woken up or a new waiter enters the slowpath, it can't acquire the lock. This is not the case before commit d257cc8c as the writer that set the handoff bit will clear it when exiting out via the out_nolock path. This is less efficient as the busy rwsem stays in an unlock state for a longer time. In some cases, this new behavior may cause lockups as shown in [1] and [2]. This patch allows a non-first writer to ignore the handoff bit if it is not originally set or initiated by the first waiter. This patch is shown to be effective in fixing the lockup problem reported in [1]. [1] https://lore.kernel.org/lkml/20220617134325.GC30825@techsingularity.net/ [2] https://lore.kernel.org/lkml/3f02975c-1a9d-be20-32cf-f1d8e3dfafcc@oracle.com/ Fixes: d257cc8c ("locking/rwsem: Make handoff bit handling more consistent") Signed-off-by:
Waiman Long <longman@redhat.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
John Donnelly <john.p.donnelly@oracle.com> Tested-by:
Mel Gorman <mgorman@techsingularity.net> Link: https://lore.kernel.org/r/20220622200419.778799-1-longman@redhat.com
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull misc fixes from Andrew Morton: "Two hotfixes, both cc:stable" * tag 'mm-hotfixes-stable-2022-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/hmm: fault non-owner device private entries page_alloc: fix invalid watermark check on a negative value
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fix from Jens Axboe: "Just a single fix for NVMe, yet another quirk addition" * tag 'block-5.19-2022-07-29' of git://git.kernel.dk/linux-block: nvme-pci: Crucial P2 has bogus namespace ids
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull more drm fixes from Dave Airlie: "Maxime had the dog^Wmailing list server eat his homework^Wmisc pull request. Two more small fixes, one in nouveau svm code and the other in simpledrm. nouveau: - page migration fix simpledrm: - fix mode_valid return value" * tag 'drm-fixes-2022-07-30' of git://anongit.freedesktop.org/drm/drm: nouveau/svm: Fix to migrate all requested pages drm/simpledrm: Fix return type of simpledrm_simple_display_pipe_mode_valid()
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
One fix to fix simpledrm mode_valid return value, and one for page migration in nouveau Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220729094514.sfzhc3gqjgwgal62@penduick
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Four fixes, three in drivers. The two biggest fixes are ufs and the remaining driver and core fix are small and obvious (and the core fix is low risk)" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Fix a race condition related to device management scsi: core: Fix warning in scsi_alloc_sgtables() scsi: ufs: host: Hold reference returned by of_parse_phandle() scsi: mpt3sas: Stop fw fault watchdog work item during system shutdown
-
Eiichi Tsukata authored
Updates descriptions for "mitigations=off" and "mitigations=auto,nosmt" with the respective retbleed= settings. Signed-off-by:
Eiichi Tsukata <eiichi.tsukata@nutanix.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: corbet@lwn.net Link: https://lore.kernel.org/r/20220728043907.165688-1-eiichi.tsukata@nutanix.com
-
Ralph Campbell authored
If hmm_range_fault() is called with the HMM_PFN_REQ_FAULT flag and a device private PTE is found, the hmm_range::dev_private_owner page is used to determine if the device private page should not be faulted in. However, if the device private page is not owned by the caller, hmm_range_fault() returns an error instead of calling migrate_to_ram() to fault in the page. For example, if a page is migrated to GPU private memory and a RDMA fault capable NIC tries to read the migrated page, without this patch it will get an error. With this patch, the page will be migrated back to system memory and the NIC will be able to read the data. Link: https://lkml.kernel.org/r/20220727000837.4128709-2-rcampbell@nvidia.com Link: https://lkml.kernel.org/r/20220725183615.4118795-2-rcampbell@nvidia.com Fixes: 08ddddda ("mm/hmm: check the device private page owner in hmm_range_fault()") Signed-off-by:
Ralph Campbell <rcampbell@nvidia.com> Reported-by:
Felix Kuehling <felix.kuehling@amd.com> Reviewed-by:
Alistair Popple <apopple@nvidia.com> Cc: Philip Yang <Philip.Yang@amd.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Jaewon Kim authored
There was a report that a task is waiting at the throttle_direct_reclaim. The pgscan_direct_throttle in vmstat was increasing. This is a bug where zone_watermark_fast returns true even when the free is very low. The commit f27ce0e1 ("page_alloc: consider highatomic reserve in watermark fast") changed the watermark fast to consider highatomic reserve. But it did not handle a negative value case which can be happened when reserved_highatomic pageblock is bigger than the actual free. If watermark is considered as ok for the negative value, allocating contexts for order-0 will consume all free pages without direct reclaim, and finally free page may become depleted except highatomic free. Then allocating contexts may fall into throttle_direct_reclaim. This symptom may easily happen in a system where wmark min is low and other reclaimers like kswapd does not make free pages quickly. Handle the negative case by using MIN. Link: https://lkml.kernel.org/r/20220725095212.25388-1-jaewon31.kim@samsung.com Fixes: f27ce0e1 ("page_alloc: consider highatomic reserve in watermark fast") Signed-off-by:
Jaewon Kim <jaewon31.kim@samsung.com> Reported-by:
GyeongHwan Hong <gh21.hong@samsung.com> Acked-by:
-
Linus Torvalds authored
Merge tag 'perf-tools-fixes-for-v5.19-2022-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Fix addresses for bss symbols, describing variables used in resolving data access in tools such as 'perf c2c' and 'perf mem'. - Skip symbols if SHF_ALLOC flag is not set, a technique used for listing deprecated symbols, its addresses are zeros, so not useful. - Remove undefined behavior from bpf_perf_object__next() when dealing with an empty bpf_objects_list list. - Make a ARM CoreSight disasm script work with both python2 and python3. - Sync x86's cpufeatures header with with the kernel sources. * tag 'perf-tools-fixes-for-v5.19-2022-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf bpf: Remove undefined behavior from bpf_perf_object__next() perf symbol: Skip symbols if SHF_ALLOC flag is not set perf symbol: Correct address for bss symbols perf scripts python: Let script to be python2 compliant tools headers cpufeatures: Sync with the kernel sources
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds authored
Pull workqueue fix from Tejun Heo: "Just one commit to suppress a spurious warning added during the 5.19 cycle" * tag 'wq-for-5.19-rc8-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Avoid a false warning in unbind_workers()
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull power management fix from Rafael Wysocki: "Make some false positive RCU splats resulting from a recent intel_idle driver change go away (Waiman Long)" * tag 'pm-5.19-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: intel_idle: Fix false positive RCU splats due to incorrect hardirqs state
-
Lai Jiangshan authored
Doing set_cpus_allowed_ptr() with wq_unbound_cpumask can be possible fails and trigger the false warning. Use cpu_possible_mask instead when wq_unbound_cpumask has no active CPUs. It is very easy to trigger the warning: Set wq_unbound_cpumask to a small set of CPUs. Offline all the CPUs of wq_unbound_cpumask. Offline an extra CPU and trigger the warning. Fixes: 10a5a651 ("workqueue: Restrict kworker in the offline CPU pool running on housekeeping CPUs") Signed-off-by:
Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by:
Tejun Heo <tj@kernel.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fix from Palmer Dabbelt: "A build fix for 'make vdso_install' that avoids an issue trying to install the compat VDSO" * tag 'riscv-for-linus-5.19-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: compat: vdso: Fix vdso_install target
-
Linus Torvalds authored
Merge tag 'loongarch-fixes-5.19-5' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson Pull LoongArch fixes from Huacai Chen: - Fix cache size calculation, stack protection attributes, ptrace's fpr_set and "ROM Size" in boardinfo - Some cleanups and improvements of assembly - Some cleanups of unused code and useless code * tag 'loongarch-fixes-5.19-5' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch: Fix wrong "ROM Size" of boardinfo LoongArch: Fix missing fcsr in ptrace's fpr_set LoongArch: Fix shared cache size calculation LoongArch: Disable executable stack by default LoongArch: Remove unused variables LoongArch: Remove clock setting during cpu hotplug stage LoongArch: Remove useless header compiler.h LoongArch: Remove several syntactic sugar macros for branches LoongArch: Re-tab the assembly files LoongArch: Simplify "BGT foo, zero" with BGTZ LoongArch: Simplify "BLT foo, zero" with BLTZ LoongArch: Simplify "BEQ/BNE foo, zero" with BEQZ/BNEZ LoongArch: Use the "move" pseudo-instruction where applicable LoongArch: Use the "jr" pseudo-instruction where applicable LoongArch: Use ABI names of registers where appropriate
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Re-enable the new amdgpu display engine for powerpc, as long as the compiler is correctly configured. - Disable stack variable initialisation in prom_init to fix GCC 12 allmodconfig. Thanks to Dan Horák and Sudip Mukherjee. * tag 'powerpc-5.19-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: drm/amdgpu: Re-enable DCN for 64-bit powerpc powerpc/64s: Disable stack variable initialisation for prom_init
-
- Jul 29, 2022
-
-
Tiezhu Yang authored
We can see the "ROM Size" is different in the following outputs: [root@linux loongson]# cat /sys/firmware/loongson/boardinfo BIOS Information Vendor : Loongson Version : vUDK2018-LoongArch-V2.0.pre-beta8 ROM Size : 63 KB Release Date : 06/15/2022 Board Information Manufacturer : Loongson Board Name : Loongson-LS3A5000-7A1000-1w-A2101 Family : LOONGSON64 [root@linux loongson]# dmidecode | head -11 ... Handle 0x0000, DMI type 0, 26 bytes BIOS Information Vendor: Loongson Version: vUDK2018-LoongArch-V2.0.pre-beta8 Release Date: 06/15/2022 ROM Size: 4 MB According to "BIOS Information (Type 0) structure" in the SMBIOS Reference Specification [1], it shows 64K * (n+1) is the size of the physical device containing the BIOS if the size is less than 16M. Additionally, we can see the related code in dmidecode [2]: u64 s = { .l = (code1 + 1) << 6 }; So the output of dmidecode is correct, the output of boardinfo is wrong, fix it. By the way, at present no need to consider the size is 16M or greater on LoongArch, because it is usually 4M or 8M which is enough to use. [1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.6.0.pdf [2] https://git.savannah.nongnu.org/cgit/dmidecode.git/tree/dmidecode.c#n347 Fixes: 628c3bb4 ("LoongArch: Add boot and setup routines") Reviewed-by:WANG Xuerui <git@xen0n.name> Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
