| Message ID | 20260828080757.1160553-1-gehariprasath@ti.com |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-ti,scarthgap] ti-vendor-kernel-headers: add recipe for TI-only dma-heap.h ioctl | expand |
meta-ti / na / 20260828080757.1160553-1-gehariprasath PRC Results: PASS ========================================================= check-yocto-patches: PASS ========================================================= Patches ---------------------------------------- All patches passed ========================================================= apply-yocto-patch: PASS ========================================================= scarthgap ===================== Summary: - Patch Series: [meta-ti][scarthgap][PATCH] ti-vendor-kernel-headers: add recipe for TI-only dma-heap.h ioctl - Submitter: From: Hari Prasath Gujulan Elango <gehariprasath@ti.com> - Date: Date: Fri, 28 Aug 2026 13:37:57 +0530 - Num Patches: 1 - Mailing List (public inbox) Commit SHA: 6cd9de66050632ece1bcbd63cdb66b395cc0ce95 Applied to: - Repository: lcpd-prc-meta-ti - Base Branch: scarthgap-wip - Commit Author: LCPD Automation Script <lcpdbld@list.ti.com> - Commit Subject: CI/CD Auto-Merger: cicd.scarthgap.202608190946 - Commit SHA: ef43a90c91d5a9754b2f28f09debd553fbc6a2d5 Patches ---------------------------------------- All patches applied ========================================================= check-yocto-repo: PASS ========================================================= scarthgap ===================== PASS ========================================================= yocto-check-layers: PASS ========================================================= scarthgap - PASS ===================== All checks passed
On 8/28/26 3:07 AM, Hari Prasath Gujulan Elango wrote: > The TI vendor kernel's dma-heap.h carries DMA_HEAP_IOCTL_EXPORT in > downstream.The standard header provided by linux-libc-headers' wouldn't Add a space after end of sentences "." > have the custom changes.Copy it straight from the kernel's staged > source tree (STAGING_KERNEL_DIR)into a separate /usr/include/ti/linux > path instead, for userspace code that needs it. > > Signed-off-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> > --- > .../ti-vendor-kernel-headers_1.0.bb | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > create mode 100644 meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb > > diff --git a/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb > new file mode 100644 > index 000000000..bf7dcc3a5 > --- /dev/null > +++ b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb > @@ -0,0 +1,17 @@ > +SUMMARY = "TI vendor kernel uapi headers not present in mainline linux-libc-headers" > +DESCRIPTION = "Copies select uapi headers straight from the TI vendor kernel source \ s/uapi/UAPI as it is acronym (Userspace Application Programing Interface) > +tree into a TI-specific include path (/usr/include/ti/linux), for userspace code \ > +that needs them but can't rely on linux-libc-headers carrying TI-only additions." > +LICENSE = "GPL-2.0-only" > +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" > + > +PACKAGE_ARCH = "${MACHINE_ARCH}" > + > +do_configure[depends] += "virtual/kernel:do_shared_workdir" > +do_install[depends] += "virtual/kernel:do_shared_workdir" > + > +do_install() { > + install -d ${D}${includedir}/ti/linux > + install -m 0644 ${STAGING_KERNEL_DIR}/include/uapi/linux/dma-heap.h ${D}${includedir}/ti/linux/dma-heap.h > +} > + I don't have an huge issue with this series, but let's make sure we know the alternatives first. If only a couple applications need this header, they can bundle a copy of the DMA_HEAP_IOCTL_EXPORT definition inside their own source. That does have the downside of if the definition in kernel changes the application will not get the update automatically when rebuilt against the new kernel. But this is already the big issue with using custom UAPI like this in the first place, if the kernel gets updated the applications can stop working. The upstream kernel never breaks existing UAPI, but our downstream can and does. As said, this patch looks fine as-is, just something to think about. Andrew
On 8/28/2026 9:42 AM, Andrew Davis wrote: > On 8/28/26 3:07 AM, Hari Prasath Gujulan Elango wrote: >> The TI vendor kernel's dma-heap.h carries DMA_HEAP_IOCTL_EXPORT in >> downstream.The standard header provided by linux-libc-headers' wouldn't > > Add a space after end of sentences "." > >> have the custom changes.Copy it straight from the kernel's staged >> source tree (STAGING_KERNEL_DIR)into a separate /usr/include/ti/linux >> path instead, for userspace code that needs it. >> >> Signed-off-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> >> --- >> .../ti-vendor-kernel-headers_1.0.bb | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> create mode 100644 >> meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb >> >> diff --git >> a/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb >> new file mode 100644 >> index 000000000..bf7dcc3a5 >> --- /dev/null >> +++ >> b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb >> @@ -0,0 +1,17 @@ >> +SUMMARY = "TI vendor kernel uapi headers not present in mainline >> linux-libc-headers" >> +DESCRIPTION = "Copies select uapi headers straight from the TI vendor >> kernel source \ > > s/uapi/UAPI as it is acronym (Userspace Application Programing Interface) > >> +tree into a TI-specific include path (/usr/include/ti/linux), for >> userspace code \ >> +that needs them but can't rely on linux-libc-headers carrying TI-only >> additions." >> +LICENSE = "GPL-2.0-only" >> +LIC_FILES_CHKSUM = >> "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" >> + >> +PACKAGE_ARCH = "${MACHINE_ARCH}" >> + >> +do_configure[depends] += "virtual/kernel:do_shared_workdir" >> +do_install[depends] += "virtual/kernel:do_shared_workdir" >> + >> +do_install() { >> + install -d ${D}${includedir}/ti/linux >> + install -m 0644 >> ${STAGING_KERNEL_DIR}/include/uapi/linux/dma-heap.h >> ${D}${includedir}/ti/linux/dma-heap.h >> +} >> + > > I don't have an huge issue with this series, but let's make sure we know > the alternatives > first. If only a couple applications need this header, they can bundle a > copy of the > DMA_HEAP_IOCTL_EXPORT definition inside their own source. Hari, is this an acceptable solution? Have the app bundle the header instead of trying to do this copying? > That does have the downside of if the definition in kernel changes the > application will not > get the update automatically when rebuilt against the new kernel. But > this is already the big > issue with using custom UAPI like this in the first place, if the kernel > gets updated the > applications can stop working. The upstream kernel never breaks existing > UAPI, but our > downstream can and does. > > As said, this patch looks fine as-is, just something to think about. > > Andrew
Hello Andrew, Thanks for the reviews. On 8/28/2026 8:12 PM, Andrew Davis wrote: > On 8/28/26 3:07 AM, Hari Prasath Gujulan Elango wrote: >> The TI vendor kernel's dma-heap.h carries DMA_HEAP_IOCTL_EXPORT in >> downstream.The standard header provided by linux-libc-headers' wouldn't > > Add a space after end of sentences "." ACK > >> have the custom changes.Copy it straight from the kernel's staged >> source tree (STAGING_KERNEL_DIR)into a separate /usr/include/ti/linux >> path instead, for userspace code that needs it. >> >> Signed-off-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> >> --- >> .../ti-vendor-kernel-headers_1.0.bb | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> create mode 100644 meta-ti-bsp/recipes-kernel/ti-vendor-kernel- >> headers/ti-vendor-kernel-headers_1.0.bb >> >> diff --git a/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti- >> vendor-kernel-headers_1.0.bb b/meta-ti-bsp/recipes-kernel/ti-vendor- >> kernel-headers/ti-vendor-kernel-headers_1.0.bb >> new file mode 100644 >> index 000000000..bf7dcc3a5 >> --- /dev/null >> +++ b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor- >> kernel-headers_1.0.bb >> @@ -0,0 +1,17 @@ >> +SUMMARY = "TI vendor kernel uapi headers not present in mainline >> linux-libc-headers" >> +DESCRIPTION = "Copies select uapi headers straight from the TI vendor >> kernel source \ > > s/uapi/UAPI as it is acronym (Userspace Application Programing Interface) > ACK >> +tree into a TI-specific include path (/usr/include/ti/linux), for >> userspace code \ >> +that needs them but can't rely on linux-libc-headers carrying TI-only >> additions." >> +LICENSE = "GPL-2.0-only" >> +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0- >> only;md5=801f80980d171dd6425610833a22dbe6" >> + >> +PACKAGE_ARCH = "${MACHINE_ARCH}" >> + >> +do_configure[depends] += "virtual/kernel:do_shared_workdir" >> +do_install[depends] += "virtual/kernel:do_shared_workdir" >> + >> +do_install() { >> + install -d ${D}${includedir}/ti/linux >> + install -m 0644 ${STAGING_KERNEL_DIR}/include/uapi/linux/dma- >> heap.h ${D}${includedir}/ti/linux/dma-heap.h >> +} >> + > > I don't have an huge issue with this series, but let's make sure we know > the alternatives > first. If only a couple applications need this header, they can bundle a > copy of the > DMA_HEAP_IOCTL_EXPORT definition inside their own source. > > That does have the downside of if the definition in kernel changes the > application will not > get the update automatically when rebuilt against the new kernel. But > this is already the big > issue with using custom UAPI like this in the first place, if the kernel > gets updated the > applications can stop working. The upstream kernel never breaks existing > UAPI, but our > downstream can and does. > > As said, this patch looks fine as-is, just something to think about. We could certainly explore this option, but as you have highlighted syncing that with the kernel would be a challenge. I need more time to discuss with the concerned team how best we can manage this.I would say let's take this patch in considering the SDK release for Ford. Regards, Hari > > Andrew
Hello Ryan, On 8/28/2026 8:42 PM, Ryan Eatmon wrote: > > > On 8/28/2026 9:42 AM, Andrew Davis wrote: >> On 8/28/26 3:07 AM, Hari Prasath Gujulan Elango wrote: >>> The TI vendor kernel's dma-heap.h carries DMA_HEAP_IOCTL_EXPORT in >>> downstream.The standard header provided by linux-libc-headers' wouldn't >> >> Add a space after end of sentences "." >> >>> have the custom changes.Copy it straight from the kernel's staged >>> source tree (STAGING_KERNEL_DIR)into a separate /usr/include/ti/linux >>> path instead, for userspace code that needs it. >>> >>> Signed-off-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> >>> --- >>> .../ti-vendor-kernel-headers_1.0.bb | 17 +++++++++++++++++ >>> 1 file changed, 17 insertions(+) >>> create mode 100644 meta-ti-bsp/recipes-kernel/ti-vendor-kernel- >>> headers/ti-vendor-kernel-headers_1.0.bb >>> >>> diff --git a/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti- >>> vendor-kernel-headers_1.0.bb b/meta-ti-bsp/recipes-kernel/ti-vendor- >>> kernel-headers/ti-vendor-kernel-headers_1.0.bb >>> new file mode 100644 >>> index 000000000..bf7dcc3a5 >>> --- /dev/null >>> +++ b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor- >>> kernel-headers_1.0.bb >>> @@ -0,0 +1,17 @@ >>> +SUMMARY = "TI vendor kernel uapi headers not present in mainline >>> linux-libc-headers" >>> +DESCRIPTION = "Copies select uapi headers straight from the TI >>> vendor kernel source \ >> >> s/uapi/UAPI as it is acronym (Userspace Application Programing Interface) >> >>> +tree into a TI-specific include path (/usr/include/ti/linux), for >>> userspace code \ >>> +that needs them but can't rely on linux-libc-headers carrying TI- >>> only additions." >>> +LICENSE = "GPL-2.0-only" >>> +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0- >>> only;md5=801f80980d171dd6425610833a22dbe6" >>> + >>> +PACKAGE_ARCH = "${MACHINE_ARCH}" >>> + >>> +do_configure[depends] += "virtual/kernel:do_shared_workdir" >>> +do_install[depends] += "virtual/kernel:do_shared_workdir" >>> + >>> +do_install() { >>> + install -d ${D}${includedir}/ti/linux >>> + install -m 0644 ${STAGING_KERNEL_DIR}/include/uapi/linux/dma- >>> heap.h ${D}${includedir}/ti/linux/dma-heap.h >>> +} >>> + >> >> I don't have an huge issue with this series, but let's make sure we >> know the alternatives >> first. If only a couple applications need this header, they can bundle >> a copy of the >> DMA_HEAP_IOCTL_EXPORT definition inside their own source. > > Hari, is this an acceptable solution? Have the app bundle the header > instead of trying to do this copying? > We don't have the time to explore this option now. I will talk to them and see if this can be done, but as Highlighted by Andrew below, syncing the changes in the kernel with the application would need to be taken care. Regards, Hari > >> That does have the downside of if the definition in kernel changes the >> application will not >> get the update automatically when rebuilt against the new kernel. But >> this is already the big >> issue with using custom UAPI like this in the first place, if the >> kernel gets updated the >> applications can stop working. The upstream kernel never breaks >> existing UAPI, but our >> downstream can and does. >> >> As said, this patch looks fine as-is, just something to think about. >> >> Andrew >
diff --git a/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb new file mode 100644 index 000000000..bf7dcc3a5 --- /dev/null +++ b/meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb @@ -0,0 +1,17 @@ +SUMMARY = "TI vendor kernel uapi headers not present in mainline linux-libc-headers" +DESCRIPTION = "Copies select uapi headers straight from the TI vendor kernel source \ +tree into a TI-specific include path (/usr/include/ti/linux), for userspace code \ +that needs them but can't rely on linux-libc-headers carrying TI-only additions." +LICENSE = "GPL-2.0-only" +LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0-only;md5=801f80980d171dd6425610833a22dbe6" + +PACKAGE_ARCH = "${MACHINE_ARCH}" + +do_configure[depends] += "virtual/kernel:do_shared_workdir" +do_install[depends] += "virtual/kernel:do_shared_workdir" + +do_install() { + install -d ${D}${includedir}/ti/linux + install -m 0644 ${STAGING_KERNEL_DIR}/include/uapi/linux/dma-heap.h ${D}${includedir}/ti/linux/dma-heap.h +} +
The TI vendor kernel's dma-heap.h carries DMA_HEAP_IOCTL_EXPORT in downstream.The standard header provided by linux-libc-headers' wouldn't have the custom changes.Copy it straight from the kernel's staged source tree (STAGING_KERNEL_DIR)into a separate /usr/include/ti/linux path instead, for userspace code that needs it. Signed-off-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com> --- .../ti-vendor-kernel-headers_1.0.bb | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 meta-ti-bsp/recipes-kernel/ti-vendor-kernel-headers/ti-vendor-kernel-headers_1.0.bb