If the same size kmalloc cache already exists, it should not be created
again. So there is the check for NULL kmalloc_caches before calling the
kmalloc creation function. However, new_kmalloc_cache() itself checks NULL
kmalloc_cahces before cache creation. Therefore, the NULL check is not
necessary in this function.
Signed-off-by: Hyunmin Lee <hyunminlr@gmail.com>
Co-developed-by: Jeungwoo Yoo <casionwoo@gmail.com>
Signed-off-by: Jeungwoo Yoo <casionwoo@gmail.com>
Co-developed-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
For SLAB the kmalloc caches needed to be created in ascending sizes in
order. However, the constraint is not necessary anymore because SLAB has
been removed and SLUB doesn't need to comply with the constraint. Thus,
kmalloc 96 and 192 caches can be created after the other size kmalloc
caches are created instead of checking every time to find their order to
be created. Also, this change could prevent engineers from being confused
by the removed constraint.
Signed-off-by: Hyunmin Lee <hyunminlr@gmail.com>
Co-developed-by: Jeungwoo Yoo <casionwoo@gmail.com>
Signed-off-by: Jeungwoo Yoo <casionwoo@gmail.com>
Co-developed-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Signed-off-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
I sometimes see ("unknown type") in the result and it was because it
didn't check the type of stack variables properly during the instruction
tracking. The stack can carry constant values (without type info) and
if the target instruction is accessing the stack location, it resulted
in the "unknown type".
Maybe we could pick one of integer types for the constant, but it
doesn't really mean anything useful. Let's just drop the stack slot if
it doesn't have a valid type info.
Here's an example how it got the unknown type.
Note that 0xffffff48 = -0xb8.
-----------------------------------------------------------
find data type for 0xffffff48(reg6) at ...
CU for ...
frame base: cfa=0 fbreg=6
scope: [2/2] (die:11cb97f)
bb: [37 - 3a]
var [37] reg15 type='int' size=0x4 (die:0x1180633)
bb: [40 - 4b]
mov [40] imm=0x1 -> reg13
var [45] reg8 type='sigset_t*' size=0x8 (die:0x11a39ee)
mov [45] imm=0x1 -> reg2 <--- here reg2 has a constant
bb: [215 - 237]
mov [218] reg2 -> -0xb8(stack) constant <--- and save it to the stack
mov [225] reg13 -> -0xc4(stack) constant
call [22f] find_task_by_vgpid
call [22f] return -> reg0 type='struct task_struct*' size=0x8 (die:0x11881e8)
bb: [5c8 - 5cf]
bb: [2fb - 302]
mov [2fb] -0xc4(stack) -> reg13 constant
bb: [13b - 14d]
mov [143] 0xd50(reg3) -> reg5 type='struct task_struct*' size=0x8 (die:0xa31f3c)
bb: [153 - 153]
chk [153] reg6 offset=0xffffff48 ok=0 kind=0 fbreg <--- access here
found by insn track: 0xffffff48(reg6) type-offset=0
type='G<EF>^K<F6><AF>U' size=0 (die:0xffffffffffffffff)
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240502060011.1838090-7-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The instruction tracking should be the same for the both registers.
Just do it once and compare the result with multi regs as with the
previous patches.
Then we don't need to call find_data_type_block() separately for each
reg.
Let's remove the 'reg' argument from the relevant functions.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240502060011.1838090-6-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The following instruction pattern is used to access a global variable.
mov $0x231c0, %rax
movsql %edi, %rcx
mov -0x7dc94ae0(,%rcx,8), %rcx
cmpl $0x0, 0xa60(%rcx,%rax,1) <<<--- here
The first instruction set the address of the per-cpu variable (here, it
is 'runqueues' of type 'struct rq'). The second instruction seems like
a cpu number of the per-cpu base. The third instruction get the base
offset of per-cpu area for that cpu. The last instruction compares the
value of the per-cpu variable at the offset of 0xa60.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240502060011.1838090-5-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Like per-cpu base offset array, sometimes it accesses the global
variable directly using the offset. Allow this type of instructions as
long as it finds a global variable for the address.
movslq %edi, %rcx
mov -0x7dc94ae0(,%rcx,8), %rcx <<<--- here
As %rcx has a valid type (i.e. array index) from the first instruction,
it will be checked by the first case in check_matching_type(). But as
it's not a pointer type, the match will fail. But in this case, it
should check if it accesses the kernel global array variable.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240502060011.1838090-4-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
There's currently no documentation for the swiotlb. Add documentation
describing usage scenarios, the key APIs, and implementation details.
Group the new documentation with other DMA-related documentation.
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Reviewed-by: Petr Tesarik <petr@tesarici.cz>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Currently it looks up global variables from the current CU using address
and name. But it sometimes fails to find a variable as the variable can
come from a different CU - but it's still strange it failed to find a
declaration for some reason.
Anyway, it can collect all global variables from all CU once and then
lookup them later on. This slightly improves the success rate of my
test data set.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240502060011.1838090-3-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This function is to search all global variables in the CU. We want to
have the list of global variables at once and match them later.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240502060011.1838090-2-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Pull NVMe fixes from Keith.
* git://git.infradead.org/nvme:
nvme-tcp: strict pdu pacing to avoid send stalls on TLS
nvmet: fix nvme status code when namespace is disabled
nvmet-tcp: fix possible memory leak when tearing down a controller
nvme: cancel pending I/O if nvme controller is in terminal state
nvmet-auth: replace pr_debug() with pr_err() to report an error.
nvmet-auth: return the error code to the nvmet_auth_host_hash() callers
nvme: find numa distance only if controller has valid numa id
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
Generic Cleanups/Fixes:
- fixup of generated dtb imx219 overlay file names
- Remove UART baud rate selection in device tree.
- Use exact ranges for FSS.
SoC specific Fixes/Features:
AM625:
- Add USB PHY2 region and usb phy control registers
AM62A
- Add USB PHY2 region and usb phy control registers, Disable USB LPM.
- Add wave-512 video encoder/decoder support
- Enable UHS mode for SD
AM62P:
- Disable ethernet by default
- Add USB support
AM654
- Serdes fixups
- SDHCI fixups.
AM67/j722s:
- Disable ethernet by default
- Add USB support
AM68/J721s2:
- Add main ESM range
- Add support for SDR104
AM69/J784S4:
- Add main ESM range
- Enable support for UHS mode
Board specific fixes/Features:
AM625:
- BeaglePlay: Fixes for wlan mmc-pwrseq and ethernet phy reset
- phyboard-lyra: Add Audio codec, USB-C, increase CAN bit rate and enable
ability to apply overlays
- verdin: GPIO pinctrl fixups, Switch SD carddetect to GPIO, fixup memory
to 2GB, and audio clock, PCIe reset GPIO hog, sleep-moci
- lp-sk: Drop power button
- sk: minor white space cleanup.
AM64
- phyboard-electra: Increase CAN bit rate, enable overlay to enable GPIO fan
AM65:
- iot2050: Add icssg-prueth for PG1
AM67/j722s:
- evm: Enable UHS support for SD card and eMMC support.
AM69/J784s4:
- evm/sk: Fix uart pins and pinctrl macro usage.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAmYyNEYACgkQ3bWEnRc2
JJ12Yg/+MhvnAD+DVLDSVVNlp6OHqs9sGFV76+M6CbZxehvZGwUtNl6qI/xBoN4C
+eAHlgaoMe6WT8S8KMy5p/Zxlsem9+S7Dd72/A3P0rT7PKx6HgUyh60D3CmWHjuF
a/9bd4vBRKr2oEiMhgpr7MIQ2J5OOLCfjUpn99NdNG/nXenpOHHsKpkUAUacbAcA
BjLQzNSiL/Drm7A1su122MmemrBt72KSpL6753R+D9mU5HwoPcvBMd0o9UMAnGXy
LpqXXXLVJX4QjN7/8rQ0sVzHwlA/N+CrBsmIu/gcqiHZ7rPltVfK/HWy/UETfGZf
j/wIBQOgXIxOhyzAuDj0h+umuTWS86zjnD3FX7F+x66h/vERxsp+xo6hO7dsijax
FeKB4YMRJrz/Yqwh/EyEGAZHUGFB0zGSFu0QBlvBvH+h4cx9PDnFXjIyrEsZ8GCE
OnC0QUT2Mb1OoclZWepk+2DqFpjSEGSuLf1Tu2Fzj4onq+ECfkx95cS2EemY3sb6
Iyc8ddsVClLsIES+NidcTUYwfYMDlTjDuJUDAwPyl0fSIV0tl5jS7qxHU8ujYloC
JAdevNL1CUgrjo27R/LxAopzGX7sQR3bneAEC4Lfzp9ER4en9f9RyFAaOIvFeU66
5AiSbRnBj9RKMnbBFhKWnUA2lgC7Xs/DPkS7YKK/ttjD/Bfpa9U=
=PUtH
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYzkGoACgkQYKtH/8kJ
UieFuA/8DTiWC4mJU/tsMtrXYu8xWTKgn55yyE87fNkOq3UrsZuolb05eM4thsRl
nfrUXDj8p7H9Y/PKF20HidGqjxRMKmEmltbadYM+uFtQ1LzB4rFglzZ3ZvjQ47la
FTLGCkIgygPT51zWXiPtJHwEs3/lN5C+TcrqtEUcCDYWUpBupB5GwrTrGvIf/f/J
mpSwTDJplqdRED/ig6K5lo4GmqTdKNRcv+PQ1VyfCyxCmv/JcR4cFN8gOs4tJeaV
xqQo5i5zbiaViNMHRr0L0mqnwHix99F0GdyVIo0HH+M5gABGuPvPzW0tQ2isn5K4
BGc+9PEaqO39FUsxTsoCtZi5P2DdxififDXzvrVLb2G6H7Q5JihQ9ZMrSis7nQxB
ih0LgwpxDL1lTxPIQzYttLpdBPqC2NLd9GJDD7Yi1eAMfiZKmKcz3PjjnnfQcfM4
i91UoUzDpzVw49S6hSg/mgRy0zH+92fj0yvXT45xQXwkmutPqlRS4cwy815lVBsA
LednschDYoMHoPXPwPP/16sgQFr4XtVH3Uf/1Hrfc/b5WyW5aqixXossFnMAYhr3
ZObd4ImgeiVB6y6neUdq5+pgqKGQ6Ysy9TPFfBFVZ5dwGLO/Jz66xjMm5EnFHiXT
EACjYpUD2pbpoizzyeCMixn/R6CKJTUumqSaCfxad8Zv8oe2VBI=
=OTpo
-----END PGP SIGNATURE-----
Merge tag 'ti-k3-dt-for-v6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/dt
TI K3 device tree updates for v6.10
Generic Cleanups/Fixes:
- fixup of generated dtb imx219 overlay file names
- Remove UART baud rate selection in device tree.
- Use exact ranges for FSS.
SoC specific Fixes/Features:
AM625:
- Add USB PHY2 region and usb phy control registers
AM62A
- Add USB PHY2 region and usb phy control registers, Disable USB LPM.
- Add wave-512 video encoder/decoder support
- Enable UHS mode for SD
AM62P:
- Disable ethernet by default
- Add USB support
AM654
- Serdes fixups
- SDHCI fixups.
AM67/j722s:
- Disable ethernet by default
- Add USB support
AM68/J721s2:
- Add main ESM range
- Add support for SDR104
AM69/J784S4:
- Add main ESM range
- Enable support for UHS mode
Board specific fixes/Features:
AM625:
- BeaglePlay: Fixes for wlan mmc-pwrseq and ethernet phy reset
- phyboard-lyra: Add Audio codec, USB-C, increase CAN bit rate and enable
ability to apply overlays
- verdin: GPIO pinctrl fixups, Switch SD carddetect to GPIO, fixup memory
to 2GB, and audio clock, PCIe reset GPIO hog, sleep-moci
- lp-sk: Drop power button
- sk: minor white space cleanup.
AM64
- phyboard-electra: Increase CAN bit rate, enable overlay to enable GPIO fan
AM65:
- iot2050: Add icssg-prueth for PG1
AM67/j722s:
- evm: Enable UHS support for SD card and eMMC support.
AM69/J784s4:
- evm/sk: Fix uart pins and pinctrl macro usage.
* tag 'ti-k3-dt-for-v6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: (48 commits)
arm64: dts: ti: Fix csi2-dual-imx219 dtb names
arm64: dts: ti: k3-am625-beagleplay: Fix Ethernet PHY RESET GPIOs
arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add USB-C
arm64: dts: ti: k3-j784s4: Add main esm address range
arm64: dts: ti: k3-j721s2: Add main esm address range
arm64: dts: ti: k3-am62-verdin-dahlia: support sleep-moci
arm64: dts: ti: k3-am62-verdin: replace sleep-moci hog with regulator
arm64: dts: ti: k3-j722s-evm: Enable UHS support for MMCSD
arm64: dts: ti: k3-j784s4-main: Enable support for UHS mode
arm64: dts: ti: k3-j721s2-main: Enable support for SDR104 speed mode
arm64: dts: ti: k3-am62a: Enable UHS mode support for SD cards
arm64: dts: ti: k3-am65-main: Remove unused properties in sdhci nodes
arm64: dts: ti: k3-am65-main: Fix sdhci node properties
arm64: dts: ti: Enable overlays for the am625-phyboard-lyra
arm64: dts: ti: am64-phyboard-electra: Add overlay to enable a GPIO fan
arm64: dts: ti: k3-am62a-main: Add Wave5 Video Encoder/Decoder Node
arm64: dts: ti: k3-am69-sk: Fix UART pin type and macro type
arm64: dts: ti: k3-j784s4-evm: Fix UART pin type and macro type
arm64: dts: ti: k3-am62a: Disable USB LPM
arm64: dts: ti: k3-am62p: add the USB sub-system
...
Link: https://lore.kernel.org/r/20240501124319.ake5j2oc5pbnn5nb@contour
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Using restricted DMA pools (CONFIG_DMA_RESTRICTED_POOL=y) in conjunction
with dynamic SWIOTLB (CONFIG_SWIOTLB_DYNAMIC=y) leads to the following
crash when initialising the restricted pools at boot-time:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
| Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
| pc : rmem_swiotlb_device_init+0xfc/0x1ec
| lr : rmem_swiotlb_device_init+0xf0/0x1ec
| Call trace:
| rmem_swiotlb_device_init+0xfc/0x1ec
| of_reserved_mem_device_init_by_idx+0x18c/0x238
| of_dma_configure_id+0x31c/0x33c
| platform_dma_configure+0x34/0x80
faddr2line reveals that the crash is in the list validation code:
include/linux/list.h:83
include/linux/rculist.h:79
include/linux/rculist.h:106
kernel/dma/swiotlb.c:306
kernel/dma/swiotlb.c:1695
because add_mem_pool() is trying to list_add_rcu() to a NULL
'mem->pools'.
Fix the crash by initialising the 'mem->pools' list_head in
rmem_swiotlb_device_init() before calling add_mem_pool().
Reported-by: Nikita Ioffe <ioffe@google.com>
Tested-by: Nikita Ioffe <ioffe@google.com>
Fixes: 1aaa736815 ("swiotlb: allocate a new memory pool when existing pools are full")
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Sophgo:
Added sdhci support for cv18xx/duo.
Added clock support for cv18xx.
Added clock for uart/sdhci.
Added spi support for cv18xx.
Added i2c support for cv18xx.
Added reserved memory node for cv1800b/duo.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEyXBewyFOIoMq4pDN7RKLaY1m8IIFAmYxmBsACgkQ7RKLaY1m
8IKJbwwA2MF4SGcM7ZBdrYrom0leEIv7/UrGyGLOK3GUY57hp2upsrpE9j66x8sV
5GGEdlUoAzlcHFe23FzA44JVhRm3NcgUo5CAZRrjrk9M17RKdCWziiJ5h4ZbP1Ue
a787yAAg58OmMLSpaJBoO0IwjFiUS8nUC9YUSqvWmVhtsvHO/n7aZKvYOdgZ3lnA
LtlQGpsuz3q8q5Gk/tmS8astIkxzCMVlLfipkETqF5H5dtlw/tl7sIqubxUnnWea
/qj6QiSn+li2jdk4VQOw57Fc6IEkFZtYJGRwnCKmZE7thHA2z8HZ+gIXDq/X0CU8
PTnwQ7nO0oRJn0bQLACy+vO/9iznRNo+y3HAoVQtDjB/Xef6JbIrI/1pnft8UUQO
ZBGvuvXbq7K1uTpVHIrup9AnxwcNTzNFJ6wK/jap/R+CAIZKA2GSpNgd0qDOxzGh
OLjTVnU1jc7VhB2gaNEaox9zs0s6MOxMwz9iRLAA3Dsyitbx1AEjq63vYXE3KR72
dnvT4Y8j
=d7SS
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYzjYsACgkQYKtH/8kJ
Uie5nA//Sib+nyw4b/v6Mk1c+OWl+N+V9iaennHJ3hcRxC/AQDF6RbwPi3DVItkz
KvXFGa7buTl1HzmiBVqjv1k2lZTFdZo6ZndwGwr/V1qd9pP+USoC/5ua4XatYdP+
UT9RtXnqTMRzYFXVYnYKzs3phhteGfqg8yAmqOqNN6mtkgzy0Wi3NGoPWVD83G2V
PZY0LcC3H9qU0lM3KXicHGWAPWgrvOo9iVdeXNlKt0QKvaMRw0t3tkKQSb2HEBvv
M2T6uknTir8lFdXhC/6r26zNiC0Iuk9/xtVuTvyI1NWyscLy+F0orR7QT49axEBO
C425MQ34OkyPfplGvROWq9PN4jpnbyMIlFnP0/VJyjPfO6oZ7MYNJ6hbYjrNDf/7
n/8RugMxtUZVwBHTb5pKvCgB51/zf80N5bNVW1yRQ3HbUFz91VaPTh5m+WKFz7BQ
6rETCpdS4ai0tkREbfbNPhBmid3SuqF9wTWEOcfh2BqRCjc+c4In/XsVFkDLGxL/
peZku7C11hTDc3L/WazU2hwwjye28aoqykhr6B7CQ7MiThkUnknXrXkdfqwiTDJj
Dv4e2wl0LU3zN66NFTlpUQ4fYXTD6IH8d3ps9qLaY3KbALbMR8x+oTnwBfxYUJuL
oP/NT6kEFCRP1pdU9E4OXhvaqvfGQI4/gETnefXmsG68u0dtS24=
=5D+b
-----END PGP SIGNATURE-----
Merge tag 'riscv-sophgo-dt-for-v6.10' of https://github.com/sophgo/linux into soc/dt
RISC-V Devicetrees for v6.10
Sophgo:
Added sdhci support for cv18xx/duo.
Added clock support for cv18xx.
Added clock for uart/sdhci.
Added spi support for cv18xx.
Added i2c support for cv18xx.
Added reserved memory node for cv1800b/duo.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* tag 'riscv-sophgo-dt-for-v6.10' of https://github.com/sophgo/linux:
riscv: dts: sophgo: add reserved memory node for CV1800B
riscv: dts: sophgo: use real clock for sdhci
riscv: dts: sophgo: cv18xx: Add i2c devices
riscv: dts: sophgo: cv18xx: Add spi devices
riscv: dts: sophgo: add uart clock for Sophgo CV1800 series SoC
riscv: dts: sophgo: add clock generator for Sophgo CV1800 series SoC
riscv: dts: sophgo: add sdcard support for milkv duo
Link: https://lore.kernel.org/r/MA0P287MB2822CA2DE757787D6EA3B1F8FE192@MA0P287MB2822.INDP287.PROD.OUTLOOK.COM
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
'/memory' nodes always have a 'reg' property, and therefore should have
a unit-address with just plain hex (i.e. no commas). Fix all the arm64
'/memory' nodes.
It's possible that some bootloader depends on /memory (arm32 ATAG to DT
code does for example). If so, the memory node should be commented with
that requirement.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Chanho Min <chanho.min@lge.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240430191856.874600-2-robh@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In deactivate_slab(), slab->freelist can be changed concurrently. Mark
data race on slab->freelist as benign using READ_ONCE.
This patch is aimed at reducing the number of benign races reported by
KCSAN in order to focus future debugging effort on harmful races.
Signed-off-by: linke li <lilinke99@qq.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
AMD CPUs have the scope of RAPL energy-pkg event as package, whereas
Intel Cascade Lake CPUs have the scope as die.
To account for the difference in the energy-pkg event scope between AMD
and Intel CPUs, give more generic and semantically correct names to the
maxdie and dieid variables.
No functional change.
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20240502095115.177713-2-Dhananjay.Ugwekar@amd.com
These are generated files. Prefix them with $(obj)/ instead of $(src)/.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
This flag is set to symbols that are not intended to be written
to the .config file.
Since commit b75b0a819a ("kconfig: change defconfig_list option to
environment variable"), SYMBOL_NO_WRITE is only set to choices.
Therefore, (sym->flags & SYMBOL_NO_WRITE) is equivalent to
sym_is_choice(sym). This flag is no longer necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
To support APX functionality, the EVEX prefix is used to:
- promote legacy instructions
- promote VEX instructions
- add new instructions
Promoted VEX instructions require no extra annotation because the opcodes
do not change and the permissive nature of the instruction decoder already
allows them to have an EVEX prefix.
Promoted legacy instructions and new instructions are placed in map 4 which
has not been used before.
Create a new table for map 4 and add APX instructions.
Annotate SCALABLE instructions with "(es)" - refer to patch "x86/insn: Add
support for APX EVEX to the instruction decoder logic". SCALABLE
instructions must be represented in both no-prefix (NP) and 66 prefix
forms.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-9-adrian.hunter@intel.com
Intel Advanced Performance Extensions (APX) extends the EVEX prefix to
support:
- extended general purpose registers (EGPRs) i.e. r16 to r31
- Push-Pop Acceleration (PPX) hints
- new data destination (NDD) register
- suppress status flags writes (NF) of common instructions
- new instructions
Refer to the Intel Advanced Performance Extensions (Intel APX) Architecture
Specification for details.
The extended EVEX prefix does not need amended instruction decoder logic,
except in one area. Some instructions are defined as SCALABLE which means
the EVEX.W bit and EVEX.pp bits are used to determine operand size.
Specifically, if an instruction is SCALABLE and EVEX.W is zero, then
EVEX.pp value 0 (representing no prefix NP) means default operand size,
whereas EVEX.pp value 1 (representing 66 prefix) means operand size
override i.e. 16 bits
Add an attribute (INAT_EVEX_SCALABLE) to identify such instructions, and
amend the logic appropriately.
Amend the awk script that generates the attribute tables from the opcode
map, to recognise "(es)" as attribute INAT_EVEX_SCALABLE.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-8-adrian.hunter@intel.com
Support for REX2 has been added to the instruction decoder logic and the
awk script that generates the attribute tables from the opcode map.
Add REX2 prefix byte (0xD5) to the opcode map.
Add annotation (!REX2) for map 0/1 opcodes that are reserved under REX2.
Add JMPABS to the opcode map and add annotation (REX2) to identify that it
has a mandatory REX2 prefix. A separate opcode attribute table is not
needed at this time because JMPABS has the same attribute encoding as the
MOV instruction that it shares an opcode with i.e. INAT_MOFFSET.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-7-adrian.hunter@intel.com
Intel Advanced Performance Extensions (APX) uses a new 2-byte prefix named
REX2 to select extended general purpose registers (EGPRs) i.e. r16 to r31.
The REX2 prefix is effectively an extended version of the REX prefix.
REX2 and EVEX are also used with PUSH/POP instructions to provide a
Push-Pop Acceleration (PPX) hint. With PPX hints, a CPU will attempt to
fast-forward register data between matching PUSH and POP instructions.
REX2 is valid only with opcodes in maps 0 and 1. Similar extension for
other maps is provided by the EVEX prefix, covered in a separate patch.
Some opcodes in maps 0 and 1 are reserved under REX2. One of these is used
for a new 64-bit absolute direct jump instruction JMPABS.
Refer to the Intel Advanced Performance Extensions (Intel APX) Architecture
Specification for details.
Define a code value for the REX2 prefix (INAT_PFX_REX2), and add attribute
flags for opcodes reserved under REX2 (INAT_NO_REX2) and to identify
opcodes (only JMPABS) that require a mandatory REX2 prefix
(INAT_REX2_VARIANT).
Amend logic to read the REX2 prefix and get the opcode attribute for the
map number (0 or 1) encoded in the REX2 prefix.
Amend the awk script that generates the attribute tables from the opcode
map, to recognise "REX2" as attribute INAT_PFX_REX2, and "(!REX2)"
as attribute INAT_NO_REX2, and "(REX2)" as attribute INAT_REX2_VARIANT.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-6-adrian.hunter@intel.com
The x86 instruction decoder is used not only for decoding kernel
instructions. It is also used by perf uprobes (user space probes) and by
perf tools Intel Processor Trace decoding. Consequently, it needs to
support instructions executed by user space also.
Add instructions documented in Intel Architecture Instruction Set
Extensions and Future Features Programming Reference March 2024
319433-052, that have not been added yet:
AADD
AAND
AOR
AXOR
CMPccXADD
PBNDKB
RDMSRLIST
URDMSR
UWRMSR
VBCSTNEBF162PS
VBCSTNESH2PS
VCVTNEEBF162PS
VCVTNEEPH2PS
VCVTNEOBF162PS
VCVTNEOPH2PS
VCVTNEPS2BF16
VPDPB[SU,UU,SS]D[,S]
VPDPW[SU,US,UU]D[,S]
VPMADD52HUQ
VPMADD52LUQ
VSHA512MSG1
VSHA512MSG2
VSHA512RNDS2
VSM3MSG1
VSM3MSG2
VSM3RNDS2
VSM4KEY4
VSM4RNDS4
WRMSRLIST
TCMMIMFP16PS
TCMMRLFP16PS
TDPFP16PS
PREFETCHIT1
PREFETCHIT0
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-5-adrian.hunter@intel.com
The x86 instruction decoder is used not only for decoding kernel
instructions. It is also used by perf uprobes (user space probes) and by
perf tools Intel Processor Trace decoding. Consequently, it needs to
support instructions executed by user space also.
Intel Architecture Instruction Set Extensions and Future Features manual
number 319433-044 of May 2021, documented VEX versions of instructions
VPDPBUSD, VPDPBUSDS, VPDPWSSD and VPDPWSSDS, but the opcode map has them
listed as EVEX only.
Remove EVEX-only (ev) annotation from instructions VPDPBUSD, VPDPBUSDS,
VPDPWSSD and VPDPWSSDS, which allows them to be decoded with either a VEX
or EVEX prefix.
Fixes: 0153d98f2d ("x86/insn: Add misc instructions to x86 instruction decoder")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-4-adrian.hunter@intel.com
The x86 instruction decoder is used not only for decoding kernel
instructions. It is also used by perf uprobes (user space probes) and by
perf tools Intel Processor Trace decoding. Consequently, it needs to
support instructions executed by user space also.
Opcode 0x68 PUSH instruction is currently defined as 64-bit operand size
only i.e. (d64). That was based on Intel SDM Opcode Map. However that is
contradicted by the Instruction Set Reference section for PUSH in the
same manual.
Remove 64-bit operand size only annotation from opcode 0x68 PUSH
instruction.
Example:
$ cat pushw.s
.global _start
.text
_start:
pushw $0x1234
mov $0x1,%eax # system call number (sys_exit)
int $0x80
$ as -o pushw.o pushw.s
$ ld -s -o pushw pushw.o
$ objdump -d pushw | tail -4
0000000000401000 <.text>:
401000: 66 68 34 12 pushw $0x1234
401004: b8 01 00 00 00 mov $0x1,%eax
401009: cd 80 int $0x80
$ perf record -e intel_pt//u ./pushw
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.014 MB perf.data ]
Before:
$ perf script --insn-trace=disasm
Warning:
1 instruction trace errors
pushw 10349 [000] 10586.869237014: 401000 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) pushw $0x1234
pushw 10349 [000] 10586.869237014: 401006 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) addb %al, (%rax)
pushw 10349 [000] 10586.869237014: 401008 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) addb %cl, %ch
pushw 10349 [000] 10586.869237014: 40100a [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) addb $0x2e, (%rax)
instruction trace error type 1 time 10586.869237224 cpu 0 pid 10349 tid 10349 ip 0x40100d code 6: Trace doesn't match instruction
After:
$ perf script --insn-trace=disasm
pushw 10349 [000] 10586.869237014: 401000 [unknown] (./pushw) pushw $0x1234
pushw 10349 [000] 10586.869237014: 401004 [unknown] (./pushw) movl $1, %eax
Fixes: eb13296cfa ("x86: Instruction decoder API")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240502105853.5338-3-adrian.hunter@intel.com
The x86 instruction decoder needs to know these new instructions that
are going to be used in the crypto library as well as the x86 core
code. Add the following:
LOADIWKEY:
Load a CPU-internal wrapping key.
ENCODEKEY128:
Wrap a 128-bit AES key to a key handle.
ENCODEKEY256:
Wrap a 256-bit AES key to a key handle.
AESENC128KL:
Encrypt a 128-bit block of data using a 128-bit AES key
indicated by a key handle.
AESENC256KL:
Encrypt a 128-bit block of data using a 256-bit AES key
indicated by a key handle.
AESDEC128KL:
Decrypt a 128-bit block of data using a 128-bit AES key
indicated by a key handle.
AESDEC256KL:
Decrypt a 128-bit block of data using a 256-bit AES key
indicated by a key handle.
AESENCWIDE128KL:
Encrypt 8 128-bit blocks of data using a 128-bit AES key
indicated by a key handle.
AESENCWIDE256KL:
Encrypt 8 128-bit blocks of data using a 256-bit AES key
indicated by a key handle.
AESDECWIDE128KL:
Decrypt 8 128-bit blocks of data using a 128-bit AES key
indicated by a key handle.
AESDECWIDE256KL:
Decrypt 8 128-bit blocks of data using a 256-bit AES key
indicated by a key handle.
The detail can be found in Intel Software Developer Manual.
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Link: https://lore.kernel.org/r/20240502105853.5338-2-adrian.hunter@intel.com
There is an issue in clang's ThinLTO caching (enabled for the kernel via
'--thinlto-cache-dir') with .incbin, which the kernel occasionally uses
to include data within the kernel, such as the .config file for
/proc/config.gz. For example, when changing the .config and rebuilding
vmlinux, the copy of .config in vmlinux does not match the copy of
.config in the build folder:
$ echo 'CONFIG_LTO_NONE=n
CONFIG_LTO_CLANG_THIN=y
CONFIG_IKCONFIG=y
CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
CONFIG_HEADERS_INSTALL=y
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
$ scripts/config -d HEADERS_INSTALL
$ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux
...
UPD kernel/config_data
GZIP kernel/config_data.gz
CC kernel/configs.o
...
LD vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
# CONFIG_HEADERS_INSTALL is not set
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
Without '--thinlto-cache-dir' or when using full LTO, this issue does
not occur.
Benchmarking incremental builds on a few different machines with and
without the cache shows a 20% increase in incremental build time without
the cache when measured by touching init/main.c and running 'make all'.
ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s]
Range (min … max): 56.109 s … 56.594 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s]
Range (min … max): 67.059 s … 68.556 s 10 runs
Summary
With ThinLTO cache ran
1.20 ± 0.01 times faster than Without ThinLTO cache
ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s]
Range (min … max): 85.447 s … 86.244 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s]
Range (min … max): 103.286 s … 104.124 s 10 runs
Summary
With ThinLTO cache ran
1.21 ± 0.00 times faster than Without ThinLTO cache
While it is unfortunate to take this performance improvement off the
table, correctness is more important. If/when this is fixed in LLVM, it
can potentially be brought back in a conditional manner. Alternatively,
a developer can just disable LTO if doing incremental compiles quickly
is important, as a full compile cycle can still take over a minute even
with the cache and it is unlikely that LTO will result in functional
differences for a kernel change.
Cc: stable@vger.kernel.org
Fixes: dc5723b02e ("kbuild: add support for Clang LTO")
Reported-by: Yifan Hong <elsk@google.com>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2021
Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.
In the following example, both A and B can be disabled simultaneously:
choice
prompt "choose A, B, or nothing"
optional
config A
bool "A"
config B
bool "B"
endchoice
You can achieve the equivalent outcome by other means.
A common solution is to add another option to guard the choice block.
In the following example, you can set ENABLE_A_B_CHOICE=n to disable
the entire choice block:
choice
prompt "choose A or B"
depends on ENABLE_A_B_CHOICE
config A
bool "A"
config B
bool "B"
endchoice
Another approach is to insert one more entry:
choice
prompt "choose A, B, or disable both"
config A
bool "A"
config B
bool "B"
config DISABLE_A_AND_B
bool "choose this to disable both A and B"
endchoice
Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE,
LTO_NONE, etc.
The 'optional' property is even more unnecessary for a tristate choice.
Without the 'optional' property, you can disable A and B; you can set
'm' in the choice prompt, and disable A and B individually:
choice
prompt "choose one built-in or make them modular"
config A
tristate "A"
config B
tristate "B"
endchoice
In conclusion, the 'optional' property was unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.
This feature is rarely used. In fact, it is only used in arch/sh/Kconfig
because the equivalent outcome can be achieved by inserting one more
entry.
The 'optional' property support will be removed from Kconfig.
This commit replaces the 'optional' property with a dummy option,
CMDLINE_FROM_BOOTLOADER, as seen in some other architectures.
Note:
The 'default CMDLINE_OVERWRITE' statement does not work as intended
in combination with 'optional'. If neither CONFIG_CMDLINE_OVERWRITE
nor CONFIG_CMDLINE_EXTEND is specified in a defconfig file, both of
them are disabled. This is a bug. To maintain the current behavior,
I added CONFIG_CMDLINE_FROM_BOOTLOADER=y to those defconfig files.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
All symbols except choices have a name.
Previously, choices were allowed to have a name, but commit c83f020973
("kconfig: remove named choice support") eliminated that possibility.
Now, it is easy to distinguish choices from normal symbols; if the name
is NULL, it is a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Given KBUILD_IMAGE properly set in arch/*/Makefile, the default case
should work in most scenarios. The only oddity is the naming of the
copy destination, vmlinux-kbuild-${KERNELRELEASE}. Let's rename it
to vmlinuz-${KERNELRELEASE} because the kernel is often compressed.
Remove the warning to avoid unnecessary patch submissions when the
default case suffices.
Remove the x86 case, which is now equivalent to the default.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
All symbols except choices have a name.
child->sym->name never becomes NULL inside choice blocks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Several functions require traversing menu entries sequentially. This
commit introduces some helpers to simplify such operations.
The menu_next() function facilitates depth-first traversal:
1. Descend to the child level if the current menu has one
2. Move to the next sibling at the same level if available
3. Ascend to the parent level if there is no more child or sibling
The menu_for_each_sub_entry() macro iterates over all submenu entries
using depth-first traverse.
The menu_for_each_entry() macro is the same, but over all menu entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Weak references are references that are permitted to remain unsatisfied
in the final link. This means they cannot be implemented using place
relative relocations, resulting in GOT entries when using position
independent code generation.
The notes section should always exist, so the weak annotations can be
omitted.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
kallsyms is a directory of all the symbols in the vmlinux binary, and so
creating it is somewhat of a chicken-and-egg problem, as its non-zero
size affects the layout of the binary, and therefore the values of the
symbols.
For this reason, the kernel is linked more than once, and the first pass
does not include any kallsyms data at all. For the linker to accept
this, the symbol declarations describing the kallsyms metadata are
emitted as having weak linkage, so they can remain unsatisfied. During
the subsequent passes, the weak references are satisfied by the kallsyms
metadata that was constructed based on information gathered from the
preceding passes.
Weak references lead to somewhat worse codegen, because taking their
address may need to produce NULL (if the reference was unsatisfied), and
this is not usually supported by RIP or PC relative symbol references.
Given that these references are ultimately always satisfied in the final
link, let's drop the weak annotation, and instead, provide fallback
definitions in the linker script that are only emitted if an unsatisfied
reference exists.
While at it, drop the FRV specific annotation that these symbols reside
in .rodata - FRV is long gone.
Tested-by: Nick Desaulniers <ndesaulniers@google.com> # Boot
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20230504174320.3930345-1-ardb%40kernel.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
scripts/package/buildtar checks some kernel packages, and copies the
first image found. This may potentially produce an inconsistent (and
possibly wrong) package.
For instance, the for-loop for arm64 checks Image.{bz2,gz,lz4,lzma,lzo},
and vmlinuz.efi, then copies the first image found, which might be a
stale image created in a previous build.
When CONFIG_EFI_ZBOOT is enabled in the pristine source tree,
'make ARCH=arm64 tar-pkg' will build and copy vmlinuz.efi. This is the
expected behavior.
If you build the kernel with CONFIG_EFI_ZBOOT disabled, Image.gz will
be created, which will remain in the tree until you run 'make clean'.
Even if CONFIG_EFI_ZBOOT is turned on later, 'make ARCH=arm64 tar-pkg'
will copy stale Image.gz instead of the latest vmlinuz.efi, as Image.gz
takes precedence over vmlinuz.efi.
In summary, the code "[ -f ... ] && cp" does not consistently produce
the desired outcome.
Other packaging targets are deterministic; deb-pkg and rpm-pkg copies
${KBUILD_IMAGE}, which is determined by CONFIG options.
I removed [ -f ... ] checks from x86, alpha, parisc, and the default
because they have a single kernel image to copy. If it is missing, it
should be an error.
I did not modify the code for mips, arm64, riscv. Instead, I left some
comments. Eventually, someone may fix the code, or at the very least,
it may discourage the copy-pasting of incorrect code to another
architecture.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Running dtbs_check and dt_compatible_check targets really only depend
on processed-schema.json, but the dependency is 'dt_binding_check'. That
was sort worked around with the CHECK_DT_BINDING variable in order to
skip some of the work that 'dt_binding_check' does. It still runs the
full checks of the schemas which is not necessary and adds 10s of
seconds to the build time. That's significant when checking only a few
DTBs and with recent changes that have improved the validation time by
6-7x.
Add a new target, dt_binding_schema, which just builds
processed-schema.json and can be used as the dependency for other
targets. The scripts_dtc dependency isn't needed either as the examples
aren't built for it.
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Add IEEE80211_RADIOTAP_EHT and IEEE80211_RADIOTAP_EHT_USIG radiotap
to fill in EHT information, such as MCS, NSS, GI and bandwidth.
Co-developed-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
