Hello,
On Wed, Jan 29, 2025 at 01:34:28PM +0100, Krzysztof Kozlowski wrote:
> On 29/01/2025 13:19, Uwe Kleine-König wrote:
> > On Wed, Jan 29, 2025 at 10:27:22AM +0100, Krzysztof Kozlowski wrote:
> >> On 28/01/2025 18:29, Uwe Kleine-König wrote:
> > I tried
> >
> > dt-validate -m -u Documentation/devicetree/bindings -p ~/work/kbuild/arm/Documentation/devicetree/bindings/processed-schema.json ~/work/kbuild/arm/arch/arm/boot/dts/intel/socfpga/socfpga_cyclone5_de10nano.dtb
>
> That's unusual way of running the check, but of course might work.
This is what `make` does when running one of the dt check targets. I
didn't find a way to call this via make for just a single dtb.
> >>> + soc {
> >>> + fpga_axi: axi_h2f_lw_bridge@ff200000 {
> >>
> >> Follow DTS coding style. You just sent us something from downstream.
> >
> > Indeed this is from downstream. Looking at the matching dt-validate
> > output I guess just "axi@ff200000" would be appropriate?!
>
> bus@
ok.
> >>> + compatible = "simple-bus";
> >>> + reg = <0xff200000 0x00200000>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <1>;
> >>
> >> ranges would be after reg, but they are pointless here, no?
> >
> > I thought it's "compatible", "reg" at the start, "status" at the end and
> > the rest in-between in alphabetic order. What is the right ordering?
>
> DTS coding style could be clearer here. It exactly says what is the
> first, what is the second and what is the third.
I found Documentation/devicetree/bindings/dts-coding-style.rst now.
> >> Where is the child?
> >
> > I intend to add children using dt-overlays. I have a prototype here, but
> > that's still to embarrassing to show.
>
> The entire bus is in such case a bit confusing. If you have nothing
> connected here in the base board, does it really exist in FPGA bitstream?
I'm unsure. If I don't load an FPGA image, the machine boots fine but
IIRC accessing the address space results in an error. If I load an FPGA
image, its register space appears at that address. So technically it
might be ok to drop the node, but from a practical POV it's useful to
have it in the board.dtb to not have to create that note in each
overlay.
If that is good enough for you, I'll go with a comment in that node that
tells about the expectation that it will be filled using an overlay.
Best regards
Uwe
Attachment:
signature.asc
Description: PGP signature
