Thread (61 messages) 61 messages, 5 authors, 2022-07-14

Re: [PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node

From: Matthias Brugger <matthias.bgg@gmail.com>
Date: 2022-07-07 13:02:18
Also in: linux-devicetree, linux-mediatek, lkml


On 06/07/2022 16:38, Krzysztof Kozlowski wrote:
On 06/07/2022 15:48, Matthias Brugger wrote:
quoted

On 04/07/2022 14:36, Krzysztof Kozlowski wrote:
quoted
On 04/07/2022 12:00, Tinghan Shen wrote:
quoted
The max clock items for the dts node with compatible
'mediatek,mt8195-smi-sub-common' should be 3.

However, the dtbs_check of such node will get following message,
arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@14010000: clock-names: ['apb', 'smi', 'gals0'] is too long
           From schema: Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml

Remove the last 'else' checking to fix this error.
Missing fixes tag.
  From my understanding, fixes tags are for patches that fix bugs (hw is not
working etc) and not a warning message from dtbs_check. So my point of view
would be to not add a fixes tag here.
Not conforming to bindings is also a bug. Missing properties or wrong
properties, even if hardware is working, is still a bug. If such bug is
not visible now in Linux, might be visible later in the future or
visible in different OS (DTS are used by other systems and pieces of
software like bootloaders). Limiting this only to Linux and to current
version (hardware still works) is OK for Linux drivers, but not for DTS.
If a wrong DTS breaks software, then it's worth a fixes tag, especially for the 
DTS part, we could argue about the bindings part, but in that case it would be 
probably OK.
Therefore Fixes tag in general is applicable. Of course maybe to this
one not really, maybe this is too trivial, or whatever, so I do not
insist. But I insist on the principle - reasonable dtbs_check warnings
are like compiler warnings - bugs which have to be fixed.
I'm not arguing that these things shouldn't be fixed, but that they are worth 
being back-ported to the stable branches.

Regards,
Matthias

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help