aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/DocBook/v4l
diff options
context:
space:
mode:
authorSakari Ailus <sakari.ailus@maxwell.research.nokia.com>2010-03-27 09:58:24 -0400
committerMauro Carvalho Chehab <mchehab@redhat.com>2010-05-19 11:58:07 -0400
commitdd96608369be9d3cfc604eaa3a53a2d38f1cb415 (patch)
treefc3e9f5f70aef35255fd2cca2e5a88498827d093 /Documentation/DocBook/v4l
parentd3d7c963562adad92e968df23c425ae964fe9ce2 (diff)
V4L/DVB: V4L: Events: Add documentation
Add documentation on how to use V4L2 events, both for V4L2 drivers and for V4L2 applications. Signed-off-by: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/DocBook/v4l')
-rw-r--r--Documentation/DocBook/v4l/dev-event.xml31
-rw-r--r--Documentation/DocBook/v4l/v4l2.xml3
-rw-r--r--Documentation/DocBook/v4l/vidioc-dqevent.xml124
-rw-r--r--Documentation/DocBook/v4l/vidioc-subscribe-event.xml104
4 files changed, 262 insertions, 0 deletions
diff --git a/Documentation/DocBook/v4l/dev-event.xml b/Documentation/DocBook/v4l/dev-event.xml
new file mode 100644
index 000000000000..be5a98fb4fab
--- /dev/null
+++ b/Documentation/DocBook/v4l/dev-event.xml
@@ -0,0 +1,31 @@
1 <title>Event Interface</title>
2
3 <para>The V4L2 event interface provides means for user to get
4 immediately notified on certain conditions taking place on a device.
5 This might include start of frame or loss of signal events, for
6 example.
7 </para>
8
9 <para>To receive events, the events the user is interested in first must
10 be subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an event is
11 subscribed, the events of subscribed types are dequeueable using the
12 &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using
13 VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type V4L2_EVENT_ALL may
14 be used to unsubscribe all the events the driver supports.</para>
15
16 <para>The event subscriptions and event queues are specific to file
17 handles. Subscribing an event on one file handle does not affect
18 other file handles.
19 </para>
20
21 <para>The information on dequeueable events is obtained by using select or
22 poll system calls on video devices. The V4L2 events use POLLPRI events on
23 poll system call and exceptions on select system call. </para>
24
25 <!--
26Local Variables:
27mode: sgml
28sgml-parent-document: "v4l2.sgml"
29indent-tabs-mode: nil
30End:
31 -->
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml
index 060105af49e5..9737243377a3 100644
--- a/Documentation/DocBook/v4l/v4l2.xml
+++ b/Documentation/DocBook/v4l/v4l2.xml
@@ -401,6 +401,7 @@ and discussions on the V4L mailing list.</revremark>
401 <section id="ttx"> &sub-dev-teletext; </section> 401 <section id="ttx"> &sub-dev-teletext; </section>
402 <section id="radio"> &sub-dev-radio; </section> 402 <section id="radio"> &sub-dev-radio; </section>
403 <section id="rds"> &sub-dev-rds; </section> 403 <section id="rds"> &sub-dev-rds; </section>
404 <section id="event"> &sub-dev-event; </section>
404 </chapter> 405 </chapter>
405 406
406 <chapter id="driver"> 407 <chapter id="driver">
@@ -426,6 +427,7 @@ and discussions on the V4L mailing list.</revremark>
426 &sub-cropcap; 427 &sub-cropcap;
427 &sub-dbg-g-chip-ident; 428 &sub-dbg-g-chip-ident;
428 &sub-dbg-g-register; 429 &sub-dbg-g-register;
430 &sub-dqevent;
429 &sub-encoder-cmd; 431 &sub-encoder-cmd;
430 &sub-enumaudio; 432 &sub-enumaudio;
431 &sub-enumaudioout; 433 &sub-enumaudioout;
@@ -467,6 +469,7 @@ and discussions on the V4L mailing list.</revremark>
467 &sub-reqbufs; 469 &sub-reqbufs;
468 &sub-s-hw-freq-seek; 470 &sub-s-hw-freq-seek;
469 &sub-streamon; 471 &sub-streamon;
472 &sub-subscribe-event;
470 <!-- End of ioctls. --> 473 <!-- End of ioctls. -->
471 &sub-mmap; 474 &sub-mmap;
472 &sub-munmap; 475 &sub-munmap;
diff --git a/Documentation/DocBook/v4l/vidioc-dqevent.xml b/Documentation/DocBook/v4l/vidioc-dqevent.xml
new file mode 100644
index 000000000000..eb45c1695d8c
--- /dev/null
+++ b/Documentation/DocBook/v4l/vidioc-dqevent.xml
@@ -0,0 +1,124 @@
1<refentry id="vidioc-dqevent">
2 <refmeta>
3 <refentrytitle>ioctl VIDIOC_DQEVENT</refentrytitle>
4 &manvol;
5 </refmeta>
6
7 <refnamediv>
8 <refname>VIDIOC_DQEVENT</refname>
9 <refpurpose>Dequeue event</refpurpose>
10 </refnamediv>
11
12 <refsynopsisdiv>
13 <funcsynopsis>
14 <funcprototype>
15 <funcdef>int <function>ioctl</function></funcdef>
16 <paramdef>int <parameter>fd</parameter></paramdef>
17 <paramdef>int <parameter>request</parameter></paramdef>
18 <paramdef>struct v4l2_event
19*<parameter>argp</parameter></paramdef>
20 </funcprototype>
21 </funcsynopsis>
22 </refsynopsisdiv>
23
24 <refsect1>
25 <title>Arguments</title>
26
27 <variablelist>
28 <varlistentry>
29 <term><parameter>fd</parameter></term>
30 <listitem>
31 <para>&fd;</para>
32 </listitem>
33 </varlistentry>
34 <varlistentry>
35 <term><parameter>request</parameter></term>
36 <listitem>
37 <para>VIDIOC_DQEVENT</para>
38 </listitem>
39 </varlistentry>
40 <varlistentry>
41 <term><parameter>argp</parameter></term>
42 <listitem>
43 <para></para>
44 </listitem>
45 </varlistentry>
46 </variablelist>
47 </refsect1>
48
49 <refsect1>
50 <title>Description</title>
51
52 <para>Dequeue an event from a video device. No input is required
53 for this ioctl. All the fields of the &v4l2-event; structure are
54 filled by the driver. The file handle will also receive exceptions
55 which the application may get by e.g. using the select system
56 call.</para>
57
58 <table frame="none" pgwide="1" id="v4l2-event">
59 <title>struct <structname>v4l2_event</structname></title>
60 <tgroup cols="4">
61 &cs-str;
62 <tbody valign="top">
63 <row>
64 <entry>__u32</entry>
65 <entry><structfield>type</structfield></entry>
66 <entry></entry>
67 <entry>Type of the event.</entry>
68 </row>
69 <row>
70 <entry>union</entry>
71 <entry><structfield>u</structfield></entry>
72 <entry></entry>
73 <entry></entry>
74 </row>
75 <row>
76 <entry></entry>
77 <entry>__u8</entry>
78 <entry><structfield>data</structfield>[64]</entry>
79 <entry>Event data. Defined by the event type. The union
80 should be used to define easily accessible type for
81 events.</entry>
82 </row>
83 <row>
84 <entry>__u32</entry>
85 <entry><structfield>pending</structfield></entry>
86 <entry></entry>
87 <entry>Number of pending events excluding this one.</entry>
88 </row>
89 <row>
90 <entry>__u32</entry>
91 <entry><structfield>sequence</structfield></entry>
92 <entry></entry>
93 <entry>Event sequence number. The sequence number is
94 incremented for every subscribed event that takes place.
95 If sequence numbers are not contiguous it means that
96 events have been lost.
97 </entry>
98 </row>
99 <row>
100 <entry>struct timeval</entry>
101 <entry><structfield>timestamp</structfield></entry>
102 <entry></entry>
103 <entry>Event timestamp.</entry>
104 </row>
105 <row>
106 <entry>__u32</entry>
107 <entry><structfield>reserved</structfield>[9]</entry>
108 <entry></entry>
109 <entry>Reserved for future extensions. Drivers must set
110 the array to zero.</entry>
111 </row>
112 </tbody>
113 </tgroup>
114 </table>
115
116 </refsect1>
117</refentry>
118<!--
119Local Variables:
120mode: sgml
121sgml-parent-document: "v4l2.sgml"
122indent-tabs-mode: nil
123End:
124-->
diff --git a/Documentation/DocBook/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/v4l/vidioc-subscribe-event.xml
new file mode 100644
index 000000000000..71ab88cb76b3
--- /dev/null
+++ b/Documentation/DocBook/v4l/vidioc-subscribe-event.xml
@@ -0,0 +1,104 @@
1<refentry id="vidioc-subscribe-event">
2 <refmeta>
3 <refentrytitle>ioctl VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT</refentrytitle>
4 &manvol;
5 </refmeta>
6
7 <refnamediv>
8 <refname>VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT</refname>
9 <refpurpose>Subscribe or unsubscribe event</refpurpose>
10 </refnamediv>
11
12 <refsynopsisdiv>
13 <funcsynopsis>
14 <funcprototype>
15 <funcdef>int <function>ioctl</function></funcdef>
16 <paramdef>int <parameter>fd</parameter></paramdef>
17 <paramdef>int <parameter>request</parameter></paramdef>
18 <paramdef>struct v4l2_event_subscription
19*<parameter>argp</parameter></paramdef>
20 </funcprototype>
21 </funcsynopsis>
22 </refsynopsisdiv>
23
24 <refsect1>
25 <title>Arguments</title>
26
27 <variablelist>
28 <varlistentry>
29 <term><parameter>fd</parameter></term>
30 <listitem>
31 <para>&fd;</para>
32 </listitem>
33 </varlistentry>
34 <varlistentry>
35 <term><parameter>request</parameter></term>
36 <listitem>
37 <para>VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT</para>
38 </listitem>
39 </varlistentry>
40 <varlistentry>
41 <term><parameter>argp</parameter></term>
42 <listitem>
43 <para></para>
44 </listitem>
45 </varlistentry>
46 </variablelist>
47 </refsect1>
48
49 <refsect1>
50 <title>Description</title>
51
52 <para>Subscribe or unsubscribe V4L2 event. Subscribed events are
53 dequeued by using the &VIDIOC-DQEVENT; ioctl.</para>
54
55 <table frame="none" pgwide="1" id="v4l2-event-subscription">
56 <title>struct <structname>v4l2_event_subscription</structname></title>
57 <tgroup cols="3">
58 &cs-str;
59 <tbody valign="top">
60 <row>
61 <entry>__u32</entry>
62 <entry><structfield>type</structfield></entry>
63 <entry>Type of the event.</entry>
64 </row>
65 <row>
66 <entry>__u32</entry>
67 <entry><structfield>reserved</structfield>[7]</entry>
68 <entry>Reserved for future extensions. Drivers and applications
69 must set the array to zero.</entry>
70 </row>
71 </tbody>
72 </tgroup>
73 </table>
74
75 <table frame="none" pgwide="1" id="event-type">
76 <title>Event Types</title>
77 <tgroup cols="3">
78 &cs-def;
79 <tbody valign="top">
80 <row>
81 <entry><constant>V4L2_EVENT_ALL</constant></entry>
82 <entry>0</entry>
83 <entry>All events. V4L2_EVENT_ALL is valid only for
84 VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once.
85 </entry>
86 </row>
87 <row>
88 <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
89 <entry>0x08000000</entry>
90 <entry>Base event number for driver-private events.</entry>
91 </row>
92 </tbody>
93 </tgroup>
94 </table>
95
96 </refsect1>
97</refentry>
98<!--
99Local Variables:
100mode: sgml
101sgml-parent-document: "v4l2.sgml"
102indent-tabs-mode: nil
103End:
104-->
generated by cgit v1.2.2 (git 2.25.0) at 2025-09-06 02:02:47 -0400
ytes is passed. So, the volume update sequence * is something like: * * fd = open("/dev/my_volume"); * ioctl(fd, UBI_IOCVOLUP, &image_size); * write(fd, buf, image_size); * close(fd); * * Logical eraseblock erase * ~~~~~~~~~~~~~~~~~~~~~~~~ * * To erase a logical eraseblock, the %UBI_IOCEBER ioctl command of the * corresponding UBI volume character device should be used. This command * unmaps the requested logical eraseblock, makes sure the corresponding * physical eraseblock is successfully erased, and returns. * * Atomic logical eraseblock change * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * * Atomic logical eraseblock change operation is called using the %UBI_IOCEBCH * ioctl command of the corresponding UBI volume character device. A pointer to * a &struct ubi_leb_change_req object has to be passed to the ioctl. Then the * user is expected to write the requested amount of bytes (similarly to what * should be done in case of the "volume update" ioctl). * * Logical eraseblock map * ~~~~~~~~~~~~~~~~~~~~~ * * To map a logical eraseblock to a physical eraseblock, the %UBI_IOCEBMAP * ioctl command should be used. A pointer to a &struct ubi_map_req object is * expected to be passed. The ioctl maps the requested logical eraseblock to * a physical eraseblock and returns. Only non-mapped logical eraseblocks can * be mapped. If the logical eraseblock specified in the request is already * mapped to a physical eraseblock, the ioctl fails and returns error. * * Logical eraseblock unmap * ~~~~~~~~~~~~~~~~~~~~~~~~ * * To unmap a logical eraseblock to a physical eraseblock, the %UBI_IOCEBUNMAP * ioctl command should be used. The ioctl unmaps the logical eraseblocks, * schedules corresponding physical eraseblock for erasure, and returns. Unlike * the "LEB erase" command, it does not wait for the physical eraseblock being * erased. Note, the side effect of this is that if an unclean reboot happens * after the unmap ioctl returns, you may find the LEB mapped again to the same * physical eraseblock after the UBI is run again. * * Check if logical eraseblock is mapped * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * * To check if a logical eraseblock is mapped to a physical eraseblock, the * %UBI_IOCEBISMAP ioctl command should be used. It returns %0 if the LEB is * not mapped, and %1 if it is mapped. * * Set an UBI volume property * ~~~~~~~~~~~~~~~~~~~~~~~~~ * * To set an UBI volume property the %UBI_IOCSETPROP ioctl command should be * used. A pointer to a &struct ubi_set_vol_prop_req object is expected to be * passed. The object describes which property should be set, and to which value * it should be set. */ /* * When a new UBI volume or UBI device is created, users may either specify the * volume/device number they want to create or to let UBI automatically assign * the number using these constants. */ #define UBI_VOL_NUM_AUTO (-1) #define UBI_DEV_NUM_AUTO (-1) /* Maximum volume name length */ #define UBI_MAX_VOLUME_NAME 127 /* ioctl commands of UBI character devices */ #define UBI_IOC_MAGIC 'o' /* Create an UBI volume */ #define UBI_IOCMKVOL _IOW(UBI_IOC_MAGIC, 0, struct ubi_mkvol_req) /* Remove an UBI volume */ #define UBI_IOCRMVOL _IOW(UBI_IOC_MAGIC, 1, __s32) /* Re-size an UBI volume */ #define UBI_IOCRSVOL _IOW(UBI_IOC_MAGIC, 2, struct ubi_rsvol_req) /* Re-name volumes */ #define UBI_IOCRNVOL _IOW(UBI_IOC_MAGIC, 3, struct ubi_rnvol_req) /* ioctl commands of the UBI control character device */ #define UBI_CTRL_IOC_MAGIC 'o' /* Attach an MTD device */ #define UBI_IOCATT _IOW(UBI_CTRL_IOC_MAGIC, 64, struct ubi_attach_req) /* Detach an MTD device */ #define UBI_IOCDET _IOW(UBI_CTRL_IOC_MAGIC, 65, __s32) /* ioctl commands of UBI volume character devices */ #define UBI_VOL_IOC_MAGIC 'O' /* Start UBI volume update */ #define UBI_IOCVOLUP _IOW(UBI_VOL_IOC_MAGIC, 0, __s64) /* LEB erasure command, used for debugging, disabled by default */ #define UBI_IOCEBER _IOW(UBI_VOL_IOC_MAGIC, 1, __s32) /* Atomic LEB change command */ #define UBI_IOCEBCH _IOW(UBI_VOL_IOC_MAGIC, 2, __s32) /* Map LEB command */ #define UBI_IOCEBMAP _IOW(UBI_VOL_IOC_MAGIC, 3, struct ubi_map_req) /* Unmap LEB command */ #define UBI_IOCEBUNMAP _IOW(UBI_VOL_IOC_MAGIC, 4, __s32) /* Check if LEB is mapped command */ #define UBI_IOCEBISMAP _IOR(UBI_VOL_IOC_MAGIC, 5, __s32) /* Set an UBI volume property */ #define UBI_IOCSETVOLPROP _IOW(UBI_VOL_IOC_MAGIC, 6, \ struct ubi_set_vol_prop_req) /* Maximum MTD device name length supported by UBI */ #define MAX_UBI_MTD_NAME_LEN 127 /* Maximum amount of UBI volumes that can be re-named at one go */ #define UBI_MAX_RNVOL 32 /* * UBI volume type constants. * * @UBI_DYNAMIC_VOLUME: dynamic volume * @UBI_STATIC_VOLUME: static volume */ enum { UBI_DYNAMIC_VOLUME = 3, UBI_STATIC_VOLUME = 4, }; /* * UBI set volume property ioctl constants. * * @UBI_VOL_PROP_DIRECT_WRITE: allow (any non-zero value) or disallow (value 0) * user to directly write and erase individual * eraseblocks on dynamic volumes */ enum { UBI_VOL_PROP_DIRECT_WRITE = 1, }; /** * struct ubi_attach_req - attach MTD device request. * @ubi_num: UBI device number to create * @mtd_num: MTD device number to attach * @vid_hdr_offset: VID header offset (use defaults if %0) * @padding: reserved for future, not used, has to be zeroed * * This data structure is used to specify MTD device UBI has to attach and the * parameters it has to use. The number which should be assigned to the new UBI * device is passed in @ubi_num. UBI may automatically assign the number if * @UBI_DEV_NUM_AUTO is passed. In this case, the device number is returned in * @ubi_num. * * Most applications should pass %0 in @vid_hdr_offset to make UBI use default * offset of the VID header within physical eraseblocks. The default offset is * the next min. I/O unit after the EC header. For example, it will be offset * 512 in case of a 512 bytes page NAND flash with no sub-page support. Or * it will be 512 in case of a 2KiB page NAND flash with 4 512-byte sub-pages. * * But in rare cases, if this optimizes things, the VID header may be placed to * a different offset. For example, the boot-loader might do things faster if * the VID header sits at the end of the first 2KiB NAND page with 4 sub-pages. * As the boot-loader would not normally need to read EC headers (unless it * needs UBI in RW mode), it might be faster to calculate ECC. This is weird * example, but it real-life example. So, in this example, @vid_hdr_offer would * be 2KiB-64 bytes = 1984. Note, that this position is not even 512-bytes * aligned, which is OK, as UBI is clever enough to realize this is 4th * sub-page of the first page and add needed padding. */ struct ubi_attach_req { __s32 ubi_num; __s32 mtd_num; __s32 vid_hdr_offset; __s8 padding[12]; }; /** * struct ubi_mkvol_req - volume description data structure used in * volume creation requests. * @vol_id: volume number * @alignment: volume alignment * @bytes: volume size in bytes * @vol_type: volume type (%UBI_DYNAMIC_VOLUME or %UBI_STATIC_VOLUME) * @padding1: reserved for future, not used, has to be zeroed * @name_len: volume name length * @padding2: reserved for future, not used, has to be zeroed * @name: volume name * * This structure is used by user-space programs when creating new volumes. The * @used_bytes field is only necessary when creating static volumes. * * The @alignment field specifies the required alignment of the volume logical * eraseblock. This means, that the size of logical eraseblocks will be aligned * to this number, i.e., * (UBI device logical eraseblock size) mod (@alignment) = 0. * * To put it differently, the logical eraseblock of this volume may be slightly * shortened in order to make it properly aligned. The alignment has to be * multiple of the flash minimal input/output unit, or %1 to utilize the entire * available space of logical eraseblocks. * * The @alignment field may be useful, for example, when one wants to maintain * a block device on top of an UBI volume. In this case, it is desirable to fit * an integer number of blocks in logical eraseblocks of this UBI volume. With * alignment it is possible to update this volume using plane UBI volume image * BLOBs, without caring about how to properly align them. */ struct ubi_mkvol_req { __s32 vol_id; __s32 alignment; __s64 bytes; __s8 vol_type; __s8 padding1; __s16 name_len; __s8 padding2[4]; char name[UBI_MAX_VOLUME_NAME + 1]; } __packed; /** * struct ubi_rsvol_req - a data structure used in volume re-size requests. * @vol_id: ID of the volume to re-size * @bytes: new size of the volume in bytes * * Re-sizing is possible for both dynamic and static volumes. But while dynamic * volumes may be re-sized arbitrarily, static volumes cannot be made to be * smaller than the number of bytes they bear. To arbitrarily shrink a static * volume, it must be wiped out first (by means of volume update operation with * zero number of bytes). */ struct ubi_rsvol_req { __s64 bytes; __s32 vol_id; } __packed; /** * struct ubi_rnvol_req - volumes re-name request. * @count: count of volumes to re-name * @padding1: reserved for future, not used, has to be zeroed * @vol_id: ID of the volume to re-name * @name_len: name length * @padding2: reserved for future, not used, has to be zeroed * @name: new volume name * * UBI allows to re-name up to %32 volumes at one go. The count of volumes to * re-name is specified in the @count field. The ID of the volumes to re-name * and the new names are specified in the @vol_id and @name fields. * * The UBI volume re-name operation is atomic, which means that should power cut * happen, the volumes will have either old name or new name. So the possible * use-cases of this command is atomic upgrade. Indeed, to upgrade, say, volumes * A and B one may create temporary volumes %A1 and %B1 with the new contents, * then atomically re-name A1->A and B1->B, in which case old %A and %B will * be removed. * * If it is not desirable to remove old A and B, the re-name request has to * contain 4 entries: A1->A, A->A1, B1->B, B->B1, in which case old A1 and B1 * become A and B, and old A and B will become A1 and B1. * * It is also OK to request: A1->A, A1->X, B1->B, B->Y, in which case old A1 * and B1 become A and B, and old A and B become X and Y. * * In other words, in case of re-naming into an existing volume name, the * existing volume is removed, unless it is re-named as well at the same * re-name request. */ struct ubi_rnvol_req { __s32 count; __s8 padding1[12]; struct { __s32 vol_id; __s16 name_len; __s8 padding2[2]; char name[UBI_MAX_VOLUME_NAME + 1]; } ents[UBI_MAX_RNVOL]; } __packed; /** * struct ubi_leb_change_req - a data structure used in atomic LEB change * requests. * @lnum: logical eraseblock number to change * @bytes: how many bytes will be written to the logical eraseblock * @dtype: pass "3" for better compatibility with old kernels * @padding: reserved for future, not used, has to be zeroed * * The @dtype field used to inform UBI about what kind of data will be written * to the LEB: long term (value 1), short term (value 2), unknown (value 3). * UBI tried to pick a PEB with lower erase counter for short term data and a * PEB with higher erase counter for long term data. But this was not really * used because users usually do not know this and could easily mislead UBI. We * removed this feature in May 2012. UBI currently just ignores the @dtype * field. But for better compatibility with older kernels it is recommended to * set @dtype to 3 (unknown). */ struct ubi_leb_change_req { __s32 lnum; __s32 bytes; __s8 dtype; /* obsolete, do not use! */ __s8 padding[7]; } __packed; /** * struct ubi_map_req - a data structure used in map LEB requests. * @dtype: pass "3" for better compatibility with old kernels * @lnum: logical eraseblock number to unmap * @padding: reserved for future, not used, has to be zeroed */ struct ubi_map_req { __s32 lnum; __s8 dtype; /* obsolete, do not use! */ __s8 padding[3]; } __packed; /** * struct ubi_set_vol_prop_req - a data structure used to set an UBI volume * property. * @property: property to set (%UBI_VOL_PROP_DIRECT_WRITE) * @padding: reserved for future, not used, has to be zeroed * @value: value to set */ struct ubi_set_vol_prop_req { __u8 property; __u8 padding[7]; __u64 value; } __packed; #endif /* __UBI_USER_H__ */
generated by cgit v1.2.2 (git 2.25.0) at 2025-09-06 02:02:47 -0400