On Thu, Jun 10, 2021 at 04:00:39PM +0000, Enrico Weigelt, metux IT consult via Stratos-dev wrote:
On 10.06.21 15:22, Arnd Bergmann wrote:
Can you give an example of how this would be hooked up to other drivers using those gpios. Can you give an example of how using the "gpio-keys" or "gpio-leds" drivers in combination with virtio-gpio looks like in the DT?
Connecting between self-probing bus'es and DT is generally tricky. IMHO we don't have any generic mechanism for that.
DT does have a generic description of PCI endpoints, which virtio-iommu relies on to express the relation between IOMMU and endpoint nodes [1]. I think the problem here is similar: the client node needs a phandle to the GPIO controller which may use virtio-pci transport?
Note that it mostly works if the device is on the root PCI bus. Behind a bridge the OS may change the device's bus number as needed, so the BDF reference in DT is only valid if the software providing the DT description (VMM or firmware) initializes bus numbers accordingly (and I don't remember if Linux supports this case well).
Thanks, Jean
[1] Documentation/devicetree/bindings/virtio/iommu.txt
I've made a few attempts, but nothing practically useful, which would be accepted by the corresponding maintainers, yet. We'd either need some very special logic in DT probing or pseudo-bus'es for the mapping. (DT wants to do those connections via phandle's, which in turn need the referenced nodes to be present in the DT).
From what I can tell, both the mmio and pci variants of virtio can have their dev->of_node populated, but I don't see the logic in register_virtio_device() that looks up the of_node of the virtio_device that the of_gpio code then tries to refer to.
Have you ever successfully bound a virtio device via DT ?
--mtx
--
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu.
Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287 -- Stratos-dev mailing list Stratos-dev@op-lists.linaro.org https://op-lists.linaro.org/mailman/listinfo/stratos-dev
On Thu, Jun 10, 2021 at 7:03 PM Jean-Philippe Brucker jean-philippe@linaro.org wrote:
On Thu, Jun 10, 2021 at 04:00:39PM +0000, Enrico Weigelt, metux IT consult via Stratos-dev wrote:
On 10.06.21 15:22, Arnd Bergmann wrote:
Can you give an example of how this would be hooked up to other drivers using those gpios. Can you give an example of how using the "gpio-keys" or "gpio-leds" drivers in combination with virtio-gpio looks like in the DT?
Connecting between self-probing bus'es and DT is generally tricky. IMHO we don't have any generic mechanism for that.
DT does have a generic description of PCI endpoints, which virtio-iommu relies on to express the relation between IOMMU and endpoint nodes [1]. I think the problem here is similar: the client node needs a phandle to the GPIO controller which may use virtio-pci transport?
Right, the code to set dev->of_node is fairly simple, the device probe just needs to scan for child nodes. Aside from PCI, similar code exists for USB and MMC/SDIO, which are usually discoverable but sometimes need additional properties.
Note that it mostly works if the device is on the root PCI bus. Behind a bridge the OS may change the device's bus number as needed, so the BDF reference in DT is only valid if the software providing the DT description (VMM or firmware) initializes bus numbers accordingly (and I don't remember if Linux supports this case well).
I think you can mark the host bridge as "probe-only" to prevent the OS (at least Linux) from renumbering the buses.
The part I did not find though is assigning dev->of_node in the virtio_device to a child of the PCI device node.
Arnd
stratos-dev@op-lists.linaro.org
-
Arnd Bergmann -
Jean-Philippe Brucker