Re: [PATCH 1/2] dt-bindings: fpga: Convert bridge binding to yaml

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/9/24 09:15, Krzysztof Kozlowski wrote:
On 09/01/2024 09:06, Michal Simek wrote:


On 1/9/24 09:00, Krzysztof Kozlowski wrote:
On 09/01/2024 04:53, Xu Yilun wrote:
On Mon, Jan 08, 2024 at 10:16:17AM +0100, Michal Simek wrote:


On 1/8/24 10:09, Krzysztof Kozlowski wrote:
On 05/01/2024 17:04, Michal Simek wrote:
Convert the generic fpga bridge DT binding to json-schema.

Signed-off-by: Michal Simek <michal.simek@xxxxxxx>

+$id: http://devicetree.org/schemas/fpga/fpga-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FPGA Bridge
+
+maintainers:
+  - Michal Simek <michal.simek@xxxxxxx>
+
+properties:
+  $nodename:
+    pattern: "^fpga-bridge(@.*)?$"

Not sure, but maybe we need to allow fpga-bridge-1? Could we have more
than one bridge on given system?

Yilun: Any comment on this?

We can have more bridges, but IIUC people use fpga-bridge@0, fpga-bridge@0
to identify them. So the expression is OK to me.

So you claim unit address thus reg with some sort of bus address is a
requirement? Then "?" is not correct in that pattern.

I expect it is about that people are using fpga-bridge@0 but bridge is not on
the bus. Yilun said that reg property in altr,socfpga-fpga2sdram-bridge.yaml is
optional which means no reg property no @XXX in node name.
That's why I think that expression is correct. If there are more bridges without
reg property then I expect we need to get more examples to align expression.

If we allow node name without unit address, thus not being part of any
bus, then the only question is whether it is possible to have system
with more than two FPGA bridges. If the answer is "yes", which I think
is the case, then the pattern should already allow it:

(@[0-9a-f]+|-[0-9]+)?

Let's see what Yilun says. I am happy to align it. IIRC in our case bridge doesn't need to have reg interface because it can be handled via gpio. You can have multiple of them but doesn't make sense to allocate multiple gpios to handle it because they can connected in a chain that one gpio drives all of them (And I don't think we have ever been requested to write a driver for it).

Thanks,
Michal







[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux