On 2/26/25 08:54, Krzysztof Kozlowski wrote:

On 25/02/2025 15:58, Fabrice Gasnier wrote:

quoted

On 2/25/25 13:04, Krzysztof Kozlowski wrote:

quoted

On Mon, Feb 24, 2025 at 07:01:47PM +0100, Fabrice Gasnier wrote:

quoted

 	}
 
 	return pinctrl_pm_select_sleep_state(dev);

@@ -246,6 +413,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(stm32_pwm_lp_pm_ops, stm32_pwm_lp_suspend,
 
 static const struct of_device_id stm32_pwm_lp_of_match[] = {
 	{ .compatible = "st,stm32-pwm-lp", },
+	{ .compatible = "st,stm32mp25-pwm-lp", },

No driver data suggests device is backwards compatible. Commit msg
suggests not, so that's confusing.

The LPTimer PWM driver takes benefit of the MFD parent driver to feed in
data, e.g. 'num_cc_chans'. Number of channels is now variable, on

This means this ID table is useless. You do the matching via parent
device, so stop growing the table and call it deprecated or something.

quoted

STM32MP25 (e.g. not a single channel). But it can't be hard-coded as
compatible data. (there's only 1 channel on earlier LP Timer hardware
revision).

The hardware controller is a bit different, hence the new compatible

If it works with old compatible, it's an easy proof that it is
compatible, so please counter argument that with something specific.

Ack, I'll drop the "st,stm32mp25-pwm-lp" compatible, as match through
the parent device is achieved here.
Alternatively, reading directly the hardware configuration register
could be used to retrieve the 'num_cc_chans'.

Thanks for reviewing,
Best regards,
Fabrice

What is different that driver cannot work with new device using old
interface or old features?


Best regards,
Krzysztof