Re: [PATCH v3 2/2] backlight: Add support for Orient Chip OCP8178

[email protected]
Newsgroups org.kernel.vger.linux-leds,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing PM resume initialization causes backlight to fail after system suspend.
--

--- Patch [2]: [PATCH v3 2/2] backlight: Add support for Orient Chip OCP8178 ---
commit bfc20bddc55de3beb592431b21d9fc9bc3366d90
Author: Wim de With <[email protected]>

backlight: Add support for Orient Chip OCP8178

This commit adds a driver for the Orient Chip OCP8178 backlight controller.
The driver implements a vendor-specific onewire protocol over GPIO to set
static brightness levels.

> diff --git a/drivers/video/backlight/ocp8178_bl.c b/drivers/video/backlight/ocp8178_bl.c
> new file mode 100644
> index 0000000000000..6c1e8c9451f12
> --- /dev/null
> +++ b/drivers/video/backlight/ocp8178_bl.c
[ ... ]
> +static int ocp8178_bl_update_status(struct backlight_device *bl)
> +{
> +	struct ocp8178_bl *ocp8178 = bl_get_data(bl);
> +	u8 brightness = backlight_get_brightness(bl);
> +
> +	ocp8178_bl_set_brightness(ocp8178, brightness);
> +	return 0;
> +}
> +
> +static const struct backlight_ops ocp8178_bl_ops = {
> +	.options = BL_CORE_SUSPENDRESUME,
> +	.update_status = ocp8178_bl_update_status,
> +};
[ ... ]
> +static struct platform_driver ocp8178_bl_driver = {
> +	.driver = {
> +		.name = "ocp8178-bl",
> +		.of_match_table = ocp8178_bl_of_match,
> +	},
> +	.probe = ocp8178_bl_probe,
> +};

[Severity: High]
Will the backlight fail to turn on after a system suspend cycle?

Since BL_CORE_SUSPENDRESUME is set in ocp8178_bl_ops, the backlight core
calls ocp8178_bl_update_status() upon system resume. During suspend, the
GPIO controller may pull the control pin low.

If the pin remains low for more than 2.5ms (OCP8178_T_OFF_US), the chip
shuts down and will power back up in its default PWM mode.

Because ocp8178_bl_update_status() immediately sends 1-wire commands without
verifying state or re-running ocp8178_bl_enable_onewire(), will the chip
misinterpret these 1-wire signals as tiny PWM pulses instead of restoring
the brightness level?

Does the platform driver need pm_ops to re-initialize the 1-wire mode state
before the backlight core attempts to update the brightness?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.