On 05/05/2024 09:36, Mithil wrote: > On Wed, Apr 17, 2024 at 7:33 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > >> How did this happen? I see this was in v1, but I am quite surprised to >> be listed here. I am for sure not a maintainer of this binding. Choose >> driver maintainers or platform maintainers, worse case. > > I might have overlooked this, will fix it. There is no driver > maintainer for it as far as I know. > Should I include the module author? Or platform maintainers or whoever is interested in this hardware. > >> Not much improved here. You miss $ref and optionally constraints. > Something like this > $ref: /schemas/types.yaml#/definitions/string > enum: [mcpdm] > Didnt really understand the "optionally constraints" part. Sorry, you stripped out *entire* context. No clue what you refer to. > >> Missing constraints, so replace it with maxItems: 1 > Similar to how clock-names are handled? > >> List the items. I asked to open existing bindings and take a look how it >> is there. Existing bindings would show you how we code this part. > clock-names: > items: > - const: pdmclk > minItems: 1 > maxItems: 1 > Something like this? No. Do you see code like this anywhere? Please only list the items, although without context impossible to judge. > >> Just one blank line. > Removed. > >> That's wrong address. Old code does not have 0. Please do no change >> parts of code without reason. If there is a reason, explain it in the >> changelog. >> > The checks were giving a warning if 0 was not included hence, I'll put > the real address if needed then. > >> Include header and use common defines for flags. Just like all other >> recent bindings. >> > There's no defines for them, this is how it is in the dts :( It does not matter whether some particular DTS uses values or defines, if these are the well known constants. Again, stripping entire context and replying after 2-3 weeks does not help me to understand this at all. Between these 2-3 weeks I got another 200 patches to review. Best regards, Krzysztof
