* Re: [PATCH RFC] crypto/hkdf: Skip tests with keys too short in FIPS mode
From: Eric Biggers @ 2025-12-09 22:54 UTC (permalink / raw)
To: Li Tian
Cc: linux-kernel, linux-crypto, Herbert Xu, David S . Miller,
Vitaly Kuznetsov
In-Reply-To: <20251205113136.17920-1-litian@redhat.com>
On Fri, Dec 05, 2025 at 07:31:36PM +0800, Li Tian wrote:
> FIPS mode mandates the keys to _setkey should be longer than 14 bytes.
> It's up to the callers to not use keys too short.
>
> Signed-off-by: Li Tian <litian@redhat.com>
> ---
> crypto/hkdf.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/hkdf.c b/crypto/hkdf.c
> index 82d1b32ca6ce..73d318f3f677 100644
> --- a/crypto/hkdf.c
> +++ b/crypto/hkdf.c
> @@ -10,6 +10,7 @@
> #include <crypto/internal/hash.h>
> #include <crypto/sha2.h>
> #include <crypto/hkdf.h>
> +#include <linux/fips.h>
> #include <linux/module.h>
>
> /*
> @@ -462,7 +463,12 @@ static const struct hkdf_testvec hkdf_sha512_tv[] = {
> };
>
> static int hkdf_test(const char *shash, const struct hkdf_testvec *tv)
> -{ struct crypto_shash *tfm = NULL;
> +{
> + /* Skip the tests with keys too short in FIPS mode */
> + if (fips_enabled && (tv->salt_size < 112 / 8))
> + return 0;
> +
As I've explained before, in HKDF the secret is in the input keying
material, not the salt.
What problem are you trying to solve?
- Eric
^ permalink raw reply
* Re: [PULL REQUEST] i2c-for-6.19-rc1
From: pr-tracker-bot @ 2025-12-09 22:50 UTC (permalink / raw)
To: Wolfram Sang
Cc: Linus Torvalds, linux-i2c, linux-kernel, Bartosz Golaszewski,
Andi Shyti
In-Reply-To: <aTg1k4C4uGKMoiUG@shikoro>
The pull request you sent on Tue, 9 Dec 2025 23:43:31 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git tags/i2c-for-6.19-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c9b47175e9131118e6f221cc8fb81397d62e7c91
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v5 3/4] misc: fastrpc: Add support for new DSP IOVA formatting
From: Dmitry Baryshkov @ 2025-12-09 22:52 UTC (permalink / raw)
To: Kumari Pallavi
Cc: kpallavi, srini, amahesh, arnd, gregkh, robh, krzk+dt, conor+dt,
quic_bkumar, ekansh.gupta, linux-kernel, quic_chennak, dri-devel,
linux-arm-msm, devicetree, jingyi.wang, aiqun.yu, ktadakam
In-Reply-To: <18c6b95a-961d-4544-856d-7dc08f7d5d74@oss.qualcomm.com>
On Mon, Dec 08, 2025 at 12:56:18PM +0530, Kumari Pallavi wrote:
>
>
> On 12/6/2025 8:00 AM, Dmitry Baryshkov wrote:
> > On Tue, Dec 02, 2025 at 11:36:27AM +0530, Kumari Pallavi wrote:
> > > Implement the new IOVA formatting required by the DSP architecture change
> > > on Kaanapali SoC. Place the SID for DSP DMA transactions at bit 56 in the
> > > physical address. This placement is necessary for the DSPs to correctly
> > > identify streams and operate as intended.
> > > To address this, set SID position to bit 56 via OF matching on the fastrpc
> > > node; otherwise, default to legacy 32-bit placement.
> > > This change ensures consistent SID placement across DSPs.
> > >
> > > Signed-off-by: Kumari Pallavi <kumari.pallavi@oss.qualcomm.com>
> > > ---
> > > drivers/misc/fastrpc.c | 48 ++++++++++++++++++++++++++++++++++++------
> > > 1 file changed, 41 insertions(+), 7 deletions(-)
> > >
> > > @@ -789,7 +807,8 @@ static int fastrpc_map_attach(struct fastrpc_user *fl, int fd,
> > > map->dma_addr = sg_phys(map->table->sgl);
> > > } else {
> > > map->dma_addr = sg_dma_address(map->table->sgl);
> > > - map->dma_addr += ((u64)fl->sctx->sid << 32);
> > > + map->dma_addr += fastrpc_compute_sid_offset((u64)fl->sctx->sid,
> >
> > Drop type conversion. Hmm. Looking at it, would it be better:
> >
> > map->dma_addr = fastrpc_compute_dma_addr(fl->sctx, sg_dma_address(map->table->sgl))
> >
>
> Thanks for the suggestion. To confirm: you’re proposing that the call site
> use a single helper returning the final DMA address, i.e.
>
> map->dma_addr = fastrpc_compute_dma_addr(fl,
> sg_dma_address(map->table->sgl));
> I can implement fastrpc_compute_dma_addr() as a thin wrapper that internally
> calls our existing fastrpc_compute_sid_offset() and composes the
> consolidated IOVA (SID in upper bits, base DMA/PA in lower bits)
> ?
Yes
>
>
> > > + fl->cctx->soc_data->sid_pos);
> > > }
> > > for_each_sg(map->table->sgl, sgl, map->table->nents,
> > > sgl_index)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 21/24] KVM: arm64: Inject recorded guest interrupts
From: Oliver Upton @ 2025-12-09 22:52 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Paolo Bonzini, Jonathan Corbet, Russell King,
Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Mingwei Zhang, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Mark Rutland, Shuah Khan, Ganapatrao Kulkarni, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-perf-users,
linux-kselftest
In-Reply-To: <20251209205121.1871534-22-coltonlewis@google.com>
In no situation should KVM be injecting a "recorded" IRQ. The overflow
condition of the PMU is well defined in the architecture and we should
implement *exactly* that.
On Tue, Dec 09, 2025 at 08:51:18PM +0000, Colton Lewis wrote:
> +/**
> + * kvm_pmu_part_overflow_status() - Determine if any guest counters have overflowed
> + * @vcpu: Ponter to struct kvm_vcpu
> + *
> + * Determine if any guest counters have overflowed and therefore an
> + * IRQ needs to be injected into the guest.
> + *
> + * Return: True if there was an overflow, false otherwise
> + */
> +bool kvm_pmu_part_overflow_status(struct kvm_vcpu *vcpu)
> +{
> + struct arm_pmu *pmu = vcpu->kvm->arch.arm_pmu;
> + u64 mask = kvm_pmu_guest_counter_mask(pmu);
> + u64 pmovs = __vcpu_sys_reg(vcpu, PMOVSSET_EL0);
> + u64 pmint = read_pmintenset();
> + u64 pmcr = read_pmcr();
How do we know that the vPMU has been loaded on the CPU at this point?
> +
> + return (pmcr & ARMV8_PMU_PMCR_E) && (mask & pmovs & pmint);
> +}
I'd rather reuse kvm_pmu_overflow_status(), relying on the accessors to
abstract away the implementation / location of the guest PMU context.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v6 4/8] drm/panel: sw43408: Add enable/disable and reset functions
From: David Heidelberg @ 2025-12-09 22:51 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sumit Semwal, Casey Connolly, Neil Armstrong,
Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Marijn Suijten,
Dmitry Baryshkov, Vinod Koul, Petr Hodina, linux-arm-msm,
devicetree, linux-kernel, phone-devel, dri-devel
In-Reply-To: <lilbxguznfzupg2gpfb6xuj4ickffgtuwwlve5g4d22lzr3bsm@slkmhn4agvgr>
On 09/12/2025 23:37, Dmitry Baryshkov wrote:
> On Mon, Dec 08, 2025 at 10:41:57AM +0100, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> Introduce enable(), disable() and reset() functions.
>>
>> The enable() and disable() callbacks keep the symmetry in the commands
>> sent to the panel and also make a clearer distinction between panel
>> initialization and configuration.
>
> It's not just it. There is a difference between commands being sent in
> en/disable and prepare/unprepare.
Thanks, I didn't know. Is there good rule how to distinguish, which
command should go where?
>
>>
>> Splitting reset() from prepare() follows clean coding practices and lets
>> us potentially make reset optional in the future for flicker-less
>> takeover from a bootloader or framebuffer driver where the panel is
>> already configured.
>>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> ---
>> drivers/gpu/drm/panel/panel-lg-sw43408.c | 47 ++++++++++++++++++++++++--------
>> 1 file changed, 35 insertions(+), 12 deletions(-)
>>
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH RFC 2/2] drm: bridge: anx7625: implement minimal Type-C support
From: Dmitry Baryshkov @ 2025-12-09 22:51 UTC (permalink / raw)
To: Xin Ji
Cc: Heikki Krogerus, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <BY5PR04MB673939B585B2419534D48E77C7A2A@BY5PR04MB6739.namprd04.prod.outlook.com>
On Mon, Dec 08, 2025 at 07:37:30AM +0000, Xin Ji wrote:
> Hi Dmitry, I found there is another patch "Register USB Type-C mode switches" which provided by Pin-yen Lin <treapking@chromium.org>, but I didn't find it in the v6.18, is it obsolete?.
It has been posted 2 years ago, it has not been reposted since that
time, it targets a very specific ChromeOS usecase. I can't call it
obsolete, but it wasn't merged.
> https://patchew.org/linux/20221124102056.393220-1-treapking@chromium.org/20221124102056.393220-6-treapking@chromium.org/
>
> Thanks,
> Xin
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/6] x86/cpufreq: use host CPU policy for Turbo checking
From: Jason Andryuk @ 2025-12-09 22:31 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xenproject.org
Cc: Andrew Cooper, Roger Pau Monné
In-Reply-To: <27f467a9-a507-4832-850e-190aff8c04aa@suse.com>
On 2025-11-24 07:24, Jan Beulich wrote:
> There's no need to invoke CPUID yet another time - we assume symmetry
> anyway. With symmetry assumed, logging per-CPU also isn't very useful.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2025, #02)
From: Karthik Nayak @ 2025-12-09 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqfr9jjrci.fsf@gitster.g>
> * kn/ref-location (2025-12-01) 2 commits
> - refs: add GIT_REF_URI to specify reference backend and directory
> - refs: support obtaining ref_store for given dir
>
> A mechanism to specify what reference backend to use and store
> references in which directory is introduced, which would likely to
> be useful during ref migration.
>
> Comments?
> source: <20251201-kn-alternate-ref-dir-v3-0-c11b946bc2fa@gmail.com>
I'm currently on leave. While I do plan to work on this, my next version
which is based on Patricks recent review will be a bit delayed.
> * kn/fix-fetch-backfill-tag-with-batched-ref-updates (2025-11-21) 3 commits
> - fetch: fix failed batched updates skipping operations
> - fetch: fix non-conflicting tags not being committed
> - fetch: extract out reference committing logic
>
> "git fetch" that involves fetching tags, when a tag being fetched
> needs to overwrite existing one, failed to fetch other tags, which
> has been corrected.
>
> Expecting a (hopefully small and final) reroll.
> cf. <CAOLa=ZQ-O7V9qHbgeuQ78R1bHGDmGEM6fP5Kr9aC0AfvSF8MZA@mail.gmail.com>
> source: <20251121-fix-tags-not-fetching-v8-0-23b53a8a8334@gmail.com>
The only change needed from the last review was a typo. I think we should be
good as is.
Thanks!
^ permalink raw reply
* Re: [PATCH v5 20/24] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters
From: Oliver Upton @ 2025-12-09 22:45 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Paolo Bonzini, Jonathan Corbet, Russell King,
Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Mingwei Zhang, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Mark Rutland, Shuah Khan, Ganapatrao Kulkarni, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-perf-users,
linux-kselftest
In-Reply-To: <20251209205121.1871534-21-coltonlewis@google.com>
On Tue, Dec 09, 2025 at 08:51:17PM +0000, Colton Lewis wrote:
> Because ARM hardware is not yet capable of direct interrupt injection
PPI injection, it can do LPIs just fine.
> @@ -961,6 +964,12 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> */
> perf_event_overflow(event, &data, regs);
> }
> +
> + govf = pmovsr & kvm_pmu_guest_counter_mask(cpu_pmu);
> +
> + if (kvm_pmu_is_partitioned(cpu_pmu) && govf)
> + kvm_pmu_handle_guest_irq(govf);
> +
The state ownership of this whole interaction is very odd. I would much
rather that KVM have full ownership of the range of counters while the
guest is loaded. By that I mean the PMUv3 driver only clears overflows
on PMCs that it owns and KVM will do the same on the back of the IRQ.
Similarly, KVM should be leaving the "guest" range of counters in a
non-overflow condition at vcpu_put().
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v2] Support conditional deps using "depends on X if Y"
From: Graham Roff @ 2025-12-09 22:45 UTC (permalink / raw)
To: nathan
Cc: arnd, corbet, grahamr, linux-doc, linux-kbuild, linux-kernel,
nico, nsc
In-Reply-To: <20251205182334.GB3974306@ax162>
> Other than that, this seems reasonable to me. The actual code changes
> are small and the tests prove this works properly. I won't pick up v3
> until after 6.19-rc1 is out at the least.
Thanks Nathan! I will send out a v3 with the commit text updated, and the test
code changes you suggested.
> > > On the surface, the vast majority these become more readable using the
> > > 'if' syntax.
> >
> > Agreed, the question is whether a small improvement in
> > readability is worth the complexity of having multiple
> > ways of expressing the same thing.
>
> It is a tradeoff. Sometimes it is advantageous to increase the
> complexity in one place so other areas with more exposure to more people
> are simplified.
Exactly, a small code update here provides a much simpler syntax for
expressing a fairly common thing (conditional or optional dependencies).
It also makes the language more consistent since most other kconfig commands
accept a trailing "if <expr>" - I just assumed that "depends on" did as well
when first writing Kconfig files!
> >> +config TEST_COMPLEX
> >> + bool "Test complex conditional dependency"
> >> + depends on (FOO && BAR) if (FOO || BAR)
> >> + default y
>
> With the existing syntax, this could be expressed as
>
> depends on FOO = BAR
>
> or
>
> depends on (FOO && BAR) || (!FOO && !BAR)
>
> and I don't see how the new syntax is an improvement
> over these.
In this case I agree, the test was chosen to validate a complicated
conditional, not to show a particularly useful real-world example.
I added much better examples earlier of where the "if" style provides
improved readability.
> Overall, I'm not convinced by this patch. I have no strong
> objection to anything in here, but I'm worried that extending
> the syntax adds more problems than this one solves.
Both syntaxes have their places, it comes down to which one is most
understandable to the reader. In a lot of cases it is definitely
easier to understand the intent of the expression using "if" rather
than ors and nots. Combine that with the simplicity of the change
and any problems this might add (not sure what those are though)
would seem on balance to be worth it.
Graham
^ permalink raw reply
* [PATCH v10 8/8] media: i2c: ov9282: dynamic flash_duration maximum
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
This patch sets the current exposure time as maximum for the
flash_duration control. As Flash/Strobes which are longer than the
exposure time have no effect.
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/i2c/ov9282.c | 30 ++++++++++++++++++++++++++----
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
index 4c25b3e11afc0..cb8f6696d2783 100644
--- a/drivers/media/i2c/ov9282.c
+++ b/drivers/media/i2c/ov9282.c
@@ -199,6 +199,7 @@ struct ov9282_mode {
* @exp_ctrl: Pointer to exposure control
* @again_ctrl: Pointer to analog gain control
* @pixel_rate: Pointer to pixel rate control
+ * @flash_duration: Pointer to flash duration control
* @vblank: Vertical blanking in lines
* @noncontinuous_clock: Selection of CSI2 noncontinuous clock mode
* @cur_mode: Pointer to current selected sensor mode
@@ -221,6 +222,7 @@ struct ov9282 {
struct v4l2_ctrl *again_ctrl;
};
struct v4l2_ctrl *pixel_rate;
+ struct v4l2_ctrl *flash_duration;
u32 vblank;
bool noncontinuous_clock;
const struct ov9282_mode *cur_mode;
@@ -612,6 +614,15 @@ static int ov9282_update_controls(struct ov9282 *ov9282,
mode->vblank_max, 1, mode->vblank);
}
+static u32 ov9282_exposure_to_us(struct ov9282 *ov9282, u32 exposure)
+{
+ /* calculate exposure time in µs */
+ u32 frame_width = ov9282->cur_mode->width + ov9282->hblank_ctrl->val;
+ u32 trow_us = frame_width / (ov9282->pixel_rate->val / 1000000UL);
+
+ return exposure * trow_us;
+}
+
/**
* ov9282_update_exp_gain() - Set updated exposure and gain
* @ov9282: pointer to ov9282 device
@@ -623,9 +634,10 @@ static int ov9282_update_controls(struct ov9282 *ov9282,
static int ov9282_update_exp_gain(struct ov9282 *ov9282, u32 exposure, u32 gain)
{
int ret;
+ u32 exposure_us = ov9282_exposure_to_us(ov9282, exposure);
- dev_dbg(ov9282->dev, "Set exp %u, analog gain %u",
- exposure, gain);
+ dev_dbg(ov9282->dev, "Set exp %u (~%u us), analog gain %u",
+ exposure, exposure_us, gain);
ret = ov9282_write_reg(ov9282, OV9282_REG_HOLD, 1, 1);
if (ret)
@@ -636,6 +648,12 @@ static int ov9282_update_exp_gain(struct ov9282 *ov9282, u32 exposure, u32 gain)
goto error_release_group_hold;
ret = ov9282_write_reg(ov9282, OV9282_REG_AGAIN, 1, gain);
+ if (ret)
+ goto error_release_group_hold;
+
+ ret = __v4l2_ctrl_modify_range(ov9282->flash_duration,
+ 0, exposure_us, 1,
+ OV9282_STROBE_FRAME_SPAN_DEFAULT);
error_release_group_hold:
ov9282_write_reg(ov9282, OV9282_REG_HOLD, 1, 0);
@@ -1432,6 +1450,7 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
const struct ov9282_mode *mode = ov9282->cur_mode;
struct v4l2_fwnode_device_properties props;
u32 hblank_min;
+ u32 exposure_us;
u32 lpfr;
int ret;
@@ -1504,8 +1523,11 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops,
V4L2_CID_FLASH_STROBE_OE, 0, 1, 1, 0);
- v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops, V4L2_CID_FLASH_DURATION,
- 0, 13900, 1, 8);
+ exposure_us = ov9282_exposure_to_us(ov9282, OV9282_EXPOSURE_DEFAULT);
+ ov9282->flash_duration = v4l2_ctrl_new_std(ctrl_hdlr,
+ &ov9282_ctrl_ops, V4L2_CID_FLASH_DURATION,
+ 0, exposure_us,
+ 1, OV9282_STROBE_FRAME_SPAN_DEFAULT);
ret = v4l2_fwnode_device_parse(ov9282->dev, &props);
if (!ret) {
--
2.47.3
^ permalink raw reply related
* [PATCH v10 7/8] media: i2c: ov9282: implement try_ctrl for strobe_duration
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
As the granularity of the hardware supported values is lower than the
control value, implement a try_ctrl() function for
V4L2_CID_FLASH_DURATION. This function calculates the nearest possible
µs strobe duration for the given value and returns it back to the
caller.
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/i2c/ov9282.c | 55 +++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 52 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
index 790d421157e54..4c25b3e11afc0 100644
--- a/drivers/media/i2c/ov9282.c
+++ b/drivers/media/i2c/ov9282.c
@@ -9,6 +9,7 @@
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/i2c.h>
+#include <linux/math.h>
#include <linux/module.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
@@ -128,6 +129,8 @@
#define OV9282_REG_MIN 0x00
#define OV9282_REG_MAX 0xfffff
+#define OV9282_STROBE_SPAN_FACTOR 192
+
static const char * const ov9282_supply_names[] = {
"avdd", /* Analog power */
"dovdd", /* Digital I/O power */
@@ -691,9 +694,8 @@ static int ov9282_set_ctrl_flash_strobe_oe(struct ov9282 *ov9282, bool enable)
return ov9282_write_reg(ov9282, OV9282_REG_OUTPUT_ENABLE6, 1, current_val);
}
-static int ov9282_set_ctrl_flash_duration(struct ov9282 *ov9282, u32 value)
+static u32 ov9282_us_to_flash_duration(struct ov9282 *ov9282, u32 value)
{
- int ret;
/*
* Calculate "strobe_frame_span" increments from a given value (µs).
* This is quite tricky as "The step width of shift and span is
@@ -703,7 +705,27 @@ static int ov9282_set_ctrl_flash_duration(struct ov9282 *ov9282, u32 value)
* The formula below is interpolated from different modes/framerates
* and should work quite well for most settings.
*/
- u32 val = value * 192 / (ov9282->cur_mode->width + ov9282->hblank_ctrl->val);
+ u32 frame_width = ov9282->cur_mode->width + ov9282->hblank_ctrl->val;
+
+ return value * OV9282_STROBE_SPAN_FACTOR / frame_width;
+}
+
+static u32 ov9282_flash_duration_to_us(struct ov9282 *ov9282, u32 value)
+{
+ /*
+ * Calculate back to microseconds from "strobe_frame_span" increments.
+ * As the calculation in ov9282_us_to_flash_duration uses an integer
+ * divison round up here.
+ */
+ u32 frame_width = ov9282->cur_mode->width + ov9282->hblank_ctrl->val;
+
+ return DIV_ROUND_UP(value * frame_width, OV9282_STROBE_SPAN_FACTOR);
+}
+
+static int ov9282_set_ctrl_flash_duration(struct ov9282 *ov9282, u32 value)
+{
+ int ret;
+ u32 val = ov9282_us_to_flash_duration(ov9282, value);
ret = ov9282_write_reg(ov9282, OV9282_REG_STROBE_FRAME_SPAN, 1,
(val >> 24) & 0xff);
@@ -807,9 +829,36 @@ static int ov9282_set_ctrl(struct v4l2_ctrl *ctrl)
return ret;
}
+static int ov9282_try_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct ov9282 *ov9282 =
+ container_of_const(ctrl->handler, struct ov9282, ctrl_handler);
+
+ if (ctrl->id == V4L2_CID_FLASH_DURATION) {
+ u32 us = ctrl->val;
+ u32 fd = ov9282_us_to_flash_duration(ov9282, us);
+
+ /* get nearest strobe_duration value */
+ u32 us0 = ov9282_flash_duration_to_us(ov9282, fd);
+ u32 us1 = ov9282_flash_duration_to_us(ov9282, fd + 1);
+
+ if (abs(us1 - us) < abs(us - us0))
+ ctrl->val = us1;
+ else
+ ctrl->val = us0;
+
+ if (us != ctrl->val)
+ dev_dbg(ov9282->dev, "using next valid strobe_duration %u instead of %u\n",
+ ctrl->val, us);
+ }
+
+ return 0;
+}
+
/* V4l2 subdevice control ops*/
static const struct v4l2_ctrl_ops ov9282_ctrl_ops = {
.s_ctrl = ov9282_set_ctrl,
+ .try_ctrl = ov9282_try_ctrl,
};
/**
--
2.47.3
^ permalink raw reply related
* [PATCH v10 6/8] media: i2c: ov9282: add strobe_duration v4l2 control
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
Add V4L2_CID_FLASH_DURATION support using the "strobe_frame_span"
feature of the sensor. This is implemented by transforming the given µs
value by an interpolated formula to a "span step width" value and
writing it to register PWM_CTRL_25, PWM_CTRL_26, PWM_CTRL_27,
PWM_CTRL_28 (0x3925, 0x3926, 0x3927, 0x3928).
The maximum control value is set to the period of the current default
framerate.
All register values are based on the OV9281 datasheet v1.53 (jan 2019)
and tested using an ov9281 VisionComponents module.
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/i2c/ov9282.c | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
index 6afce803a049d..790d421157e54 100644
--- a/drivers/media/i2c/ov9282.c
+++ b/drivers/media/i2c/ov9282.c
@@ -97,6 +97,10 @@
#define OV9282_REG_MIPI_CTRL00 0x4800
#define OV9282_GATED_CLOCK BIT(5)
+/* Flash/Strobe control registers */
+#define OV9282_REG_STROBE_FRAME_SPAN 0x3925
+#define OV9282_STROBE_FRAME_SPAN_DEFAULT 0x0000001a
+
/* Input clock rate */
#define OV9282_INCLK_RATE 24000000
@@ -687,6 +691,40 @@ static int ov9282_set_ctrl_flash_strobe_oe(struct ov9282 *ov9282, bool enable)
return ov9282_write_reg(ov9282, OV9282_REG_OUTPUT_ENABLE6, 1, current_val);
}
+static int ov9282_set_ctrl_flash_duration(struct ov9282 *ov9282, u32 value)
+{
+ int ret;
+ /*
+ * Calculate "strobe_frame_span" increments from a given value (µs).
+ * This is quite tricky as "The step width of shift and span is
+ * programmable under system clock domain.", but it's not documented
+ * how to program this step width (at least in the datasheet available
+ * to the author at time of writing).
+ * The formula below is interpolated from different modes/framerates
+ * and should work quite well for most settings.
+ */
+ u32 val = value * 192 / (ov9282->cur_mode->width + ov9282->hblank_ctrl->val);
+
+ ret = ov9282_write_reg(ov9282, OV9282_REG_STROBE_FRAME_SPAN, 1,
+ (val >> 24) & 0xff);
+ if (ret)
+ return ret;
+
+ ret = ov9282_write_reg(ov9282, OV9282_REG_STROBE_FRAME_SPAN + 1, 1,
+ (val >> 16) & 0xff);
+ if (ret)
+ return ret;
+
+ ret = ov9282_write_reg(ov9282, OV9282_REG_STROBE_FRAME_SPAN + 2, 1,
+ (val >> 8) & 0xff);
+ if (ret)
+ return ret;
+
+ ret = ov9282_write_reg(ov9282, OV9282_REG_STROBE_FRAME_SPAN + 3, 1,
+ val & 0xff);
+ return ret;
+}
+
/**
* ov9282_set_ctrl() - Set subdevice control
* @ctrl: pointer to v4l2_ctrl structure
@@ -756,6 +794,9 @@ static int ov9282_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_FLASH_STROBE_OE:
ret = ov9282_set_ctrl_flash_strobe_oe(ov9282, ctrl->val);
break;
+ case V4L2_CID_FLASH_DURATION:
+ ret = ov9282_set_ctrl_flash_duration(ov9282, ctrl->val);
+ break;
default:
dev_err(ov9282->dev, "Invalid control %d", ctrl->id);
ret = -EINVAL;
@@ -1345,7 +1386,7 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
u32 lpfr;
int ret;
- ret = v4l2_ctrl_handler_init(ctrl_hdlr, 11);
+ ret = v4l2_ctrl_handler_init(ctrl_hdlr, 12);
if (ret)
return ret;
@@ -1414,6 +1455,9 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops,
V4L2_CID_FLASH_STROBE_OE, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops, V4L2_CID_FLASH_DURATION,
+ 0, 13900, 1, 8);
+
ret = v4l2_fwnode_device_parse(ov9282->dev, &props);
if (!ret) {
/* Failure sets ctrl_hdlr->error, which we check afterwards anyway */
--
2.47.3
^ permalink raw reply related
* [PATCH v10 5/8] media: i2c: ov9282: add strobe output enable v4l2 control
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
Add V4L2_CID_FLASH_STROBE_OE enable/disable support using the
"strobe output enable" feature of the sensor.
All values are based on the OV9281 datasheet v1.53 (january 2019) and
tested using an ov9281 VisionComponents module.
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/i2c/ov9282.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
index e67cff6c30ffa..6afce803a049d 100644
--- a/drivers/media/i2c/ov9282.c
+++ b/drivers/media/i2c/ov9282.c
@@ -670,6 +670,23 @@ static int ov9282_set_ctrl_vflip(struct ov9282 *ov9282, int value)
current_val);
}
+static int ov9282_set_ctrl_flash_strobe_oe(struct ov9282 *ov9282, bool enable)
+{
+ u32 current_val;
+ int ret;
+
+ ret = ov9282_read_reg(ov9282, OV9282_REG_OUTPUT_ENABLE6, 1, ¤t_val);
+ if (ret)
+ return ret;
+
+ if (enable)
+ current_val |= OV9282_OUTPUT_ENABLE6_STROBE;
+ else
+ current_val &= ~OV9282_OUTPUT_ENABLE6_STROBE;
+
+ return ov9282_write_reg(ov9282, OV9282_REG_OUTPUT_ENABLE6, 1, current_val);
+}
+
/**
* ov9282_set_ctrl() - Set subdevice control
* @ctrl: pointer to v4l2_ctrl structure
@@ -736,6 +753,9 @@ static int ov9282_set_ctrl(struct v4l2_ctrl *ctrl)
ret = ov9282_write_reg(ov9282, OV9282_REG_TIMING_HTS, 2,
(ctrl->val + ov9282->cur_mode->width) >> 1);
break;
+ case V4L2_CID_FLASH_STROBE_OE:
+ ret = ov9282_set_ctrl_flash_strobe_oe(ov9282, ctrl->val);
+ break;
default:
dev_err(ov9282->dev, "Invalid control %d", ctrl->id);
ret = -EINVAL;
@@ -1325,7 +1345,7 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
u32 lpfr;
int ret;
- ret = v4l2_ctrl_handler_init(ctrl_hdlr, 10);
+ ret = v4l2_ctrl_handler_init(ctrl_hdlr, 11);
if (ret)
return ret;
@@ -1390,6 +1410,10 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
OV9282_TIMING_HTS_MAX - mode->width,
1, hblank_min);
+ /* Flash/Strobe controls */
+ v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops,
+ V4L2_CID_FLASH_STROBE_OE, 0, 1, 1, 0);
+
ret = v4l2_fwnode_device_parse(ov9282->dev, &props);
if (!ret) {
/* Failure sets ctrl_hdlr->error, which we check afterwards anyway */
--
2.47.3
^ permalink raw reply related
* [PATCH v10 4/8] media: i2c: ov9282: add output enable register definitions
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
Add #define's for the output enable registers (0x3004, 0x3005, 0x3006),
also known as SC_CTRL_04, SC_CTRL_05, SC_CTRL_04. Use those register
definitions instead of the raw values in the `common_regs` struct.
All values are based on the OV9281 datasheet v1.53 (january 2019).
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/i2c/ov9282.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
index a9f6176e9729d..e67cff6c30ffa 100644
--- a/drivers/media/i2c/ov9282.c
+++ b/drivers/media/i2c/ov9282.c
@@ -37,6 +37,29 @@
#define OV9282_REG_ID 0x300a
#define OV9282_ID 0x9281
+/* Output enable registers */
+#define OV9282_REG_OUTPUT_ENABLE4 0x3004
+#define OV9282_OUTPUT_ENABLE4_GPIO2 BIT(1)
+#define OV9282_OUTPUT_ENABLE4_D9 BIT(0)
+
+#define OV9282_REG_OUTPUT_ENABLE5 0x3005
+#define OV9282_OUTPUT_ENABLE5_D8 BIT(7)
+#define OV9282_OUTPUT_ENABLE5_D7 BIT(6)
+#define OV9282_OUTPUT_ENABLE5_D6 BIT(5)
+#define OV9282_OUTPUT_ENABLE5_D5 BIT(4)
+#define OV9282_OUTPUT_ENABLE5_D4 BIT(3)
+#define OV9282_OUTPUT_ENABLE5_D3 BIT(2)
+#define OV9282_OUTPUT_ENABLE5_D2 BIT(1)
+#define OV9282_OUTPUT_ENABLE5_D1 BIT(0)
+
+#define OV9282_REG_OUTPUT_ENABLE6 0x3006
+#define OV9282_OUTPUT_ENABLE6_D0 BIT(7)
+#define OV9282_OUTPUT_ENABLE6_PCLK BIT(6)
+#define OV9282_OUTPUT_ENABLE6_HREF BIT(5)
+#define OV9282_OUTPUT_ENABLE6_STROBE BIT(3)
+#define OV9282_OUTPUT_ENABLE6_ILPWM BIT(2)
+#define OV9282_OUTPUT_ENABLE6_VSYNC BIT(1)
+
/* Exposure control */
#define OV9282_REG_EXPOSURE 0x3500
#define OV9282_EXPOSURE_MIN 1
@@ -213,9 +236,9 @@ static const struct ov9282_reg common_regs[] = {
{0x0302, 0x32},
{0x030e, 0x02},
{0x3001, 0x00},
- {0x3004, 0x00},
- {0x3005, 0x00},
- {0x3006, 0x04},
+ {OV9282_REG_OUTPUT_ENABLE4, 0x00},
+ {OV9282_REG_OUTPUT_ENABLE5, 0x00},
+ {OV9282_REG_OUTPUT_ENABLE6, OV9282_OUTPUT_ENABLE6_ILPWM},
{0x3011, 0x0a},
{0x3013, 0x18},
{0x301c, 0xf0},
--
2.47.3
^ permalink raw reply related
* [PATCH v10 3/8] Documentation: uAPI: media: add V4L2_CID_FLASH_{DURATION,STROBE_OE}
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
Add the new strobe duration and hardware strobe output enable to v4l
uAPI documentation. Additionally add labels for cross-referencing v4l
controls.
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
.../userspace-api/media/v4l/ext-ctrls-flash.rst | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-flash.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-flash.rst
index d22c5efb806a1..7cf0d33e79ff0 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-flash.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-flash.rst
@@ -57,6 +57,8 @@ Flash Control IDs
``V4L2_CID_FLASH_CLASS (class)``
The FLASH class descriptor.
+.. _v4l2-cid-flash-led-mode:
+
``V4L2_CID_FLASH_LED_MODE (menu)``
Defines the mode of the flash LED, the high-power white LED attached
to the flash controller. Setting this control may not be possible in
@@ -80,6 +82,8 @@ Flash Control IDs
+.. _v4l2-cid-flash-strobe-source:
+
``V4L2_CID_FLASH_STROBE_SOURCE (menu)``
Defines the source of the flash LED strobe.
@@ -96,6 +100,12 @@ Flash Control IDs
- The flash strobe is triggered by an external source. Typically
this is a sensor, which makes it possible to synchronise the
flash strobe start to exposure start.
+ This method of controlling flash LED strobe has two additional
+ prerequisites: the strobe source's :ref:`strobe output
+ <v4l2-cid-flash-strobe-oe>` must be enabled (if available)
+ and the flash controller's :ref:`flash LED mode
+ <v4l2-cid-flash-led-mode>` must be set to
+ ``V4L2_FLASH_LED_MODE_FLASH``.
@@ -186,3 +196,35 @@ Flash Control IDs
charged before strobing. LED flashes often require a cooldown period
after strobe during which another strobe will not be possible. This
is a read-only control.
+
+.. _v4l2-cid-flash-duration:
+
+``V4L2_CID_FLASH_DURATION (integer)``
+ Duration of the flash strobe pulse generated by the strobe source, when
+ using external strobe. This control shall be implemented by the device
+ generating the hardware flash strobe signal, typically a camera sensor,
+ connected to a flash controller.
+
+ The flash controllers :ref:`strobe source <v4l2-cid-flash-strobe-source>`
+ must be configured to ``V4L2_FLASH_STROBE_SOURCE_EXTERNAL`` for this
+ mode of operation. For more details please also take a look at the
+ documentation there.
+
+ The unit should be microseconds (µs) if possible.
+
+.. _v4l2-cid-flash-strobe-oe:
+
+``V4L2_CID_FLASH_STROBE_OE (boolean)``
+ Enables the output of a hardware strobe signal from the strobe source,
+ when using external strobe. This control shall be implemented by the device
+ generating the hardware flash strobe signal, typically a camera sensor,
+ connected to a flash controller.
+
+ Provided the signal generating device driver supports it, the length of the
+ strobe signal can be configured by adjusting its
+ :ref:`flash duration <v4l2-cid-flash-duration>`.
+
+ The flash controllers :ref:`strobe source <v4l2-cid-flash-strobe-source>`
+ must be configured to ``V4L2_FLASH_STROBE_SOURCE_EXTERNAL`` for this
+ mode of operation. For more details please also take a look at the
+ documentation there.
--
2.47.3
^ permalink raw reply related
* [PATCH v10 2/8] media: v4l: ctrls: add a control for enabling strobe output
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
Add a control V4L2_CID_FLASH_STROBE_OE to en- or disable the
strobe output of v4l2 devices (most likely sensors).
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/v4l2-core/v4l2-ctrls-defs.c | 2 ++
include/uapi/linux/v4l2-controls.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 4848423205ff7..765aeeec84fe5 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1136,6 +1136,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_CHARGE: return "Charge";
case V4L2_CID_FLASH_READY: return "Ready to Strobe";
case V4L2_CID_FLASH_DURATION: return "Strobe Duration";
+ case V4L2_CID_FLASH_STROBE_OE: return "Strobe Output Enable";
/* JPEG encoder controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1282,6 +1283,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_FLASH_CHARGE:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_FLASH_STROBE_OE:
case V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER:
case V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE:
case V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY_ENABLE:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 9830833b48a52..32ba3b5fb1dd5 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1187,6 +1187,7 @@ enum v4l2_flash_strobe_source {
#define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11)
#define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
#define V4L2_CID_FLASH_DURATION (V4L2_CID_FLASH_CLASS_BASE + 13)
+#define V4L2_CID_FLASH_STROBE_OE (V4L2_CID_FLASH_CLASS_BASE + 14)
/* JPEG-class control IDs */
--
2.47.3
^ permalink raw reply related
* [PATCH v10 1/8] media: v4l: ctrls: add a control for flash/strobe duration
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
In-Reply-To: <20251209-ov9282-flash-strobe-v10-0-0117cab82e2d@linux.dev>
Add a V4L2_CID_FLASH_DURATION control to set the duration of a
flash/strobe pulse. This controls the length of the flash/strobe pulse
output by device (typically a camera sensor) and connected to the flash
controller. This is different to the V4L2_CID_FLASH_TIMEOUT control,
which is implemented by the flash controller and defines a limit after
which the flash is "forcefully" turned off again.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
drivers/media/v4l2-core/v4l2-ctrls-defs.c | 1 +
include/uapi/linux/v4l2-controls.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index ad41f65374e23..4848423205ff7 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1135,6 +1135,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_FAULT: return "Faults";
case V4L2_CID_FLASH_CHARGE: return "Charge";
case V4L2_CID_FLASH_READY: return "Ready to Strobe";
+ case V4L2_CID_FLASH_DURATION: return "Strobe Duration";
/* JPEG encoder controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 2d30107e047ee..9830833b48a52 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1186,6 +1186,7 @@ enum v4l2_flash_strobe_source {
#define V4L2_CID_FLASH_CHARGE (V4L2_CID_FLASH_CLASS_BASE + 11)
#define V4L2_CID_FLASH_READY (V4L2_CID_FLASH_CLASS_BASE + 12)
+#define V4L2_CID_FLASH_DURATION (V4L2_CID_FLASH_CLASS_BASE + 13)
/* JPEG-class control IDs */
--
2.47.3
^ permalink raw reply related
* [PATCH v10 0/8] Add strobe duration and strobe output enable v4l2 ctrl
From: Richard Leitner @ 2025-12-09 22:44 UTC (permalink / raw)
To: Sakari Ailus, Dave Stevenson, Mauro Carvalho Chehab, Lee Jones,
Pavel Machek, Laurent Pinchart
Cc: linux-media, linux-kernel, linux-leds, Richard Leitner,
Hans Verkuil
This series adds two new v4l2 controls:
- V4L2_CID_FLASH_DURATION: "Strobe duration": This control enables
setting a desired flash/strobe length/duration in µs.
- V4L2_CID_FLASH_STROBE_OE: "Strobe output enable": This
control enables the hardware strobe output signal of a v4l2 device.
As a first user of these new controls add basic flash/strobe support
for ov9282 sensors using their "hardware strobe output". The duration
calculation is only interpolated from various measurements, as no
documentation was found.
Further flash/strobe-related controls as well as a migration to v4l2-cci
helpers for ov9282 will likely be implemented in future series.
All register addresses/values are based on the OV9281 datasheet v1.53
(january 2019). This series was tested using an ov9281 VisionComponents
camera module.
Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
---
Changes in v10:
- Avoid bitwise or on error codes in ov9282_set_ctrl_flash_duration() (Thanks Sakari)
- Link to v9: https://patch.msgid.link/20251120-ov9282-flash-strobe-v9-0-6c9e3a4301d7@linux.dev
Changes in v9:
- Avoid needless multiplication/division in ov9282.c (Thanks Sakari)
- Avoid possible u32 overflow in ov9282.c (Thanks Sakari)
- Link to v8: https://patch.msgid.link/20251104-ov9282-flash-strobe-v8-0-b91dfef1c65a@linux.dev
Changes in v8:
- Minor styling changes across the set
- Add missing error handling for ov9282 strobe_frame_span writing
- Rename V4L2_CID_FLASH_HW_STROBE_SIGNAL to V4L2_CID_FLASH_STROBE_OE
- Drop 02/10: FLASH_DURATION handling in v4l2-flash
- Drop 08/10: strobe_source in ov9282
- Link to v7: https://lore.kernel.org/r/20250901-ov9282-flash-strobe-v7-0-d58d5a694afc@linux.dev
Changes in v7:
- Improved v4l2 uAPI documentation (thanks Sakari)
- Link to v6: https://lore.kernel.org/r/20250716-ov9282-flash-strobe-v6-0-934f12aeff33@linux.dev
Changes in v6:
- Fix "Alignment should match open parenthesis" by Media-CI bot in v4l2-flash-led-class.c
- Fix "format string contains non-ascii character (µ)" by Media-CI bot in ov9282.c
- Introduce new V4L2_CID_FLASH_HW_STROBE_SIGNAL control (as suggested by Sakari)
- Implement V4L2_CID_FLASH_HW_STROBE_SIGNAL instead of
V4L2_CID_FLASH_LED_MODE in ov9282.c (as suggested by Sakari)
- Drop "media: v4l2-flash: fix flash_timeout comment" as this was
applied (thanks Lee)
- Link to v5: https://lore.kernel.org/r/20250617-ov9282-flash-strobe-v5-0-9762da74d065@linux.dev
Changes in v5:
- Improve try_ctrl for flash_duration by using DIV_ROUND_UP() and abs() (thanks Sakari)
- Drop "leds: flash: Add support for flash/strobe duration" as this was applied upstream
- Add "media: i2c: ov9282: dynamic flash_duration maximum" (thanks Sakari)
- Link to v4: https://lore.kernel.org/r/20250507-ov9282-flash-strobe-v4-0-72b299c1b7c9@linux.dev
Changes in v4:
- Fix FLASH_DURATION implementation in v4l2-flash-led-class.c by adding a
missing brace and enum entry (thanks Sakari)
- Fix format of multiline comment in ov9282.c (thanks Sakari)
- Add missing NULL check in ov9282.c (thanks Sakari)
- Adapt nr_of_controls_hint for v4l2 handler in ov9282.c (thanks Sakari)
- Add patch for implementing try_ctrl for strobe_duration (thanks Sakari)
- Link to v3: https://lore.kernel.org/r/20250429-ov9282-flash-strobe-v3-0-2105ce179952@linux.dev
Changes in v3:
- create separate patch for leds driver changes (thanks Lee)
- Link to v2: https://lore.kernel.org/r/20250314-ov9282-flash-strobe-v2-0-14d7a281342d@linux.dev
Changes in v2:
- remove not needed controls in struct ov9282 (thanks Dave)
- Fix commit message of 3/3 regarding framerate get/set (thanks Dave)
- Add V4L2_CID_FLASH_STROBE_SOURCE impementation to ov9282
- Add new V4L2_CID_FLASH_DURATION control (as suggested by Laurent)
- Use FLASH_DURATION instead of FLASH_TIMEOUT for ov9282
- Link to v1: https://lore.kernel.org/r/20250303-ov9282-flash-strobe-v1-0-0fd57a1564ba@linux.dev
---
Richard Leitner (8):
media: v4l: ctrls: add a control for flash/strobe duration
media: v4l: ctrls: add a control for enabling strobe output
Documentation: uAPI: media: add V4L2_CID_FLASH_{DURATION,STROBE_OE}
media: i2c: ov9282: add output enable register definitions
media: i2c: ov9282: add strobe output enable v4l2 control
media: i2c: ov9282: add strobe_duration v4l2 control
media: i2c: ov9282: implement try_ctrl for strobe_duration
media: i2c: ov9282: dynamic flash_duration maximum
.../userspace-api/media/v4l/ext-ctrls-flash.rst | 42 +++++
drivers/media/i2c/ov9282.c | 174 ++++++++++++++++++++-
drivers/media/v4l2-core/v4l2-ctrls-defs.c | 3 +
include/uapi/linux/v4l2-controls.h | 2 +
4 files changed, 215 insertions(+), 6 deletions(-)
---
base-commit: 2f112b1c25da9f5346c2261ed35c5b1e0b906471
change-id: 20250303-ov9282-flash-strobe-ac6bd00c9de6
Best regards,
--
Richard Leitner <richard.leitner@linux.dev>
^ permalink raw reply
* Re: [PULL 00/10] Misc HW patches for 2025-12-09
From: Richard Henderson @ 2025-12-09 22:42 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, qemu-devel
In-Reply-To: <20251209200537.84097-1-philmd@linaro.org>
On 12/9/25 14:05, Philippe Mathieu-Daudé wrote:
> The following changes since commit 2257f52a97f28ce3be4366817ea8817ad866562b:
>
> Merge tag 'pull-10.2-final-fixes-051225-2' ofhttps://gitlab.com/stsquad/qemu into staging (2025-12-05 12:38:37 -0600)
>
> are available in the Git repository at:
>
> https://github.com/philmd/qemu.git tags/hw-misc-20251209
>
> for you to fetch changes up to efd6b3d1768d04d5491b62ad7385f623fb12f627:
>
> Revert "hw/net/virtio-net: make VirtIONet.vlans an array instead of a pointer" (2025-12-09 21:00:15 +0100)
>
> ----------------------------------------------------------------
> Misc HW / migration / typo fixes
Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/10.2 as appropriate.
r~
^ permalink raw reply
* Re: [PATCH v6 8/8] arm64: dts: qcom: Add support for Pixel 3 and Pixel 3 XL
From: Dmitry Baryshkov @ 2025-12-09 22:42 UTC (permalink / raw)
To: david
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sumit Semwal, Casey Connolly, Neil Armstrong,
Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Marijn Suijten,
Dmitry Baryshkov, Vinod Koul, Petr Hodina, linux-arm-msm,
devicetree, linux-kernel, phone-devel, dri-devel, Amit Pundir,
Casey Connolly, Joel Selvaraj, Konrad Dybcio
In-Reply-To: <20251208-pixel-3-v6-8-e9e559d6f412@ixit.cz>
On Mon, Dec 08, 2025 at 10:42:01AM +0100, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> This adds initial device tree support for the following phones:
>
> - Google Pixel 3 (blueline)
> - Google Pixel 3 XL (crosshatch)
>
> Both phone boards use the same identifiers and differ only slightly
> in their connected peripherals.
>
> Supported functionality includes:
> - Debug UART
> - UFS
> - USB-C (peripheral mode)
> - Framebuffer (both u-boot and Linux)
> - Display (Pixel 3 only, and the driver needs work)
> - GPU
> - Bluetooth
> - Wi-Fi
>
> The rmtfs region is allocated using UIO, making it technically "dynamic."
>
> Its address and size can be read from sysfs:
>
> $ cat /sys/class/uio/uio0/name
> /sys/class/uio/uio0/maps/map0/addr
> 0x00000000f2701000
>
> $ cat /sys/class/uio/uio0/maps/map0/size
> 0x0000000000200000
>
> Like the OnePlus 6, the Pixel 3 requires 1 kB of reserved memory on either
> side of the rmtfs region to work around an XPU bug that would otherwise
> cause erroneous violations when accessing the rmtfs_mem region.
>
> Co-developed-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Co-developed-by: Casey Connolly <casey@connolly.tech>
> Signed-off-by: Casey Connolly <casey@connolly.tech>
> Co-developed-by: Joel Selvaraj <foss@joelselvaraj.com>
> Signed-off-by: Joel Selvaraj <foss@joelselvaraj.com>
> Co-developed-by: Sumit Semwal <sumit.semwal@linaro.org>
> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> Co-developed-by: Vinod Koul <vkoul@kernel.org>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> .../arm64/boot/dts/qcom/sdm845-google-blueline.dts | 85 ++++
> arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 524 +++++++++++++++++++++
> .../boot/dts/qcom/sdm845-google-crosshatch.dts | 33 ++
> 4 files changed, 644 insertions(+)
>
> +
> +&wifi {
> + vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
> + vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
> + vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
> + vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> +
> + qcom,snoc-host-cap-8bit-quirk;
> +
> + status = "okay";
> +};
Missing calbiration data. It needs to be declared here and submitted to
ath10k ML: https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath10k/boardfiles.html
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915/display: Fix intel_lpe_audio_irq_handler for PREEMPT-RT
From: Matthew Brost @ 2025-12-09 22:42 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: intel-xe, intel-gfx
In-Reply-To: <20251209151319.494640-4-dev@lankhorst.se>
On Tue, Dec 09, 2025 at 04:13:21PM +0100, Maarten Lankhorst wrote:
> No need for backporting, this is only useful for i915,
> and it doesn't compile with I915 enabled.
>
s/I915/PREEMPT_PT
With that fixed:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
> ---
> drivers/gpu/drm/i915/display/intel_lpe_audio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
> index 5b41abe1c64d5..172c0062237eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
> @@ -262,7 +262,7 @@ void intel_lpe_audio_irq_handler(struct intel_display *display)
> if (!HAS_LPE_AUDIO(display))
> return;
>
> - ret = generic_handle_irq(display->audio.lpe.irq);
> + ret = generic_handle_irq_safe(display->audio.lpe.irq);
> if (ret)
> drm_err_ratelimited(display->drm,
> "error handling LPE audio irq: %d\n", ret);
> --
> 2.51.0
>
^ permalink raw reply
* [PATCH v1] netlink: Remove implicit 32-bit trunction in nla_memcmp
From: Ian Rogers @ 2025-12-09 22:41 UTC (permalink / raw)
To: Andrew Morton, linux-kernel; +Cc: Ian Rogers
64-bit truncation to 32-bit can result in the sign of the truncated
value changing. The nla_memcmp function subtracts a 16-bit nla_len
from a size_t size and so this shouldn't occur, but the code looks
hazardous so change it to make the comparisons explicit and avoid a
truncated subtract.
Signed-off-by: Ian Rogers <irogers@google.com>
---
lib/nlattr.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index be9c576b6e2d..6e1c40dd11e3 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -854,12 +854,12 @@ EXPORT_SYMBOL(nla_memcpy);
int nla_memcmp(const struct nlattr *nla, const void *data,
size_t size)
{
- int d = nla_len(nla) - size;
+ u16 l = nla_len(nla);
- if (d == 0)
- d = memcmp(nla_data(nla), data, size);
+ if (l == size)
+ return memcmp(nla_data(nla), data, size);
- return d;
+ return l > size ? 1 : -1;
}
EXPORT_SYMBOL(nla_memcmp);
--
2.52.0.223.gf5cc29aaa4-goog
^ permalink raw reply related
* [PATCH v1] tracing: Avoid possible signed 64-bit truncation
From: Ian Rogers @ 2025-12-09 22:40 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, linux-kernel,
linux-trace-kernel
Cc: Ian Rogers
64-bit truncation to 32-bit can result in the sign of the truncated
value changing. The cmp_mod_entry is used in bsearch and so the
truncation could result in an invalid search order. This would only
happen were the addresses more than 2GB apart and so unlikely, but
let's fix the potentially broken compare anyway.
Signed-off-by: Ian Rogers <irogers@google.com>
---
kernel/trace/trace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d1e527cf2aae..e6a80cbe9326 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6057,8 +6057,10 @@ static int cmp_mod_entry(const void *key, const void *pivot)
if (addr >= ent[0].mod_addr && addr < ent[1].mod_addr)
return 0;
+ else if (addr > ent->mod_addr)
+ return 1;
else
- return addr - ent->mod_addr;
+ return -1;
}
/**
--
2.52.0.223.gf5cc29aaa4-goog
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: PCI: loongson: Document msi-parent property
From: Rob Herring (Arm) @ 2025-12-09 22:39 UTC (permalink / raw)
To: Yao Zi
Cc: linux-pci, Conor Dooley, Lorenzo Pieralisi,
Krzysztof Wilczyński, linux-kernel, Jiaxun Yang, devicetree,
Manivannan Sadhasivam, WANG Xuerui, Krzysztof Kozlowski,
loongarch, Binbin Zhou, Bjorn Helgaas, Huacai Chen
In-Reply-To: <20251209140006.54821-3-me@ziyao.cc>
On Tue, 09 Dec 2025 14:00:06 +0000, Yao Zi wrote:
> Loongson PCI controllers found in LS2K1000/2000 SoCs
> (loongson,ls2k-pci), 7A1000/2000 bridge chips (loongson,ls7a-pci), and
> RS780E bridge chips (loongson,rs780e-pci) all have their paired MSI
> controllers.
>
> Though only the one in LS2K2000 SoC is described in devicetree, we
> should document the property for all variants. For the same reason, it
> isn't marked as required for now.
>
> Fixes: 83e757ecfd5d ("dt-bindings: Document Loongson PCI Host Controller")
> Signed-off-by: Yao Zi <me@ziyao.cc>
> ---
> Documentation/devicetree/bindings/pci/loongson.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.