From: Yunseong Kim <ysk@kzalloc.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [Question] __u32 rangehigh in struct v4l2_frequency_band to a higher frequencies value
Date: Sat, 6 Sep 2025 21:53:57 +0900 [thread overview]
Message-ID: <aaa302bb-b80f-4409-b274-e857d91f944a@kzalloc.com> (raw)
Hello Mauro,
I have a question regarding the data type used in struct v4l2_frequency_band,
Current definition:
struct v4l2_frequency_band {
...
__u32 rangehigh;
...
};
According to the official HackRF One documentation, frequency ranges up to 6 GHz
are supported. However, the rangehigh field is currently defined as __u32.
This means values above present 4294967294LL cannot be represented:
https://elixir.bootlin.com/linux/v6.17-rc4/source/drivers/media/usb/hackrf/hackrf.c#L67
For example, the HackRF hardware itself can go over 6 GHz, even though the
officially provided ANT700 antenna only supports up to 1.1 GHz:
https://greatscottgadgets.com/ant700/
With a different antenna, it seems feasible to use HackRF at 5.8 GHz related
discussion:
https://github.com/greatscottgadgets/hackrf/issues/1274
Would it make sense to extend struct v4l2_frequency_band to allow rangehigh
values up to at least 6000000000ULL? Or has there already been any discussion
about changing this field to a wider type for SDR devices that support
higher frequencies?
I tried searching the mailing list archives for discussions on
v4l2_frequency_band rangehigh but couldn’t find anything relevant:
https://www.mail-archive.com/search?a=1&l=linux-media%40vger.kernel.org&haswords=v4l2_frequency_band+rangehigh&x=0&y=0&from=&subject=&datewithin=1d&date=¬words=&o=relevance
Examples in drivers:
.rangehigh = 4294967294LL, /* max u32, hw goes over 7GHz */
Possible adjustment:
struct v4l2_frequency_band {
...
__u64 rangehigh;
...
};
.rangehigh = 6000000000ULL, /* 1 Hz to 6 GHz */
I’d appreciate your advice on whether extending this field (e.g., to __u64)
would be the right direction, or if there are other considerations in
the V4L2 framework.
Thank you very much for your time.
Best regards,
Yunseong Kim
reply other threads:[~2025-09-06 12:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=aaa302bb-b80f-4409-b274-e857d91f944a@kzalloc.com \
--to=ysk@kzalloc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.