Do you have anything more specific in mind? > > > + pwminv = 1; > > + > > This is silently overriding the module parameter. > > I don't think this is a good idea, at the very least not silently. I was thinking at the same, and in the end I do have proposed this solution in any case. Let's look at the 2 use cases in which the DT property and the module parameter are different. ## 1 module parameter pwminv=0 ti,pwm-inverted DT property present => we enable the PWM inversion I think this is fair, if someone has a DT based system we need to assume that the DT is correct. This is a HW configuration, not a module parameter. ## 2 module parameter pwminv=1 ti,pwm-inverted DT property absent => we enable the PWM inversion In this case the module parameter is overriding the DT. It means that someone explicitly set pwminv=1 module parameter. I think is fair to fulfill the module parameter request in this case, overriding the DT > I would suggest to add some logic in the probe function to set this value > and check its consistency. With that said I can implement something around the lines you proposed, if you still think is worth doing it. I would personally just keep the priority on the module parameter over the DT and add an info print on what is actually configured by the driver (not checking if they are different). Or I can just add a dev_info() telling the user about the actual PWM polarity used, making this more transparent, without changing the logic proposed here. Francesco
