Indentation suggestion

	COND_CODE_1(DT_INST_NODE_HAS_PROP(inst, st_power_mode),			\
		    (CONCAT(LL_COMP_POWERMODE_,					\
			    DT_INST_STRING_TOKEN(inst, st_power_mode))),	\
		    (0))

Could we leave it as it is? There are already style checks successfully running CI. In my EXTI driver PR there were already a long description, why and how other interpretations than in CI are pretty subjective and could have different outcomes.

I agree this is not a blocking issue. Yet, it would make the code more readable for others and from a maintenance perspective.

This is pretty common reason for such request - readability of the code :) But. There is a big interpretation difference. GitHub is know for showing the code with own indentations and thus the code may look different than checked one in the editor. The root folder of zephyr project contains.editorconfig - this file defines also for vscode how to display tabs and spaces. Also any other ide shall show you same code style. Therefore please do not rely just on that, GitHub shows you. I can assure you - you will see different visual representation as soon as you open it in vim or vscode.

Please take a look here: #85508 (comment)
So far I remember, I used to use .editorconfig.

@erwango Nice. Thnx.

Therefore please do not rely just on that, GitHub shows you. I can assure you - you will see different visual representation as soon as you open it in vim or vscode.

I fully agree :-) Personally use vim over various SW projects each with its own style preferences.
I don't know if Github can be tuned to adapt the tab size to the project being sourced.

There are already style checks successfully running CI.

Despite CI Compliance Checks processing reports many issues, it does not address all of them.
In the end, I think what's best is what makes the implementation easier to understand.

@etienne-lms He he. Here we come to the next problem: How shall I adapt the visual appearance of the code, if that, what you see is different than, what I see? I think this could be major point of disagreement. Therefore I prefer to leave this job to proper CI configuration. No CI complaints - the code is good with allowed freedom interpretation range of the creator.

@etienne-lms BTW: I could highly recommend https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig if you use vscode with zephyr and 8 in #96325 (comment)

Well, leave as is if you prefer. That said, as-is tend to show CONCAT() operates on 3 arguments, while it's rather COND_CODE_1() that does.
Not a blocking issue.

Suggested change

	WRITE_BIT(comp->CSR, 1, cfg->miller_effect_hold_disable);
	WRITE_BIT(comp->CSR, 1, cfg->miller_effect_hold_disable ? 0 : 1);

This makes no sense. The macro is already doing exactly same check.

Maybe I'm wrong but miller_effect_hold_disable is true/1 when set in which case the bit shall be cleared, while if the property is not set you expect the bit to be set.

Here is a reverse logic. Please try to print csr register value before and after writing, to see if it that, what to expect.

Do you mean with st,miller-effect-hold-disable property not being set (which is G4 default config), comp->CSR bit 1 is set by the above implementation?

No. I've tested it like this:

1. No st,miller-effect-hold-disable in .overlay is present - gives CSR bit 1 staying 0.

2.st,miller-effect-hold-disable present gives CSR bit 1 being 1.

But I see discussion necessary. Thnx for it. It would be great if you try to test it your own.

Sorry to insist. As stated in your YAML, the property shall be set to:

  Disable undocumented hold feature (COMP_CxCSR bit 1).

Implicitly, if the property is not set, we would expect that the bit is set which must be done here since the COMP_CxCSR register is 0 at reset.

I see the logic as:

1. No st,miller-effect-hold-disable in .overlay is present gives CSR bit 1 is set to 1.
2. st,miller-effect-hold-disable present gives CSR bit 1 is cleared to 0 (which is the reset value).

Maybe @erwan's comment #96325 (comment) was misunderstood.

Let me step back:

1. Originally you proposed a boolean property st,miller-effect-hold-enable to enable this anti-Miller-effect feature on stm32g4xx SoCs COMP.
2. (edited: I've added this step) I proposed it is default enable at SoC level leaving boards overlay to disable it. However disabling a default enable boolean property would mean board overlay should use /delete-property/, not nice.
3. Therefore I suggested to use an int property, defaulted to 1 for G4 SoCs, allowing overlay to set it to 0.
4. Ewarn's comment was that since it's a boolean info, it's weird it is not a bool property. So, in order to be able to default enable the feature it and leave overlay to disable the feature, let's invert the config logic and use a boolean property, st,miller-effect-hold-disable:

• DT property is default not set to have CSR bit 1 set and Miller effect addressed.
• DT overlay files can set the property when the target does not want to compensate this Miller effect (and have CSR bit set to 0)

Our apologies for the possible confusion and mine especially for requesting you to change your P-R back and forth.

Maybe @erwan's comment #96325 (comment) was misunderstood.

Let me step back:

1. Originally you proposed a boolean property st,miller-effect-hold-enable to enable this anti-Miller-effect feature on stm32g4xx SoCs COMP.
2. (edited: I've added this step) I proposed it is default enable at SoC level leaving boards overlay to disable it. However disabling a default enable boolean property would mean board overlay should use /delete-property/, not nice.
3. Therefore I suggested to use an int property, defaulted to 1 for G4 SoCs, allowing overlay to set it to 0.
4. Ewarn's comment was that since it's a boolean info, it's weird it is not a bool property. So, in order to be able to default enable the feature it and leave overlay to disable the feature, let's invert the config logic and use a boolean property, st,miller-effect-hold-disable:

• DT property is default not set to have CSR bit 1 set and Miller effect addressed.
• DT overlay files can set the property when the target does not want to compensate this Miller effect (and have CSR bit set to 0)

Our apologies for the possible confusion and mine especially for requesting you to change your P-R back and forth.

Thank you for putting pieces together. Changing PR back-and-forth is fine, if you provide me strong arguments. I see now problem on my side 😄
In that case your suggestion from above makes totally sense. I'e applied it and extended description in .yml. Please take a look.

Could you add an empty line below?

done

I think you forgot to add it.

I've added it after line 309 (see above). Maybe code suggestion would be better next time.

I think you forgot to add it.

Well, leave as is if you prefer. That said, as-is tend to show CONCAT() operates on 3 arguments, while it's rather COND_CODE_1() that does.
Not a blocking issue.