Hi Krzysztof, Thanks for your clarification. We can remove the dt-binding file and use numbers in the DTS, appreciate if you can answer few additional questions: 1. Do you suggest adding all NPCM reset values to the NPCM reset document or the reset values should describe in the module documentation that uses it? 2. Some of the NPCM7XX document modules describe the reset value they use from the dt-binding for example: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/iio/adc/nuvoton%2Cnpcm750-adc.yaml#L61 If we remove the NPCM8XX dt-binding file should we describe the NPCM8XX values in the NPCM-ADC document file? Best regards, Tomer On Fri, 10 Jun 2022 at 12:55, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 10/06/2022 00:05, Tomer Maimon wrote: > > Hi Krzysztof, > > > > Sorry, but I thought the fix is only to add an explanation to the > > dt-binding file as was done in V2. > > > > The NPCM8XX binding is done in the same way as the NPCM7XX and both > > use the same reset driver and use the same reset method in upstreamed > > NPCM reset driver. > > > > Can you please explain again what you suggest to do? > > If you want abstract IDs, they must be abstract, so not representing > hardware registers. Then they start at 1 and are incremented by 1. > > Other option is to skip such IDs entirely and use register > offsets/addresses directly, like Arnd suggested in linked documents. I > think he expressed it clearly, so please read his answers which I linked > in previous discussion. > > There is no single reason to store register addresses/values/offsets as > binding headers. These are not bindings. > > Best regards, > Krzysztof
