On the rkisp1 (in my case on a NXP i.MX8 M Plus) the ISP interrupt
handler is sometimes called with RKISP1_CIF_ISP_V_START (start of frame)
and RKISP1_CIF_ISP_FRAME (end of frame) being set at the same time. In
commit 8524fa22fd ("media: staging: rkisp1: isp: add a warning and
debugfs var for irq delay") a warning was added for that. There are two
cases where this condition can occur:
1. The v-sync and the frame-end belong to the same frame. This means,
the irq was heavily delayed and the warning is likely appropriate.
2. The v-sync belongs to the next frame. This can happen if the vertical
blanking between two frames is very short.
The current code always handles case 1 although case 2 is in my
experience the more common case and happens in regular usage. This leads
to incorrect sequence numbers on stats and params buffers which in turn
breaks the regulation in user space. Fix that by adding a frame_active
flag to distinguish between these cases and handle the start of frame
either at the beginning or at the end of the rkisp1_isp_isr().
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Link: https://patch.msgid.link/20250922182003.3712101-2-stefan.klug@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Frank has been reviewing NXP media drivers for a while, and is
volunteering to continue. Add him as a reviewer for the IMX media
drivers.
Also add the NXP i.MX platform mailing list (imx@lists.linux.dev).
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20250904161720.514889-1-Frank.Li@nxp.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
- Unsupported APIs cleanup
- New sniffer API
- small bugfixes and features
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQM3A3Pv7vbm9vtjWbacY7uyt+OfQUCaQDS5gAKCRDacY7uyt+O
fapgAQD0w9ktKj7jsmvIQui5i2lE0FctQss8JydTXfJIw7qt4gD9EXpE+SgVLfDV
qzZPYWs1YEqOGHITTuzYFKfm3FFxMgg=
=SR81
-----END PGP SIGNATURE-----
Merge tag 'iwlwifi-next-2025-10-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
Miri Korenblit says:
====================
iwlwifi features. Notably:
- Unsupported APIs cleanup
- New sniffer API
- small bugfixes and features
====================
Link: https://patch.msgid.link/DM3PPF63A6024A9B77EE7385B4C865E3E54A3FDA@DM3PPF63A6024A9.namprd11.prod.outlook.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This was supposed to pass "onenand" instead of "&onenand" with the
ampersand. Passing a random stack address which will be gone when the
function ends makes no sense. However the good thing is that the pointer
is never used, so this doesn't cause a problem at run time.
Fixes: e23abf4b77 ("mtd: OneNAND: S5PC110: Implement DMA interrupt method")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
According to datasheet (http://eng.fmsh.com/nvm/FM25S01A_ds_eng.pdf)
there is no QE (Quad Enable) bit for FM25S01A flash, so remove it.
Fixes: 5f284dc15c ("mtd: spinand: add support for FudanMicro FM25S01A")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Tested-by: Tianling Shen <cnsztl@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
cpu-clock usage by the async-profiler tool can trigger a system hang,
which got bisected back to the following commit by Octavia Togami:
18dbcbfabf ("perf: Fix the POLL_HUP delivery breakage") causes this issue
The root cause of the hang is that cpu-clock is a special type of SW
event which relies on hrtimers. The __perf_event_overflow() callback
is invoked from the hrtimer handler for cpu-clock events, and
__perf_event_overflow() tries to call cpu_clock_event_stop()
to stop the event, which calls htimer_cancel() to cancel the hrtimer.
But that's a recursion into the hrtimer code from a hrtimer handler,
which (unsurprisingly) deadlocks.
To fix this bug, use hrtimer_try_to_cancel() instead, and set
the PERF_HES_STOPPED flag, which causes perf_swevent_hrtimer()
to stop the event once it sees the PERF_HES_STOPPED flag.
[ mingo: Fixed the comments and improved the changelog. ]
Closes: https://lore.kernel.org/all/CAHPNGSQpXEopYreir+uDDEbtXTBvBvi8c6fYXJvceqtgTPao3Q@mail.gmail.com/
Fixes: 18dbcbfabf ("perf: Fix the POLL_HUP delivery breakage")
Reported-by: Octavia Togami <octavia.togami@gmail.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Octavia Togami <octavia.togami@gmail.com>
Cc: stable@vger.kernel.org
Link: https://github.com/lucko/spark/issues/530
Link: https://patch.msgid.link/20251015051828.12809-1-dapeng1.mi@linux.intel.com
Start using display parent interface for i915 runtime pm. Doing the same
for xe is done in coming changes.
v3:
- remove useless include
v2:
- use <> when including drm/intel/display_parent_interface.h
- drop checks for validity of rpm function pointers
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-6-jouni.hogander@intel.com
Implement runtime pm wrappers for xe driver and add them into display
parent interface.
v3:
- drop useless include
- drop xe_display_rpm_{get, put}_raw
v2:
- move xe_display_rpm_interface code into xe_display_rpm.c
- rename xe_rpm as xe_display_rpm
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-5-jouni.hogander@intel.com
We have differing implementations for display runtime pm in i915 and xe
drivers. Add struct of function pointers into display_parent_interface
which will contain used implementation of runtime pm.
v2:
- add _interface suffix to rpm function pointer struct
- add struct ref_tracker forward declaration
- use kernel-doc comments
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-3-jouni.hogander@intel.com
Let's gradually start calling i915 and xe parent, or core, drivers from
display via function pointers passed at display probe.
Going forward, the struct intel_display_parent_interface is expected to
include const pointers to sub-structs by functionality, for example:
struct intel_display_rpm {
struct ref_tracker *(*get)(struct drm_device *drm);
/* ... */
};
struct intel_display_parent_interface {
/* ... */
const struct intel_display_rpm *rpm;
};
This is a baby step towards not building display as part of both i915
and xe drivers, but rather making it an independent driver interfacing
with the two.
v3: useless include additions dropped
v2: unrelated include removal dropped
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20251030202836.1815680-2-jouni.hogander@intel.com
J784S4 SoC has two instances of PCIe which are PCIe0 and PCIe1. J784S4
SoC uses PCIe1 instance for PCIe boot process. To configure PCIe1 at
all boot stages "pcie1_ctrl" also needs to be present at all boot
stages. Thus add the "bootph-all" boot phase tag to "pcie1_ctrl" device
tree node.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20251017084654.2929945-4-h-salunke@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 SoC has two instances of PCIe which are PCIe0 and PCIe1. PCIe1
instance is used for PCIe boot process. J784S4 SoC has four instances
of 4-lane SERDES. Out of which SERDES0 is used as PHY for PCIe1. So it
needs to be functional at all stages of PCIe boot process. Thus add the
"bootph-all" boot phase tag to nodes required to enable SERDES0 at all
boot stages.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20251017084654.2929945-3-h-salunke@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
J784S4 SoC has two instances of PCIe which are PCIe0 and PCIe1. J784S4
SoC uses PCIe1 instance for PCIe boot process. So it needs to be in
endpoint mode and it needs to be functional at all stages of PCIe boot
process. Thus add the "bootph-all" boot phase tag to "pcie1_ep" device
tree node.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Link: https://patch.msgid.link/20251017084654.2929945-2-h-salunke@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Convert 9p to the new mount API. This patch consolidates all parsing
into fs/9p/v9fs.c, which stores all results into a filesystem context
which can be passed to the various transports as needed.
Some of the parsing helper functions such as get_cache_mode() have been
eliminated in favor of using the new mount API's enum param type,
for simplicity.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Message-ID: <20251010214222.1347785-5-sandeen@redhat.com>
[ Dominique: handled source explicitly as per follow-up discussion ]
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
This patch creates a new v9fs_context structure which includes
new p9_session_opts and p9_client_opts structures, as well as
re-using the existing p9_fd_opts and p9_rdma_opts to store options
during parsing. The new structure will be used in the next
commit to pass all parsed options to the appropriate transports.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Message-ID: <20251010214222.1347785-4-sandeen@redhat.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
With the new mount API all option parsing will need to happen
in fs/v9fs.c, so move some existing data structures and macros
to header files to facilitate this. Rename some to reflect
the transport they are used for (rdma, fd, etc), for clarity.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Message-ID: <20251010214222.1347785-3-sandeen@redhat.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
296b67059 removed fsparam_u32hex because there were no callers
(yet) and it didn't build due to using the nonexistent symbol
fs_param_is_u32_hex.
fs/9p will need this parser, so add it back with the appropriate
fix (use fs_param_is_u32).
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Message-ID: <20251010214222.1347785-2-sandeen@redhat.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
We already know that "retval" is negative, so there is no need to check
again. Also the statement is not indented far enough. Delete it.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Fixes: 43c36a56cc ("Revert "fs/9p: Refresh metadata in d_revalidate for uncached mode too"")
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Message-ID: <aPtiSJl8EwSfVvqN@stanley.mountain>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
When page cache is used, writebacks are done on a page granularity, and it
is expected that the underlying filesystem (such as v9fs) should respect
the write position. However, currently v9fs will passthrough O_APPEND to
the server even on cached mode. This causes data corruption if a sync or
fstat gets between two writes to the same file.
This patch removes the APPEND flag from the open request we send to the
server when writeback caching is involved. I believe keeping server-side
APPEND is probably fine for uncached mode (even if two fds are opened, one
without O_APPEND and one with it, this should still be fine since they
would use separate fid for the writes).
Signed-off-by: Tingmao Wang <m@maowtm.org>
Fixes: 4eb3117888 ("fs/9p: Rework cache modes and add new options to Documentation")
Message-ID: <20251102235631.8724-1-m@maowtm.org>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
'->def' is only ever used as a true/false flag
Reported-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-ID: <20251103-v9fs_trans_def_bool-v1-1-f33dc7ed9e81@codewreck.org>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
While developing a 9P server (https://github.com/Barre/ZeroFS) and
testing it under high-load, I was running into allocation failures.
The failures occur even with plenty of free memory available because
kmalloc requires contiguous physical memory.
This results in errors like:
ls: page allocation failure: order:7, mode:0x40c40(GFP_NOFS|__GFP_COMP)
This patch introduces a transport capability flag (supports_vmalloc)
that indicates whether a transport can work with vmalloc'd buffers
(non-physically contiguous memory). Transports requiring DMA should
leave this flag as false.
The fd-based transports (tcp, unix, fd) set this flag to true, and
p9_fcall_init will use kvmalloc instead of kmalloc for these
transports. This allows the allocator to fall back to vmalloc when
contiguous physical memory is not available.
Additionally, if kmem_cache_alloc fails, the code falls back to
kvmalloc for transports that support it.
Signed-off-by: Pierre Barre <pierre@barre.sh>
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Message-ID: <d2017c29-11fb-44a5-bd0f-4204329bbefb@app.fastmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Add a RK3288 compatible for a version of the Rockchip VDEC IP that only
support HEVC decoding.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, RockPro64, Quartz64-B, NanoPi R5S
Tested-by: Detlev Casanova <detlev.casanova@collabora.com> # RK3399
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The RK3328 VDEC has a HW quirk that require QoS to be disabled when HEVC
or VP9 is decoded, otherwise the decoded picture may become corrupted.
Add a RK3328 variant with a quirk flag to disable QoS when before
decoding is started.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, RockPro64, Quartz64-B, NanoPi R5S
Tested-by: Detlev Casanova <detlev.casanova@collabora.com> # RK3399
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add a RK3288 variant, a version of the Rockchip VDEC IP that only
support HEVC decoding.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, RockPro64, Quartz64-B, NanoPi R5S
Tested-by: Detlev Casanova <detlev.casanova@collabora.com> # RK3399
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Add filtering of coded formats and controls depending on a variant
capabilities.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, RockPro64, Quartz64-B, NanoPi R5S
Tested-by: Detlev Casanova <detlev.casanova@collabora.com> # RK3399
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Different versions of the Rockchip VDEC IP exists and one way they can
differ is what decoding formats are supported.
Add a variant implementation in order to support flagging different
capabilities.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, RockPro64, Quartz64-B, NanoPi R5S
Tested-by: Detlev Casanova <detlev.casanova@collabora.com> # RK3399
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The Rockchip VDEC supports the HEVC codec with the Main and Main10
Profile up to Level 5.1 High tier: 4096x2304@60 fps.
Add the backend for HEVC format to the decoder.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64, RockPro64, Quartz64-B, NanoPi R5S
Tested-by: Detlev Casanova <detlev.casanova@collabora.com> # RK3399
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
gt_reset() doesn't make sense by itself: it can only be called as part
of the worker. Inline it there to avoid it being called from elsewhere
and clarify the gt_reset() vs do_gt_reset() paths. Note that the error
return from gt_reset() was just being ignored.
Also add a comment to the xe_pm_runtime_put() to make sure the
get()/put() pair is clear.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20251031222244.37735-2-lucas.demarchi@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
In the past two years, I have focused on EROFS and contributed features
including the reserved buffer pool, configurable global buffer pool, and
the ongoing direct I/O support for compressed data.
I would like to continue contributing to EROFS and help with code
reviews. Please CC me on EROFS-related changes.
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Acked-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Acked-by: Chao Yu <chao@kernel.org>
Acked-by: Hongbo Li <lihongbo22@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Mike Christie <michael.christie@oracle.com> says:
The following patches were made over Linus tree. They fix/improve the
stats used in the main IO path. The first patch fixes an issue where
I made some stats u32 when they should have stayed u64. The rest of
the patches improve the handling of RW/num_cmds stats to reduce code
duplication and improve performance.
Link: https://patch.msgid.link/20250917221338.14813-1-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The atomic use in the main I/O path is causing perf issues when using
higher performance backend devices and multiple queues (more than
10 when using vhost-scsi) like with this fio workload:
[global]
bs=4K
iodepth=128
direct=1
ioengine=libaio
group_reporting
time_based
runtime=120
name=standard-iops
rw=randread
numjobs=16
cpus_allowed=0-15
To fix this issue, move the LUN stats to per CPU.
Note: I forgot to include this patch with the delayed/ordered per CPU
tracking and per device/device entry per CPU stats. With this patch you
get the full 33% improvements when using fast backends, multiple queues
and multiple IO submiters.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://patch.msgid.link/20250917221338.14813-4-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Create some macros to reduce code duplication for when we handle per-CPU
stats. Convert the existing LUN and auth cases.
Note: This is similar to percpu_counters but they only support s64 since
they are also used for non-stat counters where you need to handle/prevent
rollover more gracefully. Our use is just for stats where the spec
defines u64 use plus we already have some files exporting u64 values so
it's not possible to directly use percpu_counters.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://patch.msgid.link/20250917221338.14813-3-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In commit 9cf2317b79 ("scsi: target: Move I/O path stats to per CPU")
I saw we sometimes use %u and also misread the spec. As a result I
thought all the stats were supposed to be 32-bit only. However, for the
majority of cases we support currently, the spec specifies u64 bit
stats. This patch converts the stats changed in the commit above to u64.
Fixes: 9cf2317b79 ("scsi: target: Move I/O path stats to per CPU")
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
Link: https://patch.msgid.link/20250917221338.14813-2-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Check whether or not the conversion of the argument to an integer
succeeded. Reject invalid timeout values.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20251031221844.2921694-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Replace Stanley Chu with me and Chaotian in the maintainers field since
Stanley's email address is no longer active.
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251031122008.1517549-1-peter.wang@mediatek.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Remove the stack buffer 'buf'. This patch does not modify the output
produced by target_lu_gp_members_show().
An example of the output that is produced with this patch applied:
$ cat /sys/kernel/config/target/core/alua/lu_gps/default_lu_gp/members
fileio_0/vdev0
fileio_1/vdev1
iblock_0/vdev2
$ od -c /sys/kernel/config/target/core/alua/lu_gps/default_lu_gp/members
0000000 f i l e i o _ 0 / v d e v 0 \n f
0000020 i l e i o _ 1 / v d e v 1 \n i b
0000040 l o c k _ 0 / v d e v 2 \n
0000055
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20251027184639.3501254-3-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
NUL characters are not allowed in ASCII configfs output. Hence this
patch.
Fixes: c66ac9db8d ("[SCSI] target: Add LIO target core v4.0.0-rc6")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://patch.msgid.link/20251027184639.3501254-2-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry <john.g.garry@oracle.com> says:
This is a reposting of Mike's atomic writes support for the SCSI
target.
Again, we are now only supporting target_core_iblock. It's implemented
similar to UNMAP where we do not do any emulation and instead pass the
operation to the block layer.
Link: https://patch.msgid.link/20251020103820.2917593-1-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Make target_core_iblock use the LIO helper function to translate its
block_device atomic settings to LIO settings. If we then get a write
that LIO has indicated is atomic via the SCF_ATOMIC flag, we use the
REQ_ATOMIC flag to tell the block layer to perform an atomic write.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-8-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Report if the device supports WRITE_ATOMIC_16 in the
REPORT_SUPPORTED_OPERATION_CODES command.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-7-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Report the atomic values in the Block Limits VPD page.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
jpg: handle not having atomic_supported attribute
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-6-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add the core LIO code to process the WRITE_ATOMIC_16 command.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
jpg: fix return code from sbc_check_atomic, reformat
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-5-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add a helper function that sets up the atomic value based on a
block_device similar to what we do for unmap.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
jpg: Set atomic alignment, drop atomic_supported reference
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-4-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add atomic fields to the se_device and export them in configfs.
Initially only target_core_iblock will be supported and we will inherit
all the settings from the block layer.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
jpg: Stop being allowed to configure atomic write alignment,
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-3-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Rename target_configure_unmap_from_queue() to
target_configure_unmap_from_bdev() since it now takes a bdev.
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Link: https://patch.msgid.link/20251020103820.2917593-2-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
