SPI NOR core changes:
- Add Pratyush as SPI NOR co-maintainer.
- Flash parameters initialization was done in a spaghetti way. Clean
flash parameters initialization.
- Rework the flash_info flags and clarify where one should be used.
- Initialize all flash parameters based on JESD216 SFDP where possible.
Flash parameters and settings that are SFDP discoverable should not be
duplicated via flash_info flags at flash declaration.
- Remove debugfs entries that duplicate sysfs entries.
SPI NOR manufacturer drivers changes:
- Use late_init() hook in various drivers to make it clear that those
flash parameters are either not declared in the JESD216 SFDP standard,
or the SFDP tables which define those flash parameters are not defined
by the flash.
- Fix mtd size for s3an flashes.
- Write 2 bytes when disabling Octal DTR mode: 1 byte long transactions are
not allowed in 8D-8D-8D mode.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Hyperbus changes for v5.17-rc1
Hyperbus changes:
Couple of fixes in Renesas hyperbus rpc-if driver to avoid crash on
module remove and for missing check for error value in probe.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
SPI NOR sysfs defines partname and jedec_id device attributes, which
duplicate the information from debugfs. Since the sysfs directory
structure and the attributes in each directory define an ABI between the
kernel and user space, thus it can never be removed, remove the debugfs
entries so that we don't duplicate the information.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211217122636.474976-2-tudor.ambarus@microchip.com
The Octal DTR configuration is stored in the CFR0V register. This
register is 1 byte wide. But 1 byte long transactions are not allowed in
8D-8D-8D mode. The next byte address contains the CFR1V register, which
contains the number of dummy cycles. This is very fortunate since the
enable path changes the value of this register. Reset the value to its
default when disabling Octal DTR mode. This way, both changes to the
flash state made when enabling can be reverted in one single
transaction.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210531181757.19458-4-p.yadav@ti.com
The Octal DTR configuration is stored in the CFR5V register. This
register is 1 byte wide. But 1 byte long transactions are not allowed in
8D-8D-8D mode. Since the next byte address does not contain any
register, it is safe to write any value to it. Write a 0 to it.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20210531181757.19458-3-p.yadav@ti.com
The template ops used in spi_nor_spimem_check_pp() and
spi_nor_spimem_check_readop() currently set the data phase to 1 byte
long. This is problematic for 8D-8D-8D protocol where odd length data
phase is invalid since one cycle transfers 2 bytes and odd number of
bytes would mean half a cycle is left over. This could result in a
controller rejecting the op as "not supported" even though it actually
supports the protocol.
Change the data length to 2 bytes in these templates. One might argue
that this should only be done for 8D-8D-8D operations but when talking
about these templates, there is no functional difference between one and
two bytes, even in STR modes.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210531181757.19458-2-p.yadav@ti.com
Remove the references to the old spi-nor.c file.
The old drivers/mtd/spi-nor/spi-nor.c file
is not more present and now some of its code is contained in:
drivers/mtd/spi-nor/core.c
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
[tudor.ambarus@microchip.com:
- remove change in Documentation/driver-api/mtd/spi-nor.rst.
The documentation has to be rewritten entirely.
- update commit message]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20210126092516.1431913-1-f.suligoi@asem.it
In the mtdchar_write_ioctl() function, memdup_user() is called with its
'len' parameter set to verbatim values provided by user space via a
struct mtd_write_req. Both the 'len' and 'ooblen' fields of that
structure are 64-bit unsigned integers, which means the MEMWRITE ioctl
can trigger unbounded kernel memory allocation requests.
Fix by iterating over the buffers provided by user space in a loop,
processing at most mtd->erasesize bytes in each iteration. Adopt some
checks from mtd_check_oob_ops() to retain backward user space
compatibility.
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Michał Kępień <kernel@kempniu.pl>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211130113149.21848-1-kernel@kempniu.pl
When developping NAND controller drivers or when debugging filesystem
corruptions, it is quite common to need hacking locally into the
MTD/NAND core in order to get access to the content of the bad
blocks. Instead of having multiple implementations out there let's
provide a simple yet effective specific MTD-wide debugfs entry to fully
disable these checks on purpose.
A warning is added to inform the user when this mode gets enabled.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211118114659.1282855-1-miquel.raynal@bootlin.com
Get rid of the static initialization of the flash parameters and
init them when parsing SFDP.
Generated a 256 Kbyte random data and did an erase, write, read back
and compare test. The flash uses for reads SPINOR_OP_READ_1_4_4_4B 0xec,
for erases SPINOR_OP_BE_4K_4B 0x21, and for writes SPINOR_OP_PP_4B 0x12.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20211207140254.87681-15-tudor.ambarus@microchip.com
Get rid of the static initialization of the flash parameters and
init them when parsing SFDP.
Generated a 256 Kbyte random data and did an erase, write, read back
and compare test. The flash uses for reads SPINOR_OP_READ_1_4_4_4B 0xec,
for erases SPINOR_OP_BE_4K_4B 0x21, and for writes SPINOR_OP_PP_1_1_4_4B
0x34.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20211207140254.87681-14-tudor.ambarus@microchip.com
Get rid of the static initialization of the flash parameters and
init them when parsing SFDP.
Generated a 256 Kbyte random data and did an erase, write, read back
and compare test. The flash uses for reads SPINOR_OP_READ_1_4_4 0xeb,
for erases SPINOR_OP_BE_4K 0x20, and for writes SPINOR_OP_PP 0x02.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20211207140254.87681-12-tudor.ambarus@microchip.com
New flash additions that support SFDP should be declared with
PARSE_SFDP and with all the other flags that are not SFDP
discoverable.
Keep the old way of initializing the flash, until all the flashes
are converted to use either PARSE_SFDP or SPI_NOR_SKIP_SFDP.
Flashes that declare PARSE_SFDP do not have a roll-back mechanism
because if spi_nor_parse_sfdp() returns an error it means that either
BFPT is not supported, thus SFDP is not supported and the user didn't
correctly declared the flash_info entry, or some memalloc failed.
Either way we should return an error. The rest of the SFDP tables are
optional, if one of the optional SFDP tables fails, we just continue.
We would like to get rid of the default_init() hook, so the
spi_nor_manufacturer_init_params() is not called in the new sequnce
of flash initialization.
Split spi_nor_info_init_params() in spi_nor_init_default_params()
and spi_nor_no_sfdp_init_params(). spi_nor_init_default_params() is
called for all the flashes regardless if they support SFDP or not.
spi_nor_no_sfdp_init_params() is called just for the flashes that
do not define SFDP and initializes parameters and setting solely
based on flash_info data.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-10-tudor.ambarus@microchip.com
Group NOR flags initialization. Introduce a dedicated function for
setting the fixup_flags and emphasise when those flash_info flags
should be set: when the SNOR_F_4B_OPCODES/SNOR_F_IO_MODE_EN_VOLATILE
setttings can not be discovered by SFDP for this particular flash
because the SFDP table that indicates this support is not defined
in the flash.
In case the table for his support is defined but has wrong values,
one should instead use a post_sfdp() hook to set the SNOR_F equivalent
flag.
No functional change intended in this patch.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-9-tudor.ambarus@microchip.com
Used to initialize the NOR flags for settings that are not defined
in the JESD216 SFDP standard, thus can not be retrieved when parsing
SFDP.
This moves the setting of SNOR_F_READY_XSR_RDY and SNOR_F_HAS_LOCK
late in the init call, without any functional change expected.
The rest of the flags were already set after the spi_nor_init_params().
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-8-tudor.ambarus@microchip.com
Clarify for what the flash_info flags are used for. Split them in
four categories and a bool:
1/ FLAGS: flags that indicate support that is not defined by the JESD216
standard in its SFDP tables.
2/ NO_SFDP_FLAGS: these flags are used when the flash does not define the
SFDP tables. These flags indicate support that can be discovered via
SFDP. Used together with SPI_NOR_SKIP_SFDP flag.
3/ FIXUP_FLAGS: flags that indicate support that can be discovered
via SFDP ideally, but can not be discovered for this particular flash
because the SFDP table that indicates this support is not defined by
the flash. In case the table for this support is defined but has wrong
values, one should instead use a post_sfdp() hook to set the SNOR_F
equivalent flag.
4/ MFR_FLAGS: manufacturer private flags. Used in the manufacturer
fixup hooks to differentiate support between flashes of the same
manufacturer.
5/ PARSE_SFDP: sets info->parse_sfdp to true. All flash_info entries
that support SFDP should be converted to set info->parse_sfdp to true.
SPI NOR flashes that statically declare one of the
SPI_NOR_{DUAL, QUAD, OCTAL, OCTAL_DTR}_READ flags and do not support
the RDSFDP command are gratuiously receiving the RDSFDP command
in the attempt of parsing the SFDP tables. It is not desirable to issue
commands that are not supported, so introduce PARSE_SFDP to help on this
situation.
New flash additions/updates should be declared/updated to use either
PARSE_SFDP or SPI_NOR_SKIP_SFDP. Once all the flash_info entries are
converted to use SPI_NOR_SKIP_SFDP or PARSE_SFDP, we can get rid of the
SPI_NOR_SKIP_SFDP flag and use just the bool nor->info->parse_sfdp to
determine whether to parse SFDP or not. SPI_NOR_SKIP_SFDP flag is kept
just as a way to differentiate whether a flash is converted to the new
flags logic or not.
Support that can be discovered when parsing SFDP should not be duplicated
by explicit flags at flash declaration. All the flash parameters will be
discovered when parsing SFDP. Sometimes manufacturers wrongly define some
fields in the SFDP tables. If that's the case, SFDP data can be amended
with the fixups() hooks. It is not common, but if the SFDP tables are
entirely wrong, and it does not worth the hassle to tweak the SFDP
parameters by using the fixups hooks, or if the flash does not define the
SFDP tables at all, then statically init the flash with the
SPI_NOR_SKIP_SFDP flag and specify the rest of flash capabilities with
the flash info flags.
With time, we want to convert all flashes to use PARSE_SFDP and
stop triggering the SFDP parsing with the
SPI_NOR_{DUAL, QUAD, OCTAL*}_READ flags. Getting rid of the
SPI_NOR_{OCTAL, OCTAL_DTR}_READ trigger is easily achievable,
the rest are a long term goal.
Manufacturer specific flags like USE_CLSR, USE_FSR, SPI_NOR_XSR_RDY,
will be removed in a future series.
No functional changes intended in this patch.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-7-tudor.ambarus@microchip.com
spi_nor_post_sfdp_fixups() was called even when there were no SFDP
tables defined. late_init() should be instead used for flashes that
do not define SFDP tables.
Use spi_nor_post_sfdp_fixups() just to fix SFDP data. post_sfdp()
hook is as of now used just by s28hs512t, mt35xu512aba, and both
support SFDP, there's no functional change with this patch.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-5-tudor.ambarus@microchip.com
Used to init all the mtd_info fields. Move the mtd_info init
the last thing in the spi_nor_scan(), so that we avoid superfluous
initialization of the mtd_info fields in case of errors.
While here use common naming scheme for functions that are setting
mtd_info fields:
s/spi_nor_register_locking_ops/spi_nor_set_mtd_locking_ops
s/spi_nor_otp_init/spi_nor_set_mtd_otp_ops
The functions names are self explanatory, get rid of the comment
for the OTP function.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-4-tudor.ambarus@microchip.com
Use NOR parameters in the probe's sequence of calls, thus
nor->params->size instead of nor->mtd.size and let the mtd_info
fields be used by the mtd calls (mtd->_erase, mtd->_read, mtd->_write).
mtd_info fields should not be used during probe because we haven't
registered mtd yet. It's safe to drop xilinx's setting of nor->mtd.size,
now that we use nor->params->size in spi_nor_set_addr_width().
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-3-tudor.ambarus@microchip.com
As it was before the blamed commit, s3an_nor_scan() was called
after mtd size was set with params->size, and it overwrote the mtd
size value with '8 * nor->page_size * nor->info->n_sectors' when
XSR_PAGESIZE was set. With the introduction of
s3an_post_sfdp_fixups(), we missed to update the mtd size for the
s3an flashes. Fix the mtd size by updating both nor->params->size,
(which will update the mtd_info size later on) and nor->mtd.size
(which is used in spi_nor_set_addr_width()).
Fixes: 641edddb4f ("mtd: spi-nor: Add s3an_post_sfdp_fixups()")
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211207140254.87681-2-tudor.ambarus@microchip.com
If there is more than one mtd device which supports OTP, there will
be a kernel warning about duplicated sysfs entries and the probing will
fail. This is because the nvmem device name is not unique. Make it
unique by prepending the name of the mtd. E.g. before the name was
"user-otp", now it will be "mtd0-user-otp".
For reference the kernel splash is:
[ 4.665531] sysfs: cannot create duplicate filename '/bus/nvmem/devices/user-otp'
[ 4.673056] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-next-20211101+ #1296
[ 4.680565] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
[ 4.688856] Call trace:
[ 4.691303] dump_backtrace+0x0/0x1bc
[ 4.694984] show_stack+0x24/0x30
[ 4.698306] dump_stack_lvl+0x68/0x84
[ 4.701980] dump_stack+0x18/0x34
[ 4.705302] sysfs_warn_dup+0x70/0x90
[ 4.708973] sysfs_do_create_link_sd+0x144/0x150
[ 4.713603] sysfs_create_link+0x2c/0x50
[ 4.717535] bus_add_device+0x74/0x120
[ 4.721293] device_add+0x330/0x890
[ 4.724791] device_register+0x2c/0x40
[ 4.728550] nvmem_register+0x240/0x9f0
[ 4.732398] mtd_otp_nvmem_register+0xb0/0x10c
[ 4.736854] mtd_device_parse_register+0x28c/0x2b4
[ 4.741659] spi_nor_probe+0x20c/0x2e0
[ 4.745418] spi_mem_probe+0x78/0xbc
[ 4.749001] spi_probe+0x90/0xf0
[ 4.752237] really_probe.part.0+0xa4/0x320
..
[ 4.873936] mtd mtd1: Failed to register OTP NVMEM device
[ 4.894468] spi-nor: probe of spi0.0 failed with error -17
Fixes: 4b361cfa86 ("mtd: core: add OTP nvmem provider support")
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20211104134843.2642800-1-michael@walle.cc
The following KASAN BUG is observed when testing the rpc-if driver on
rcar-gen3:
root@rcar-gen3:~# modprobe -r rpc-if
[ 101.930146] ==================================================================
[ 101.937408] BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x518/0x25d0
[ 101.944240] Read of size 8 at addr ffff0004c5be2750 by task modprobe/664
[ 101.950959]
[ 101.952466] CPU: 2 PID: 664 Comm: modprobe Not tainted 5.14.0-rc1-00342-g1a1464d7aa31 #1
[ 101.960578] Hardware name: Renesas H3ULCB board based on r8a77951 (DT)
[ 101.967120] Call trace:
[ 101.969580] dump_backtrace+0x0/0x2c0
[ 101.973275] show_stack+0x1c/0x30
[ 101.976616] dump_stack_lvl+0x9c/0xd8
[ 101.980301] print_address_description.constprop.0+0x74/0x2b8
[ 101.986071] kasan_report+0x1f4/0x26c
[ 101.989757] __asan_load8+0x98/0xd4
[ 101.993266] __lock_acquire+0x518/0x25d0
[ 101.997215] lock_acquire.part.0+0x18c/0x360
[ 102.001506] lock_acquire+0x74/0x90
[ 102.005013] _raw_spin_lock_irq+0x98/0x130
[ 102.009131] __pm_runtime_disable+0x30/0x210
[ 102.013427] rpcif_hb_remove+0x5c/0x70 [rpc_if]
[ 102.018001] platform_remove+0x40/0x80
[ 102.021771] __device_release_driver+0x234/0x350
[ 102.026412] driver_detach+0x158/0x20c
[ 102.030179] bus_remove_driver+0xa0/0x140
[ 102.034212] driver_unregister+0x48/0x80
[ 102.038153] platform_driver_unregister+0x18/0x24
[ 102.042879] rpcif_platform_driver_exit+0x1c/0x34 [rpc_if]
[ 102.048400] __arm64_sys_delete_module+0x210/0x310
[ 102.053212] invoke_syscall+0x60/0x190
[ 102.056986] el0_svc_common+0x12c/0x144
[ 102.060844] do_el0_svc+0x88/0xac
[ 102.064181] el0_svc+0x24/0x3c
[ 102.067257] el0t_64_sync_handler+0x1a8/0x1b0
[ 102.071634] el0t_64_sync+0x198/0x19c
[ 102.075315]
[ 102.076815] Allocated by task 628:
[ 102.080781]
[ 102.082280] Last potentially related work creation:
[ 102.087524]
[ 102.089022] The buggy address belongs to the object at ffff0004c5be2000
[ 102.089022] which belongs to the cache kmalloc-2k of size 2048
[ 102.101555] The buggy address is located 1872 bytes inside of
[ 102.101555] 2048-byte region [ffff0004c5be2000, ffff0004c5be2800)
[ 102.113486] The buggy address belongs to the page:
[ 102.118409]
[ 102.119908] Memory state around the buggy address:
[ 102.124711] ffff0004c5be2600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.131947] ffff0004c5be2680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.139181] >ffff0004c5be2700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.146412] ^
[ 102.152257] ffff0004c5be2780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.159491] ffff0004c5be2800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 102.166723] ==================================================================
The above bug is caused by use of the wrong pointer in the
rpcif_disable_rpm() call. Fix the bug by using the correct pointer.
Fixes: 5de15b610f ("mtd: hyperbus: add Renesas RPC-IF driver")
Signed-off-by: George G. Davis <davis.george@siemens.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210716204935.25859-1-george_davis@mentor.com
spansion_post_sfdp_fixups() was called regardless if the flash defined
SFDP tables or not. A better place for this kind of parameters init is
in manufacturer's late_init() hook. post_sfdp() should be called only
when SFDP is defined. No functional change in this patch.
Instead of doing the 4b opcodes settings at manufacturer level, thus
also for every flash that will be introduced, this should be done
just where it is needed, per flash. I'll let this for other patch.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211029172633.886453-12-tudor.ambarus@microchip.com
OTP is not described in the JESD216 SFDP standard, place the
OTP ops init in late_init().
We can't get rid of the default_init() hook for winbond, as the
4byte_addr_mode is SFDP specific and will require to have all
flashes at hand, in order to check which has the SFDP tables defined,
in which case there's nothing to do if the SFDP tables are corect,
and which of the flashes do not define the SFDP tables in which case
each flash should declare a late_init() fixup.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211029172633.886453-9-tudor.ambarus@microchip.com
Flash parameters init is done in a spaghetti way right now.
There is the init based on the flash_info data, then there is the
default_init() hook, then SFDP init, an intermediary post_bft(),
then post_sfdp() and a spi_nor_late_init_params(). Each method can
overwrite previuosly initialized parameters.
We want to separate what is SFDP and non-SFDP specific. late_init()
will replace the default_init() hook and will be used only to initialize
flash parameters that are not declared in the JESD216 SFDP standard, or
where SFDP tables are not defined at all.
We cut a member in the chain of initializing parameters by getting rid
of the default_init() hook, and we make it clear that everything that is
in late_init() is not covered by the SFDP tables defined by the flash.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Link: https://lore.kernel.org/r/20211029172633.886453-6-tudor.ambarus@microchip.com
Pull xfs cleanups from Darrick Wong:
"The most 'exciting' aspect of this branch is that the xfsprogs
maintainer and I have worked through the last of the code
discrepancies between kernel and userspace libxfs such that there are
no code differences between the two except for #includes.
IOWs, diff suffices to demonstrate that the userspace tools behave the
same as the kernel, and kernel-only bits are clearly marked in the
/kernel/ source code instead of just the userspace source.
Summary:
- Clean up open-coded swap() calls.
- A little bit of #ifdef golf to complete the reunification of the
kernel and userspace libxfs source code"
* tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: sync xfs_btree_split macros with userspace libxfs
xfs: #ifdef out perag code for userspace
xfs: use swap() to make dabtree code cleaner
Pull more parisc fixes from Helge Deller:
"Fix a build error in stracktrace.c, fix resolving of addresses to
function names in backtraces, fix single-stepping in assembly code and
flush userspace pte's when using set_pte_at()"
* tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc/entry: fix trace test in syscall exit path
parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page
parisc: Fix implicit declaration of function '__kernel_text_address'
parisc: Fix backtrace to always include init funtion names
