From: "Carlos Rafael Giani" <crg7475@mailbox.org>
To: meta-freescale <meta-freescale@yoctoproject.org>
Subject: linux-imx-headers and ioctl mismatches
Date: Fri, 10 Apr 2020 12:12:57 +0200 [thread overview]
Message-ID: <88da2816-ac64-512c-9f0f-a99c0fd6d0d1@mailbox.org> (raw)
The linux-imx-headers recipe gathers certain headers from the kernel
source so that other recipes which do access these headers don't have to
mark the entire kernel as a dependency.
However, if a platform doesn't actually use linux-imx as its kernel, or
at least uses a kernel release version that differs from that of
linux-imx, ioctl mismatches can occur.
Current example: linux-imx is at version 4.19 , while linux-boundary is
at 4.14. The DMA_BUF_IOCTL_PHYS ioctl is defined in the uapi/dma-buf.h
header in 4.14 as:
#define DMA_BUF_IOCTL_PHYS _IOW(DMA_BUF_BASE, 1, struct
dma_buf_phys)
but in 4.19 as:
#define DMA_BUF_IOCTL_PHYS _IOW(DMA_BUF_BASE, 10, struct
dma_buf_phys)
This leads to Boundary Devices platforms that can't handle this ioctl
properly because of the definition mismatch.
Just mentioning this here to discuss ideas. Perhaps it would make sense
to create a virtual/imx-headers package, or place the git repo URL as a
configurable variable?
next reply other threads:[~2020-04-10 10:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-10 10:12 Carlos Rafael Giani [this message]
2020-04-10 14:12 ` [meta-freescale] linux-imx-headers and ioctl mismatches Otavio Salvador
2020-04-10 14:20 ` Carlos Rafael Giani
2020-04-10 14:22 ` Otavio Salvador
[not found] ` <20200410144623.GA190348@p1g2>
2020-04-10 17:52 ` Otavio Salvador
2020-04-10 18:25 ` Kevin Lannen
2020-04-10 18:35 ` Otavio Salvador
2020-04-10 18:43 ` Kevin Lannen
2020-04-10 18:46 ` Otavio Salvador
2020-04-11 22:04 ` Andrey Zhizhikin
2020-04-11 23:52 ` Otavio Salvador
2020-04-11 10:32 ` Carlos Rafael Giani
2020-04-11 21:29 ` Otavio Salvador
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88da2816-ac64-512c-9f0f-a99c0fd6d0d1@mailbox.org \
--to=crg7475@mailbox.org \
--cc=meta-freescale@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).