Message-ID: <aWYupZ3xp7-IycFD@kekkonen.localdomain>
Date: Tue, 13 Jan 2026 13:38:13 +0200
From: Sakari Ailus <sakari.ailus@...ux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Matthias Fend <matthias.fend@...end.at>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Hans Verkuil <hverkuil@...nel.org>,
	Hans de Goede <hansg@...nel.org>,
	Ricardo Ribalda <ribalda@...omium.org>,
	André Apitzsch <git@...tzsch.eu>,
	Tarang Raval <tarang.raval@...iconsignals.io>,
	Benjamin Mugnier <benjamin.mugnier@...s.st.com>,
	Sylvain Petinot <sylvain.petinot@...s.st.com>,
	Dongcheng Yan <dongcheng.yan@...el.com>,
	Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Jingjing Xiong <jingjing.xiong@...el.com>,
	Heimir Thor Sverrisson <heimir.sverrisson@...il.com>,
	Mehdi Djait <mehdi.djait@...ux.intel.com>,
	Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Hardevsinh Palaniya <hardevsinh.palaniya@...iconsignals.io>,
	Svyatoslav Ryhel <clamor95@...il.com>, linux-media@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Hao Yao <hao.yao@...el.com>,
	Himanshu Bhavani <himanshu.bhavani@...iconsignals.io>,
	bsp-development.geo@...ca-geosystems.com
Subject: Re: [PATCH v7 2/2] media: i2c: add Himax HM1246 image sensor driver

Hi Andy, Matthias,

On Tue, Jan 13, 2026 at 11:28:56AM +0200, Andy Shevchenko wrote:
> On Tue, Jan 13, 2026 at 10:06:36AM +0100, Matthias Fend wrote:
> > Hi Andy,
> > Am 12.01.2026 um 20:01 schrieb Andy Shevchenko:
> > > On Mon, Jan 12, 2026 at 03:49:33PM +0100, Matthias Fend wrote:
> 
> ...
> 
> > > > +struct hm1246_mode {
> > > > +	u32 codes[4];
> > > > +	u32 clocks_per_pixel;
> > > 
> > > > +	u32 top;
> > > > +	u32 left;
> > > > +	u32 width;
> > > > +	u32 height;
> > > 
> > > Why not use struct v4l2_rect?
> > 
> > Valid question. I would save something in six places, but add something in
> > about 27 others. Because of this ratio, I opted for the current way.
> 
> It's more about standardization. Can you provide an example of the place where
> you need to add something?

We have around as many driver mode structs for more or less similar
purposes as we have register-list based drivers, so certainly some help
from the framework could be useful. But I don't think this problem is
solved by switching to struct v4l2_rect here (albeit I don't think it's a
bad idea as such either).

> 
> > > > +	u32 hts;
> > > > +	u32 vts_min;
> > > > +	const struct hm1246_reg_list reg_list;
> > > > +};
> 
> ...
> 
> > > > +static int hm1246_get_selection(struct v4l2_subdev *sd,
> > > > +				struct v4l2_subdev_state *state,
> > > > +				struct v4l2_subdev_selection *sel)
> > > > +{
> > > > +	const struct v4l2_mbus_framefmt *format;
> > > > +	const struct hm1246_mode *mode;
> > > > +
> > > > +	format = v4l2_subdev_state_get_format(state, 0);
> > > > +	mode = v4l2_find_nearest_size(hm1246_modes, ARRAY_SIZE(hm1246_modes),
> > > > +				      width, height, format->width,
> > > > +				      format->height);
> > > > +
> > > > +	switch (sel->target) {
> > > > +	case V4L2_SEL_TGT_CROP:
> > > > +		sel->r = *v4l2_subdev_state_get_crop(state, 0);
> > > > +		return 0;
> > > > +
> > > > +	case V4L2_SEL_TGT_NATIVE_SIZE:
> > > > +		sel->r.top = 0;
> > > > +		sel->r.left = 0;
> > > > +		sel->r.width = HM1246_NATIVE_WIDTH;
> > > > +		sel->r.height = HM1246_NATIVE_HEIGHT;
> > > > +		return 0;
> > > > +
> > > > +	case V4L2_SEL_TGT_CROP_DEFAULT:
> > > > +	case V4L2_SEL_TGT_CROP_BOUNDS:
> > > 
> > > > +		sel->r.top = mode->top;
> > > > +		sel->r.left = mode->left;
> > > > +		sel->r.width = mode->width;
> > > > +		sel->r.height = mode->height;
> > > 
> > > Seems in the same way here.
> > > 
> > > > +		return 0;
> > > > +	}
> > > 
> > > > +	return -EINVAL;
> > > 
> > > Why not making it a default case?
> > 
> > I prefer it when the return statement is at the end of the function. Do you
> > see a problem here?
> 
> For the matter of fact I do see a problem here. But it's not how code works
> right now, it's about maintenance. The disrupted returns like this may lead
> to subtle mistakes when the code gets changed (grows) and more cases added
> including ones that might want to share something as a success path.

I'd also move returning to the default case -- the function doesn't do
anything else after the switch.

> 
> > > > +}
> 
> ...
> 
> > > > +	hm1246->reset_gpio =
> > > > +		devm_gpiod_get_optional(hm1246->dev, "reset", GPIOD_OUT_HIGH);
> > > > +	if (IS_ERR(hm1246->reset_gpio))
> > > > +		return dev_err_probe(hm1246->dev, PTR_ERR(hm1246->reset_gpio),
> > > > +				     "failed to get reset GPIO\n");
> > > 
> > > Can it be GPIO reset driver used instead? (Note, it's made agnostic now.)
> > 
> > That would probably be possible, but I currently don't see any advantage for
> > I2C image sensors. If I understand correctly, you would first have to define
> > a reset controller that could then be used in the sensor – instead of simply
> > specifying the GPIO directly.
> 
> Again, standardization.
> 
> > The advantage of being able to share the reset line with other components
> > probably doesn't make sense for these sensors in most cases. That's perhaps
> > also the reason why it hasn't been used before.
> > 
> > Maybe the media maintainers have an opinion on this?

I think this is a good idea: the reset line is sometimes shared with
another device (VCM driver in this case). Right now we don't have a sensor
driver doing this however. Do you know of a driver that would serve as an
example?

That being said, I think adding this could be done on top of this set as
well.

-- 
Kind regards,

Sakari Ailus

Powered by blists - more mailing lists