aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-28net: mscc: ocelot: fix tagged VLAN refusal while under a VLAN-unaware bridgeVladimir Oltean1-0/+7
Currently the following set of commands fails: $ ip link add br0 type bridge # vlan_filtering 0 $ ip link set swp0 master br0 $ bridge vlan port vlan-id swp0 1 PVID Egress Untagged $ bridge vlan add dev swp0 vid 10 Error: mscc_ocelot_switch_lib: Port with more than one egress-untagged VLAN cannot have egress-tagged VLANs. Dumping ocelot->vlans, one can see that the 2 egress-untagged VLANs on swp0 are vid 1 (the bridge PVID) and vid 4094, a PVID used privately by the driver for VLAN-unaware bridging. So this is why bridge vid 10 is refused, despite 'bridge vlan' showing a single egress untagged VLAN. As mentioned in the comment added, having this private VLAN does not impose restrictions to the hardware configuration, yet it is a bookkeeping problem. There are 2 possible solutions. One is to make the functions that operate on VLAN-unaware pvids: - ocelot_add_vlan_unaware_pvid() - ocelot_del_vlan_unaware_pvid() - ocelot_port_setup_dsa_8021q_cpu() - ocelot_port_teardown_dsa_8021q_cpu() call something different than ocelot_vlan_member_(add|del)(), the latter being the real problem, because it allocates a struct ocelot_bridge_vlan *vlan which it adds to ocelot->vlans. We don't really *need* the private VLANs in ocelot->vlans, it's just that we have the extra convenience of having the vlan->portmask cached in software (whereas without these structures, we'd have to create a raw ocelot_vlant_rmw_mask() procedure which reads back the current port mask from hardware). The other solution is to filter out the private VLANs from ocelot_port_num_untagged_vlans(), since they aren't what callers care about. We only need to do this to the mentioned function and not to ocelot_port_num_tagged_vlans(), because private VLANs are never egress-tagged. Nothing else seems to be broken in either solution, but the first one requires more rework which will conflict with the net-next change 36a0bf443585 ("net: mscc: ocelot: set up tag_8021q CPU ports independent of user port affinity"), and I'd like to avoid that. So go with the other one. Fixes: 54c319846086 ("net: mscc: ocelot: enforce FDB isolation when VLAN-unaware") Signed-off-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-28clk: imx93: drop of_match_ptrPeng Fan1-1/+1
There is build warning when CONFIG_OF is not selected. >> drivers/clk/imx/clk-imx93.c:324:34: warning: 'imx93_clk_of_match' >> defined but not used [-Wunused-const-variable=] 324 | static const struct of_device_id imx93_clk_of_match[] = { | ^~~~~~~~~~~~~~~~~~ The driver only support DT table, no sense to use of_match_ptr. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Reported-by: kernel test robot <[email protected]> Signed-off-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-28clk: iproc: Do not rely on node name for correct PLL setupFlorian Fainelli1-4/+8
After commit 31fd9b79dc58 ("ARM: dts: BCM5301X: update CRU block description") a warning from clk-iproc-pll.c was generated due to a duplicate PLL name as well as the console stopped working. Upon closer inspection it became clear that iproc_pll_clk_setup() used the Device Tree node unit name as an unique identifier as well as a parent name to parent all clocks under the PLL. BCM5301X was the first platform on which that got noticed because of the DT node unit name renaming but the same assumptions hold true for any user of the iproc_pll_clk_setup() function. The first 'clock-output-names' property is always guaranteed to be unique as well as providing the actual desired PLL clock name, so we utilize that to register the PLL and as a parent name of all children clock. Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support") Signed-off-by: Florian Fainelli <[email protected]> Acked-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2022-09-28io_uring/poll: disable level triggered pollJens Axboe1-1/+1
Stefan reports that there are issues with the level triggered notification. Since we're late in the cycle, and it was introduced for the 6.0 release, just disable it at prep time and we can bring this back when Samba is happy with it. Reported-by: Stefan Metzmacher <[email protected]> Reviewed-by: Stefan Metzmacher <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2022-09-28clk: sunxi-ng: h6: Fix default PLL GPU rateJernej Skrabec1-2/+6
In commit 4167ac8a657e ("clk: sunxi-ng: sun50i: h6: Modify GPU clock configuration to support DFS") divider M0 was forced to be 1 in order to support DFS. However, that left N as it is, at high value of 36. On boards without devfreq enabled (all of them in kernel 6.0), this effectively sets GPU frequency to 864 MHz. This is about 100 MHz above maximum supported frequency. In order to fix this, let's set N to 18 (register value 17). That way default frequency of 432 MHz is preserved. Fixes: 4167ac8a657e ("clk: sunxi-ng: sun50i: h6: Modify GPU clock configuration to support DFS") Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2022-09-28drm/i915/gt: Perf_limit_reasons are only available for Gen11+Ashutosh Dixit1-4/+11
Register GT0_PERF_LIMIT_REASONS (0x1381a8) is available only for Gen11+. Therefore ensure perf_limit_reasons sysfs files are created only for Gen11+. Otherwise on Gen < 5 accessing these files results in the following oops: <1> [88.829420] BUG: unable to handle page fault for address: ffffc90000bb81a8 <1> [88.829438] #PF: supervisor read access in kernel mode <1> [88.829447] #PF: error_code(0x0000) - not-present page This patch is a backport of the drm-tip commit 0d2d201095e9 ("drm/i915: Perf_limit_reasons are only available for Gen11+") to drm-intel-fixes. The backport is not identical to the original, it only includes the sysfs portions of if. The debugfs portion is not available in drm-intel-fixes so has not been backported. Bspec: 20008 Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6863 Fixes: fa68bff7cf27 ("drm/i915/gt: Add sysfs throttle frequency interfaces") Signed-off-by: Ashutosh Dixit <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (backported from commit 0d2d201095e9f141d6a9fb44320afce761f8b5c2)
2022-09-28clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocksHan Xu1-2/+2
There is no dedicate parent clock for QSPI so SET_RATE_PARENT flag should not be used. For instance, the default parent clock for QSPI is pll2_bus, which is also the parent clock for quite a few modules, such as MMDC, once GPMI NAND set clock rate for EDO5 mode can cause system hang due to pll2_bus rate changed. Fixes: f1541e15e38e ("clk: imx6sx: Switch to clk_hw based API") Signed-off-by: Han Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Fabio Estevam <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2022-09-28m68k: Rework BI_VIRT_RNG_SEED as BI_RNG_SEEDJason A. Donenfeld4-18/+21
This is useful on !virt platforms for kexec, so change things from BI_VIRT_RNG_SEED to be BI_RNG_SEED, and simply remove BI_VIRT_RNG_SEED because it only ever lasted one release, and nothing is broken by not having it. At the same time, keep a comment noting that it's been removed, so that ID isn't reused. In addition, we previously documented 2-byte alignment, but 4-byte alignment is actually necessary, so update that comment. Suggested-by: Geert Uytterhoeven <[email protected]> Fixes: a1ee38ab1a75 ("m68k: virt: Use RNG seed from bootinfo block") Signed-off-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2022-09-28m68k: Process bootinfo records before saving themJason A. Donenfeld1-2/+3
The RNG seed boot record is memzeroed after processing, in order to preserve forward secrecy. By saving the bootinfo for procfs prior to that, forward secrecy is violated, since it becomes possible to recover past states. So, save the bootinfo block only after first processing them. Fixes: a1ee38ab1a75 ("m68k: virt: Use RNG seed from bootinfo block") Signed-off-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2022-09-28ACPI: x86: s2idle: Add another ID to s2idle_dmi_tableMario Limonciello1-0/+11
It's reported that "ASUSTeK COMPUTER INC. ROG Flow X16 GV601RW" has non-functional fans after resume when using the AMD codepath. This issue is fixed using the Microsoft codepath. Add the 3 variants of this system to the Microsoft codepath DMI table. * GV601RW * GV601RM * GV601RE Link: https://www.reddit.com/r/linuxhardware/comments/wh50nd/compatibility_report_asus_rog_flow_x16_gv601rm/ Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2148#note_1571241 Reported-by: Luke Jones <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-09-28ACPI: x86: s2idle: Fix a NULL pointer dereferenceMario Limonciello1-1/+1
Ryzen 7000 (Raphael) introduced AMDI0008 for _HID. This ID was added in commit ed470febf837 ("ACPI: PM: s2idle: Add support for upcoming AMD uPEP HID AMDI008"), but then removed in favor of aligning all new IDs to Rembrandt support in commit fd894f05cf30 ("ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt"). Unfortunately there was a mistake in commit 100a57379380 ("ACPI: x86: s2idle: Move _HID handling for AMD systems into structures") that can lead to a NULL pointer dereference accessing `dev_id->driver_data` in the sentinel of `amd_hid_ids`. Fix this dereference. Reported-by: Richard Gong <[email protected]> Fixes: 100a57379380 ("ACPI: x86: s2idle: Move _HID handling for AMD systems into structures") Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-09-28Merge tag 'irq_urgent_for_v6.0' of ↵Linus Torvalds3-8/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull more irqchip fixes from Borislav Petkov: "More irqchip fixes for 6.0 from Marc Zyngier. Stuff got left hanging due to the whole Plumbers and vacations commotion. - A couple of configuration fixes for the recently merged Loongarch drivers - A fix to avoid dynamic allocation of a cpumask which was causing issues with PREEMPT_RT and the GICv3 ITS - A tightening of an error check in the stm32 exti driver" * tag 'irq_urgent_for_v6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/loongson-pch-lpc: Add dependence on LoongArch irqchip: Select downstream irqchip drivers for LoongArch CPU irqchip/gic-v3-its: Remove cpumask_var_t allocation irqchip/stm32-exti: Remove check on always false condition
2022-09-28Merge tag 'mmc-v6.0-rc5' of ↵Linus Torvalds5-44/+8
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "A couple of MMC fixes. This time there is also a fix for the ARM SCMI firmware driver, which has been acked by Sudeep Holla, the maintainer. MMC core: - Terminate infinite loop in SD-UHS voltage switch MMC host: - hsq: Fix kernel crash in the recovery path - moxart: Fix bus width configurations - sdhci: Fix kernel panic for cqe irq ARM_SCMI: - Fixup clock management by reverting 'firmware: arm_scmi: Add clock management to the SCMI power domain'" * tag 'mmc-v6.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: hsq: Fix data stomping during mmc recovery Revert "firmware: arm_scmi: Add clock management to the SCMI power domain" mmc: core: Terminate infinite loop in SD-UHS voltage switch mmc: moxart: fix 4-bit bus width and remove 8-bit bus width mmc: sdhci: Fix host->cmd is null
2022-09-28[coredump] don't use __kernel_write() on kmap_local_page()Al Viro3-13/+50
passing kmap_local_page() result to __kernel_write() is unsafe - random ->write_iter() might (and 9p one does) get unhappy when passed ITER_KVEC with pointer that came from kmap_local_page(). Fix by providing a variant of __kernel_write() that takes an iov_iter from caller (__kernel_write() becomes a trivial wrapper) and adding dump_emit_page() that parallels dump_emit(), except that instead of __kernel_write() it uses __kernel_write_iter() with ITER_BVEC source. Fixes: 3159ed57792b "fs/coredump: use kmap_local_page()" Signed-off-by: Al Viro <[email protected]>
2022-09-28Merge tag 'clk-microchip-fixes-6.0' of ↵Stephen Boyd1-2/+9
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-fixes Pull Microchip clock fixes for Polarfire SoCs: - fix panic at boot in clock initialization when building with clang-15 - make RTC's AHB clock critical as rtc will stop if the AHB interface clock is disabled * tag 'clk-microchip-fixes-6.0' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: clk: microchip: mpfs: make the rtc's ahb clock critical clk: microchip: mpfs: fix clk_cfg array bounds violation
2022-09-28Merge tag 'linux-can-fixes-for-6.0-20220928' of ↵Jakub Kicinski2-8/+20
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2022-09-28 The patch is by me and targets the c_can driver. It disables an optimization in the TX path of C_CAN cores which causes problems. * tag 'linux-can-fixes-for-6.0-20220928' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: c_can: don't cache TX messages for C_CAN cores ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-09-28x86/cacheinfo: Add a cpu_llc_shared_mask() UP variantBorislav Petkov1-10/+15
On a CONFIG_SMP=n kernel, the LLC shared mask is 0, which prevents __cache_amd_cpumap_setup() from doing the L3 masks setup, and more specifically from setting up the shared_cpu_map and shared_cpu_list files in sysfs, leading to lscpu from util-linux getting confused and segfaulting. Add a cpu_llc_shared_mask() UP variant which returns a mask with a single bit set, i.e., for CPU0. Fixes: 2b83809a5e6d ("x86/cpu/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask") Reported-by: Saurabh Sengar <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-09-28Revert "net: set proper memcg for net_init hooks allocations"Shakeel Butt2-52/+0
This reverts commit 1d0403d20f6c281cb3d14c5f1db5317caeec48e9. Anatoly Pugachev reported that the commit 1d0403d20f6c ("net: set proper memcg for net_init hooks allocations") is somehow causing the sparc64 VMs failed to boot and the VMs boot fine with that patch reverted. So, revert the patch for now and later we can debug the issue. Link: https://lore.kernel.org/all/[email protected]/ Reported-by: Anatoly Pugachev <[email protected]> Signed-off-by: Shakeel Butt <[email protected]> Cc: Vasily Averin <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Michal Koutný <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Tested-by: Anatoly Pugachev <[email protected]> Acked-by: Johannes Weiner <[email protected]> Fixes: 1d0403d20f6c ("net: set proper memcg for net_init hooks allocations") Reviewed-by: Muchun Song <[email protected]> Acked-by: Roman Gushchin <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2022-09-28MAINTAINERS: Drop records pointing to 01.org/linux-acpiRafael J. Wysocki1-3/+0
The https://01.org/linux-acpi web site has become permanently inaccessible, so drop the records pointing to it from MAINTAINERS. Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-09-28ACPI: Kconfig: Drop link to https://01.org/linux-acpiRafael J. Wysocki1-3/+0
Because the https://01.org/linux-acpi web site has become permanently inaccessible, drop the remaining link to it from the ACPI Kconfig. Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-09-28ACPI: docs: Drop useless DSDT override documentationRafael J. Wysocki2-14/+0
Because https://01.org/linux-acpi web site has become permanently inaccessible, the "Overriding DSDT" document in the kernel tree pointing to it as the main source of information is useless (and the config option name mentioned by it is incorrect), so drop it and drop the pointer to it from the ACPI Kconfig. Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-09-28ACPI: DPTF: Drop stale link from Kconfig helpRafael J. Wysocki1-3/+0
The web site pointed to from the DPTF Kconfig help is not accessible any more, so drop the link to it from there. Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-09-28Merge tag 'devfreq-next-for-6.1' of ↵Rafael J. Wysocki2-6/+9
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Pull devfreq next for v6.1 from Chanwoo Choi: "1. Handle -EPROBE_DEFER when regulator is not probed on mtk-ci-devfreq.c 2. Use dev_err_probe to reduce the error log on rockchip-dfi.c" * tag 'devfreq-next-for-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: PM / devfreq: rockchip-dfi: Fix an error message PM / devfreq: mtk-cci: Handle sram regulator probe deferral
2022-09-28Merge tag 'cpufreq-arm-updates-6.1' of ↵Rafael J. Wysocki7-29/+47
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull cpufreq/arm updates for 6.1-rc1 from Viresh Kumar: "- Add SM6115 to cpufreq-dt blocklist (Adam Skladowski). - Add support for Tegra239 and minor cleanups (Sumit Gupta, ye xingchen, and Yang Yingliang). - Add freq qos for qcom cpufreq driver and minor cleanups (Xuewen Yan, and Viresh Kumar). - Minor cleanups around functions called at module_init() (Xiu Jianfeng). - Use module_init and add module_exit for bmips driver (Zhang Jianhua)." * tag 'cpufreq-arm-updates-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMh cpufreq: Add __init annotation to module init funcs cpufreq: tegra194: change tegra239_cpufreq_soc to static cpufreq: tegra194: Add support for Tegra239 cpufreq: qcom-cpufreq-hw: Fix uninitialized throttled_freq warning cpufreq: tegra194: Remove the unneeded result variable cpufreq: bmips-cpufreq: Use module_init and add module_exit cpufreq: Add SM6115 to cpufreq-dt-platdev blocklist
2022-09-28perf arm-spe: augment the data source type with neoverse_spe listJing Zhang1-1/+1
When synthesizing event with SPE data source, commit 4e6430cbb1a9("perf arm-spe: Use SPE data source for neoverse cores") augment the type with source information by MIDR. However, is_midr_in_range only compares the first entry in neoverse_spe. Change is_midr_in_range to is_midr_in_range_list to traverse the neoverse_spe array so that all neoverse cores synthesize event with data source packet. Fixes: 4e6430cbb1a9f1dc ("perf arm-spe: Use SPE data source for neoverse cores") Reviewed-by: Ali Saidi <[email protected]> Reviewed-by: Leo Yan <[email protected]> Signed-off-by: Jing Zhang <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ali Saidi <[email protected]> Cc: German Gomez <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Garry <[email protected]> Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: Mike Leach <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Shuai Xue <[email protected]> Cc: Timothy Hayes <[email protected]> Cc: Will Deacon <[email protected]> Cc: Zhuo Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2022-09-28perf tests vmlinux-kallsyms: Update is_ignored_symbol function to match the ↵Athira Rajeev1-2/+3
kernel ignored list The testcase “vmlinux-kallsyms.c” fails in powerpc. vmlinux symtab matches kallsyms: FAILED! This test look at the symbols in the vmlinux DSO and check if we find all of them in the kallsyms dso. But from the powerpc logs , observed that the failure happens for: ERR : 0xc0000000000fe9c8: .Lmfspr_table not on kallsyms ERR : 0xc0000000001009c8: .Lmtspr_table not on kallsyms These are labels ( with .L) in the source code and has to be ignored. Reference code with .Lmtspr_table: arch/powerpc/xmon/spr_access.S The testcases invokes is_ignored_symbol() function to ignore hidden symbols in the dso like local symbols. This function is adapted from is_ignored_symbol() kernel function in code: scripts/kallsyms.c . The kernel function got some updates which is not reflected in the testcase function and the new updates also handles ignoring "labels". Below is the changes that went in the kernel function. /* Symbol names that begin with the following are ignored.*/ static const char * const ignored_prefixes[] = { "$", /* local symbols for ARM, MIPS, etc. */ - ".LASANPC", /* s390 kasan local symbols */ + ".L", /* local labels, .LBB,.Ltmpxxx,.L__unnamed_xx,.LASANPC, etc. */ "__crc_", /* modversions */ "__efistub_", /* arm64 EFI stub namespace */ - "__kvm_nvhe_", /* arm64 non-VHE KVM namespace */ + "__kvm_nvhe_$", /* arm64 local symbols in non-VHE KVM namespace */ + "__kvm_nvhe_.L", /* arm64 local symbols in non-VHE KVM namespace */ "__AArch64ADRPThunk_", /* arm64 lld */ "__ARMV5PILongThunk_", /* arm lld */ "__ARMV7PILongThunk_", This change is part of below commits and will handle the symbols with “.L” commit d4c858643263 ("kallsyms: ignore all local labels prefixed by '.L'") commit 6ccf9cb557bd ("KVM: arm64: Symbolize the nVHE HYP addresses") Update the testcase function to include the new changes. Reported-by: Disha Goel <[email protected]> Signed-off-by: Athira Jajeev <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nageswara R Sastry <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2022-09-28ata: libata-sata: Fix device queue depth controlDamien Le Moal3-15/+16
The function __ata_change_queue_depth() uses the helper ata_scsi_find_dev() to get the ata_device structure of a scsi device and set that device maximum queue depth. However, when the ata device is managed by libsas, ata_scsi_find_dev() returns NULL, turning __ata_change_queue_depth() into a nop, which prevents the user from setting the maximum queue depth of ATA devices used with libsas based HBAs. Fix this by renaming __ata_change_queue_depth() to ata_change_queue_depth() and adding a pointer to the ata_device structure of the target device as argument. This pointer is provided by ata_scsi_change_queue_depth() using ata_scsi_find_dev() in the case of a libata managed device and by sas_change_queue_depth() using sas_to_ata_dev() in the case of a libsas managed ata device. Signed-off-by: Damien Le Moal <[email protected]> Tested-by: John Garry <[email protected]>
2022-09-28ata: libata-scsi: Fix initialization of device queue depthDamien Le Moal1-6/+4
For SATA devices supporting NCQ, drivers using libsas first initialize a scsi device queue depth based on the controller and device capabilities, leading to the scsi device queue_depth field being 32 (ATA maximum queue depth) for most setup. However, if libata was loaded using the force=[ID]]noncq argument, the default queue depth should be set to 1 to reflect the fact that queuable commands will never be used. This is consistent with manually setting a device queue depth to 1 through sysfs as that disables NCQ use for the device. Fix ata_scsi_dev_config() to honor the noncq parameter by sertting the device queue depth to 1 for devices that do not have the ATA_DFLAG_NCQ flag set. Signed-off-by: Damien Le Moal <[email protected]> Tested-by: John Garry <[email protected]>
2022-09-28can: c_can: don't cache TX messages for C_CAN coresMarc Kleine-Budde2-8/+20
As Jacob noticed, the optimization introduced in 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO") doesn't properly work on C_CAN, but on D_CAN IP cores. The exact reasons are still unknown. For now disable caching if CAN frames in the TX path for C_CAN cores. Fixes: 387da6bc7a82 ("can: c_can: cache frames to operate as a true FIFO") Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/[email protected] Reported-by: Jacob Kroon <[email protected]> Tested-by: Jacob Kroon <[email protected]> Cc: [email protected] # v5.15 Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-09-28MAINTAINERS: RustMiguel Ojeda1-0/+18
Miguel, Alex and Wedson will be maintaining the Rust support. Boqun, Gary and Björn will be reviewers. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28samples: add first Rust examplesMiguel Ojeda10-0/+108
The beginning of a set of Rust modules that showcase how Rust modules look like and how to use the abstracted kernel features. It also includes an example of a Rust host program with several modules. These samples also double as tests in the CI. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Milan Landaverde <[email protected]> Signed-off-by: Milan Landaverde <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28x86: enable initial Rust supportMiguel Ojeda4-2/+25
Note that only x86_64 is covered and not all features nor mitigations are handled, but it is enough as a starting point and showcases the basics needed to add Rust support for a new architecture. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28docs: add Rust documentationMiguel Ojeda10-4/+675
Most of the documentation for Rust is written within the source code itself, as it is idiomatic for Rust projects. This applies to both the shared infrastructure at `rust/` as well as any other Rust module (e.g. drivers) written across the kernel. However, these documents contain general information that does not fit particularly well in the source code, like the Quick Start guide. It also contains a few other small changes elsewhere in the documentation folder. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Michael Ellerman <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Wu XiangCheng <[email protected]> Signed-off-by: Wu XiangCheng <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Yuki Okushi <[email protected]> Signed-off-by: Yuki Okushi <[email protected]> Co-developed-by: Wei Liu <[email protected]> Signed-off-by: Wei Liu <[email protected]> Co-developed-by: Daniel Xu <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Co-developed-by: Julian Merkle <[email protected]> Signed-off-by: Julian Merkle <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28Kbuild: add Rust supportMiguel Ojeda19-26/+869
Having most of the new files in place, we now enable Rust support in the build system, including `Kconfig` entries related to Rust, the Rust configuration printer and a few other bits. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Michael Ellerman <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Douglas Su <[email protected]> Signed-off-by: Douglas Su <[email protected]> Co-developed-by: Dariusz Sosnowski <[email protected]> Signed-off-by: Dariusz Sosnowski <[email protected]> Co-developed-by: Antonio Terceiro <[email protected]> Signed-off-by: Antonio Terceiro <[email protected]> Co-developed-by: Daniel Xu <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Co-developed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: add `.rustfmt.toml`Miguel Ojeda2-0/+13
This is the configuration file for the `rustfmt` tool. `rustfmt` is a tool for formatting Rust code according to style guidelines. It is very commonly used across Rust projects. The default configuration options are used. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `is_rust_module.sh`Daniel Xu1-0/+16
This script is used to detect whether a kernel module is written in Rust. It will later be used to disable BTF generation on Rust modules as BTF does not yet support Rust. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `rust_is_available.sh`Miguel Ojeda3-0/+168
This script tests whether the Rust toolchain requirements are in place to enable Rust support. It uses `min-tool-version.sh` to fetch the version numbers. The build system will call it to set `CONFIG_RUST_IS_AVAILABLE` in a later patch. It also has an option (`-v`) to explain what is missing, which is useful to set up the development environment. This is used via the `make rustavailable` target added in a later patch. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Miguel Cano <[email protected]> Signed-off-by: Miguel Cano <[email protected]> Co-developed-by: Tiago Lam <[email protected]> Signed-off-by: Tiago Lam <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `generate_rust_target.rs`Miguel Ojeda2-0/+172
This script takes care of generating the custom target specification file for `rustc`, based on the kernel configuration. It also serves as an example of a Rust host program. A dummy architecture is kept in this patch so that a later patch adds x86 support on top with as few changes as possible. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: add `generate_rust_analyzer.py`Miguel Ojeda2-0/+138
The `generate_rust_analyzer.py` script generates the configuration file (`rust-project.json`) for rust-analyzer. rust-analyzer is a modular compiler frontend for the Rust language. It provides an LSP server which can be used in editors such as VS Code, Emacs or Vim. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: decode_stacktrace: demangle Rust symbolsMiguel Ojeda1-0/+14
Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`) provide Rust v0 mangling support. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: checkpatch: enable language-independent checks for RustMiguel Ojeda1-2/+2
Include Rust in the "source code files" category, so that the language-independent tests are checked for Rust too, and teach `checkpatch` about the comment style for Rust files. This enables the malformed SPDX check, the misplaced SPDX license tag check, the long line checks, the lines without a newline check and the embedded filename check. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28scripts: checkpatch: diagnose uses of `%pA` in the C side as errorsMiguel Ojeda1-2/+6
The `%pA` format specifier is only intended to be used from Rust. `checkpatch.pl` already gives a warning for invalid specificers: WARNING: Invalid vsprintf pointer extension '%pA' This makes it an error and introduces an explanatory message: ERROR: Invalid vsprintf pointer extension '%pA' - '%pA' is only intended to be used from Rust code Suggested-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Joe Perches <[email protected]> Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28vsprintf: add new `%pA` format specifierGary Guo2-0/+23
This patch adds a format specifier `%pA` to `vsprintf` which formats a pointer as `core::fmt::Arguments`. Doing so allows us to directly format to the internal buffer of `printf`, so we do not have to use a temporary buffer on the stack to pre-assemble the message on the Rust side. This specifier is intended only to be used from Rust and not for C, so `checkpatch.pl` is intentionally unchanged to catch any misuse. Reviewed-by: Kees Cook <[email protected]> Acked-by: Petr Mladek <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: export generated symbolsMiguel Ojeda1-0/+21
All symbols are reexported reusing the `EXPORT_SYMBOL_GPL` macro from C. The lists of symbols are generated on the fly. There are three main sets of symbols to distinguish: - The ones from the `core` and `alloc` crates (from the Rust standard library). The code is licensed as Apache/MIT. - The ones from our abstractions in the `kernel` crate. - The helpers (already exported since they are not generated). We export everything as GPL. This ensures we do not mistakenly expose GPL kernel symbols/features as non-GPL, even indirectly. Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: add `kernel` crateWedson Almeida Filho6-0/+491
The `kernel` crate currently includes all the abstractions that wrap kernel features written in C. These abstractions call the C side of the kernel via the generated bindings with the `bindgen` tool. Modules developed in Rust should never call the bindings themselves. In the future, as the abstractions grow in number, we may need to split this crate into several, possibly following a similar subdivision in subsystems as the kernel itself and/or moving the code to the actual subsystems. Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Geoffrey Thomas <[email protected]> Signed-off-by: Geoffrey Thomas <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Fox Chen <[email protected]> Signed-off-by: Fox Chen <[email protected]> Co-developed-by: Viktor Garske <[email protected]> Signed-off-by: Viktor Garske <[email protected]> Co-developed-by: Dariusz Sosnowski <[email protected]> Signed-off-by: Dariusz Sosnowski <[email protected]> Co-developed-by: Léo Lanteri Thauvin <[email protected]> Signed-off-by: Léo Lanteri Thauvin <[email protected]> Co-developed-by: Niklas Mohrin <[email protected]> Signed-off-by: Niklas Mohrin <[email protected]> Co-developed-by: Milan Landaverde <[email protected]> Signed-off-by: Milan Landaverde <[email protected]> Co-developed-by: Morgan Bartlett <[email protected]> Signed-off-by: Morgan Bartlett <[email protected]> Co-developed-by: Maciej Falkowski <[email protected]> Signed-off-by: Maciej Falkowski <[email protected]> Co-developed-by: Nándor István Krácser <[email protected]> Signed-off-by: Nándor István Krácser <[email protected]> Co-developed-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Co-developed-by: John Baublitz <[email protected]> Signed-off-by: John Baublitz <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: add `bindings` crateMiguel Ojeda2-0/+66
This crate contains the bindings to the C side of the kernel. Calling C (in general, FFI) is assumed to be unsafe in Rust and, in many cases, this is accurate. For instance, virtually all C functions that take a pointer are unsafe since, typically, it will be dereferenced at some point (and in most cases there is no way for the callee to check its validity beforehand). Since one of the goals of using Rust in the kernel is precisely to avoid unsafe code in "leaf" kernel modules (e.g. drivers), these bindings should not be used directly by them. Instead, these bindings need to be wrapped into safe abstractions. These abstractions provide a safe API that kernel modules can use. In this way, unsafe code in kernel modules is minimized. Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Maciej Falkowski <[email protected]> Signed-off-by: Maciej Falkowski <[email protected]> Co-developed-by: Jiapeng Chong <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: add `macros` crateMiguel Ojeda3-0/+405
This crate contains all the procedural macros ("proc macros") shared by all the kernel. Procedural macros allow to create syntax extensions. They run at compile-time and can consume as well as produce Rust syntax. For instance, the `module!` macro that is used by Rust modules is implemented here. It allows to easily declare the equivalent information to the `MODULE_*` macros in C modules, e.g.: module! { type: RustMinimal, name: b"rust_minimal", author: b"Rust for Linux Contributors", description: b"Rust minimal sample", license: b"GPL", } Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sumera Priyadarsini <[email protected]> Signed-off-by: Sumera Priyadarsini <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Matthew Bakhtiari <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: add `compiler_builtins` crateMiguel Ojeda1-0/+63
Rust provides `compiler_builtins` as a port of LLVM's `compiler-rt`. Since we do not need the vast majority of them, we avoid the dependency by providing our own crate. Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: adapt `alloc` crate to the kernelMiguel Ojeda14-1/+100
This customizes the subset of the Rust standard library `alloc` that was just imported as-is, mainly by: - Adding SPDX license identifiers. - Skipping modules (e.g. `rc` and `sync`) via new `cfg`s. - Adding fallible (`try_*`) versions of existing infallible methods (i.e. returning a `Result` instead of panicking). Since the standard library requires stable/unstable attributes, these additions are annotated with: #[stable(feature = "kernel", since = "1.0.0")] Using "kernel" as the feature allows to have the additions clearly marked. The "1.0.0" version is just a placeholder. (At the moment, only one is needed, but in the future more fallible methods will be added). Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: import upstream `alloc` crateMiguel Ojeda13-0/+9037
This is a subset of the Rust standard library `alloc` crate, version 1.62.0, licensed under "Apache-2.0 OR MIT", from: https://github.com/rust-lang/rust/tree/1.62.0/library/alloc/src The files are copied as-is, with no modifications whatsoever (not even adding the SPDX identifiers). For copyright details, please see: https://github.com/rust-lang/rust/blob/1.62.0/COPYRIGHT The next patch modifies these files as needed for use within the kernel. This patch split allows reviewers to double-check the import and to clearly see the differences introduced. Vendoring `alloc`, at least for the moment, allows us to have fallible allocations support (i.e. the `try_*` versions of methods which return a `Result` instead of panicking) early on. It also gives a bit more freedom to experiment with new interfaces and to iterate quickly. Eventually, the goal is to have everything the kernel needs in upstream `alloc` and drop it from the kernel tree. For a summary of work on `alloc` happening upstream, please see: https://github.com/Rust-for-Linux/linux/issues/408 The following script may be used to verify the contents: for path in $(cd rust/alloc/ && find . -type f -name '*.rs'); do curl --silent --show-error --location \ https://github.com/rust-lang/rust/raw/1.62.0/library/alloc/src/$path \ | diff --unified rust/alloc/$path - && echo $path: OK done Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.