From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Matthias Fend <matthias.fend@emfend.at>
Cc: "Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Hans Verkuil" <hverkuil@kernel.org>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Hans de Goede" <hansg@kernel.org>,
"Ricardo Ribalda" <ribalda@chromium.org>,
"André Apitzsch" <git@apitzsch.eu>,
"Tarang Raval" <tarang.raval@siliconsignals.io>,
"Benjamin Mugnier" <benjamin.mugnier@foss.st.com>,
"Sylvain Petinot" <sylvain.petinot@foss.st.com>,
"Dongcheng Yan" <dongcheng.yan@intel.com>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Jingjing Xiong" <jingjing.xiong@intel.com>,
"Heimir Thor Sverrisson" <heimir.sverrisson@gmail.com>,
"Mehdi Djait" <mehdi.djait@linux.intel.com>,
"Vladimir Zapolskiy" <vladimir.zapolskiy@linaro.org>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Hardevsinh Palaniya" <hardevsinh.palaniya@siliconsignals.io>,
"Svyatoslav Ryhel" <clamor95@gmail.com>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, "Hao Yao" <hao.yao@intel.com>,
"Himanshu Bhavani" <himanshu.bhavani@siliconsignals.io>,
bsp-development.geo@leica-geosystems.com
Subject: Re: [PATCH v7 2/2] media: i2c: add Himax HM1246 image sensor driver
Date: Tue, 13 Jan 2026 11:28:56 +0200 [thread overview]
Message-ID: <aWYQWAQnnFW0Kf9z@smile.fi.intel.com> (raw)
In-Reply-To: <f2e77bb5-957e-4751-8304-d9fb94927417@emfend.at>
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?
> > > + 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.
> > > +}
...
> > > + 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?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-01-13 9:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 14:49 [PATCH v7 0/2] media: add Himax HM1246 image sensor Matthias Fend
2026-01-12 14:49 ` [PATCH v7 1/2] media: dt-bindings: i2c: " Matthias Fend
2026-01-12 19:46 ` Sakari Ailus
2026-01-12 14:49 ` [PATCH v7 2/2] media: i2c: add Himax HM1246 image sensor driver Matthias Fend
2026-01-12 19:01 ` Andy Shevchenko
2026-01-13 9:06 ` Matthias Fend
2026-01-13 9:28 ` Andy Shevchenko [this message]
2026-01-13 11:38 ` Sakari Ailus
2026-01-12 20:38 ` Sakari Ailus
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=aWYQWAQnnFW0Kf9z@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=benjamin.mugnier@foss.st.com \
--cc=bryan.odonoghue@linaro.org \
--cc=bsp-development.geo@leica-geosystems.com \
--cc=clamor95@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dongcheng.yan@intel.com \
--cc=git@apitzsch.eu \
--cc=hansg@kernel.org \
--cc=hao.yao@intel.com \
--cc=hardevsinh.palaniya@siliconsignals.io \
--cc=heimir.sverrisson@gmail.com \
--cc=himanshu.bhavani@siliconsignals.io \
--cc=hverkuil@kernel.org \
--cc=jingjing.xiong@intel.com \
--cc=krzk+dt@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=matthias.fend@emfend.at \
--cc=mchehab@kernel.org \
--cc=mehdi.djait@linux.intel.com \
--cc=ribalda@chromium.org \
--cc=robh@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=stern@rowland.harvard.edu \
--cc=sylvain.petinot@foss.st.com \
--cc=tarang.raval@siliconsignals.io \
--cc=vladimir.zapolskiy@linaro.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