pci: Support parsing PCI controller DT subnodes
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/pci/pci-uclass.c +14 -0
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;
@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ; + } + } + *devp = dev;return 0 ; }
Signature · 1 line
2.16.2
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 29 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +2
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data;
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 10 lines
drivers/pci/pci-uclass.c +10
-0+ +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ; + }
The function pci_find_and_bind_driver() is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 in arch/x86/dts/crownbay.dts.
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent,
Quoted 6 lines
drivers/pci/pci-uclass.c +2
-1+ } + *devp = dev;return 0 ; } --
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;
Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check r8a7794.dtsi for the PCI devices I use.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.
Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.
I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 54 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 49 lines · Bin Meng
Hi Marek,
Quoted 29 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +2
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data;drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 10 lines
drivers/pci/pci-uclass.c +10
-0+ +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ; + }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.
Quoted 6 lines
Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 59 lines · Marek Vasut
Quoted 58 lines · Bin Meng
Hi Marek,
Quoted 54 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.
Quoted 6 lines
Quoted 2 lines
I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 6 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Sorry this is a hack to current U-Boot implementation, not fix. The fix should be adding "ehci-pci" compatible string in the r8a7794.dtsi.
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with. As you said, DT is just a standard to describe hardware and hardware only. But there are various methods to describe hardware in DT that's why we have a proper defined bindings in Linux. How OS parses and utilizes these information is completely on their own.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 77 lines · Bin Meng
Hi Marek,
Quoted 74 lines · Marek Vasut
Quoted 72 lines · Bin Meng
Hi Marek,
Quoted 59 lines · Marek Vasut
Quoted 58 lines · Bin Meng
Hi Marek,
Quoted 54 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.Quoted 6 lines
Quoted 2 lines
I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 8 lines
Quoted 6 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.
Wrong. The DT is perfectly valid as is.
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 4 lines
As you said, DT is just
a standard to describe hardware and hardware only. But there are various methods to describe hardware in DT that's why we have a proper defined bindings in Linux.
defined bindings, yes. In Linux ... no ... the HW is OS-independent, so is it's description in DT.
Quoted 6 lines
How OS parses and utilizes these
information is completely on their own.Regards,
Bin
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 85 lines · Marek Vasut
Quoted 84 lines · Bin Meng
Hi Marek,
Quoted 80 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
Quoted 1 line
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Wrong. The DT is perfectly valid as is.
I did not say r8a7794.dtsi is invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism.
/* Find this device in the device tree */
ret = pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);
/* If nothing in the device tree, bind a device */ if (ret == -ENODEV) {
...
ret = pci_find_and_bind_driver(bus, &find_id, bdf,
&dev); }
Your patch adds some codes in pci_find_and_bind_driver() to touch DT, which is not the function supposed to do. Hence I call it a hack.
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Quoted 12 lines
Quoted 5 lines
As you said, DT is just
a standard to describe hardware and hardware only. But there are various methods to describe hardware in DT that's why we have a proper defined bindings in Linux.defined bindings, yes. In Linux ... no ... the HW is OS-independent, so is it's description in DT.
Quoted 3 lines
How OS parses and utilizes these
information is completely on their own.
[1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2
[2] http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 94 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 77 lines · Bin Meng
Hi Marek,
Quoted 74 lines · Marek Vasut
Quoted 72 lines · Bin Meng
Hi Marek,
Quoted 59 lines · Marek Vasut
Quoted 58 lines · Bin Meng
Hi Marek,
Quoted 54 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.Quoted 6 lines
Quoted 2 lines
I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 8 lines
Quoted 6 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.
Quoted 8 lines
Quoted 2 lines
Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]
Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...
Yes, "recommended" . The compatible string is not a hard requirement.
Quoted 14 lines
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
Quoted 17 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,
Quoted 5 lines
&dev); }Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.
You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
Mind you, pci_find_and_bind_driver() seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
Quoted 18 lines
Quoted 11 lines
Quoted 4 lines
As you said, DT is just
a standard to describe hardware and hardware only. But there are various methods to describe hardware in DT that's why we have a proper defined bindings in Linux.defined bindings, yes. In Linux ... no ... the HW is OS-independent, so is it's description in DT.
Quoted 3 lines
How OS parses and utilizes these
information is completely on their own.[1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2
[2] http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdfRegards,
Bin
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 104 lines · Marek Vasut
Quoted 94 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 77 lines · Bin Meng
Hi Marek,
Quoted 74 lines · Marek Vasut
Quoted 72 lines · Bin Meng
Hi Marek,
Quoted 59 lines · Marek Vasut
Quoted 58 lines · Bin Meng
Hi Marek,
Quoted 54 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.Quoted 6 lines
Quoted 2 lines
I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 8 lines
Quoted 6 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Quoted 8 lines
Quoted 2 lines
Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]
Quoted 4 lines
Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
It's not a bug of U-Boot implementation. U-Boot DM was designed this way. If you are in U-Boot, you must follow U-Boot's rule. And I don't see current DM is a wrong design.
Quoted 12 lines
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...
Quoted 1 line
Yes, "recommended" . The compatible string is not a hard requirement.
OK, since you mentioned "recommended", let me paste the bullet 2 from the same spec:
Some recommended practices include:
1. Define a compatible string using the conventions described in section 2.3.1.
2. Use the standard properties (defined in sections 2.3 and 2.4) as applicable for the new device. This usage typically includes the *reg* and interrupts properties at a minimum.
3. Use the conventions specified in section 4 (Device Bindings) if the new device fits into one the DTSpec defined device classes
...
Bullet 2 says: This usage *typically* includes the *reg* and interrupts properties at a minimum. That means "reg" is not mandatory.
And now let's see this patch:
df = ofnode_get_addr_size(node, "reg", &size);
Who says a node must have a "reg" property? Using this as a sign to attach to DT is definitely wrong.
Quoted 29 lines
Quoted 15 lines
Quoted 9 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...
Quoted 4 lines
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
You can't say adding an optional "compatible" is wrong either. Being optional means an implementation can choose to support it according to its needs. U-Boot's DM was designed to use "compatible" when it comes to device binding.
Quoted 20 lines
Quoted 20 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,&dev); }
Quoted 7 lines
Quoted 2 lines
Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
My suggestion was in the first reply: adding "compatible" string in the USB nodes.
Quoted 13 lines
Mind you,
pci_find_and_bind_driver()seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 9 lines
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
Again, I don't see this is a bug in the U-Boot PCI codes. The scenario of your board has been supported by U-Boot already. You keep saying "Linux can parse DT correctly" and "U-Boot cannot parse a valid DT", which makes no sense to me:
1. U-Boot can parse DT correctly. Parse means decoding device tree information to U-Boot's internal structure.
2. U-Boot usage of DT is perfectly valid too. How U-Boot uses these information in its internal structure is implementation-specific.
Quoted 3 lines
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
What _all the details_? Are you saying that U-Boot should follow Linux's device driver framework, to parse DT and use DT exactly the same way as Linux? Sorry this is terribly wrong. Imagine someone writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.
Regards,
Bin
Marek Vasut
NAKPATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/09/2018 11:41 AM, Bin Meng wrote:
[...]
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Quoted 8 lines
Quoted 1 line
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]
Quoted 7 lines
Quoted 4 lines
Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
It's not a bug of U-Boot implementation. U-Boot DM was designed this way.
Then the design is flawed. (and btw. the U-Boot DM was not designed that way, you can take my word for it :-) )
Quoted 2 lines
If you are in U-Boot, you must follow U-Boot's rule. And I don't see current DM is a wrong design.
Wrong, U-Boot is given some hardware to run on and a matching description, DT. If both are valid and U-Boot cannot operate on them, then U-Boot is broken and must be fixed.
You cannot claim that just because U-Boot behaves in some way, a perfectly good hardware and/or it's description is wrong and needs to be adjusted. That makes no sense.
Just assume the DT is in ROM, it's set in stone and it cannot be changed. Then the entire discussion below becomes pointless and we can focus on fixing U-Boot such that it'd be able to parse the DT properly.
Quoted 29 lines
Quoted 12 lines
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...Quoted 1 line
Yes, "recommended" . The compatible string is not a hard requirement.
OK, since you mentioned "recommended", let me paste the bullet 2 from the same spec:
Some recommended practices include:
1. Define a compatible string using the conventions described in section 2.3.1.
2. Use the standard properties (defined in sections 2.3 and 2.4) as applicable for the new device. This usage typically includes the *reg* and interrupts properties at a minimum.
3. Use the conventions specified in section 4 (Device Bindings) if the new device fits into one the DTSpec defined device classes
...Bullet 2 says: This usage *typically* includes the *reg* and interrupts properties at a minimum. That means "reg" is not mandatory.
Quoted 6 lines
And now let's see this patch:
df = ofnode_get_addr_size(node, "reg", &size);Who says a node must have a "reg" property? Using this as a sign to attach to DT is definitely wrong.
If there is no "reg" property, then you won't get a node associated with the driver instance and that's perfectly fine. Without the "reg" prop, you cannot figure out which PCI device/function the node describes, so how could you possibly associate the node with a driver instance ? You cannot.
Quoted 33 lines
Quoted 28 lines
Quoted 14 lines
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...Quoted 4 lines
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
Quoted 4 lines
You can't say adding an optional "compatible" is wrong either. Being optional means an implementation can choose to support it according to its needs. U-Boot's DM was designed to use "compatible" when it comes to device binding.
Please assume the DT is in ROM and it cannot be modified.
Again, that's not how U-Boot DM was designed, DM is independent of DT, but discussing that is really off-topic here.
Quoted 23 lines
Quoted 23 lines
Quoted 22 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,&dev); }Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.
Quoted 7 lines
Quoted 4 lines
You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
My suggestion was in the first reply: adding "compatible" string in the USB nodes.
NAK, that's a hack to work around broken U-Boot code. Unacceptable, I will not modify the DT for that reason.
Furthermore, the PCI code should match based on PCI ID or class, forcing a compatible could cause problems in case someone exchanges the PCI device and doesn't update the DT, which may not be possible (ROM). Adding the compatible also defeats the PnP behavior of PCI.
Quoted 28 lines
Quoted 13 lines
Mind you,
pci_find_and_bind_driver()seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 9 lines
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
Again, I don't see this is a bug in the U-Boot PCI codes. The scenario of your board has been supported by U-Boot already. You keep saying "Linux can parse DT correctly" and "U-Boot cannot parse a valid DT", which makes no sense to me:
Quoted 4 lines
1. U-Boot can parse DT correctly. Parse means decoding device tree information to U-Boot's internal structure.
2. U-Boot usage of DT is perfectly valid too. How U-Boot uses these information in its internal structure is implementation-specific.
That's good and all, but somehow the PCI controller subnodes are not associated with the driver in case they are described in the DT. Thus, U-Boot is not parsing the valid DT completely/correctly.
Quoted 7 lines
Quoted 3 lines
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
What
_allthedetails_? Are you saying that U-Boot should follow Linux's device driver framework, to parse DT and use DT exactly the same way as Linux?
No, I am saying U-Boot should be able to extract necessary information from a valid DT. How that happens is up to U-Boot. This is not happening currently and thus U-Boot needs to be fixed.
Quoted 7 lines
Sorry this is terribly wrong. Imagine someone
writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.
There is supposed to be only one DT for all the OSes, which has nothing to do with Linux or U-Boot or any of those. If some OS cannot parse an valid DT completely, then it's lacking.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 24 lines · Marek Vasut
On 08/09/2018 11:41 AM, Bin Meng wrote:
[...]
Quoted 20 lines
Quoted 19 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Quoted 8 lines
Quoted 2 lines
Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
Quoted 6 lines
Quoted 2 lines
It's not a bug of U-Boot implementation. U-Boot DM was designed this way.
Then the design is flawed. (and btw. the U-Boot DM was not designed that way, you can take my word for it :-) )
Then please propose something that that is not flawed. But this patch is not a fix to the design, but a hack.
Quoted 11 lines
Quoted 2 lines
If you are in U-Boot, you must follow U-Boot's rule. And I don't see current DM is a wrong design.
Wrong, U-Boot is given some hardware to run on and a matching description, DT. If both are valid and U-Boot cannot operate on them, then U-Boot is broken and must be fixed.
You cannot claim that just because U-Boot behaves in some way, a perfectly good hardware and/or it's description is wrong and needs to be adjusted. That makes no sense.
Again, who said current dts is *invalid*? You keep saying "valid", "valid"... Can you explain why adding a perfectly OK "compatible" string suddenly makes the DT invalid?
Quoted 4 lines
Just assume the DT is in ROM, it's set in stone and it cannot be changed. Then the entire discussion below becomes pointless and we can focus on fixing U-Boot such that it'd be able to parse the DT properly.
Sometimes we have to update DT as not every working DT is born from day 1.
Quoted 33 lines
Quoted 33 lines
Quoted 12 lines
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...Quoted 1 line
Yes, "recommended" . The compatible string is not a hard requirement.
OK, since you mentioned "recommended", let me paste the bullet 2 from the same spec:
Some recommended practices include:
1. Define a compatible string using the conventions described in section 2.3.1.
2. Use the standard properties (defined in sections 2.3 and 2.4) as applicable for the new device. This usage typically includes the *reg* and interrupts properties at a minimum.
3. Use the conventions specified in section 4 (Device Bindings) if the new device fits into one the DTSpec defined device classes
...Bullet 2 says: This usage *typically* includes the *reg* and interrupts properties at a minimum. That means "reg" is not mandatory.
And now let's see this patch:
df = ofnode_get_addr_size(node, "reg", &size);
Quoted 9 lines
Quoted 2 lines
Who says a node must have a "reg" property? Using this as a sign to attach to DT is definitely wrong.
If there is no "reg" property, then you won't get a node associated with the driver instance and that's perfectly fine. Without the "reg" prop, you cannot figure out which PCI device/function the node describes, so how could you possibly associate the node with a driver instance ? You cannot.
This is a hack. I said many times if you add a "compatible" string DM create the device node for you.
Quoted 139 lines
Quoted 33 lines
Quoted 28 lines
Quoted 14 lines
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...Quoted 4 lines
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
Quoted 4 lines
You can't say adding an optional "compatible" is wrong either. Being optional means an implementation can choose to support it according to its needs. U-Boot's DM was designed to use "compatible" when it comes to device binding.
Please assume the DT is in ROM and it cannot be modified.
Again, that's not how U-Boot DM was designed, DM is independent of DT, but discussing that is really off-topic here.
Quoted 23 lines
Quoted 23 lines
Quoted 22 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,&dev); }Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.Quoted 7 lines
Quoted 4 lines
You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
My suggestion was in the first reply: adding "compatible" string in the USB nodes.
NAK, that's a hack to work around broken U-Boot code. Unacceptable, I will not modify the DT for that reason.
Furthermore, the PCI code should match based on PCI ID or class, forcing a compatible could cause problems in case someone exchanges the PCI device and doesn't update the DT, which may not be possible (ROM). Adding the compatible also defeats the PnP behavior of PCI.
Quoted 28 lines
Quoted 13 lines
Mind you,
pci_find_and_bind_driver()seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 9 lines
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
Again, I don't see this is a bug in the U-Boot PCI codes. The scenario of your board has been supported by U-Boot already. You keep saying "Linux can parse DT correctly" and "U-Boot cannot parse a valid DT", which makes no sense to me:
Quoted 4 lines
1. U-Boot can parse DT correctly. Parse means decoding device tree information to U-Boot's internal structure.
2. U-Boot usage of DT is perfectly valid too. How U-Boot uses these information in its internal structure is implementation-specific.That's good and all, but somehow the PCI controller subnodes are not associated with the driver in case they are described in the DT. Thus, U-Boot is not parsing the valid DT completely/correctly.
Quoted 7 lines
Quoted 3 lines
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
What
_allthedetails_? Are you saying that U-Boot should follow Linux's device driver framework, to parse DT and use DT exactly the same way as Linux?No, I am saying U-Boot should be able to extract necessary information from a valid DT. How that happens is up to U-Boot. This is not happening currently and thus U-Boot needs to be fixed.
Quoted 7 lines
Sorry this is terribly wrong. Imagine someone
writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.
Quoted 3 lines
There is supposed to be only one DT for all the OSes, which has nothing to do with Linux or U-Boot or any of those. If some OS cannot parse an valid DT completely, then it's lacking.
I really don't understand such obsessiveness. Currently there is NO ALL OSes. There is ONLY Linux. What you kept talking about is the reference implementation from Linux. You need convince me adding a compatible string to the USB node makes the DT invalid. If you admit adding "compatible" is perfectly OK, then per your theory Linux should handle it without any problems. Next step is to upstream the DT changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 30 lines · Bin Meng
Hi Marek,
Quoted 27 lines · Marek Vasut
On 08/09/2018 11:41 AM, Bin Meng wrote:
[...]
Quoted 22 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Quoted 8 lines
Quoted 2 lines
Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]Quoted 4 lines
Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
It's not a bug of U-Boot implementation. U-Boot DM was designed this way.
Quoted 6 lines
Quoted 3 lines
Then the design is flawed. (and btw. the U-Boot DM was not designed that way, you can take my word for it :-) )
Then please propose something that that is not flawed. But this patch is not a fix to the design, but a hack.
You are mixing two things in this answer, so it makes no sense. Anyway, let me just stop you here, DM was not designed in such a way, period.
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
If you are in U-Boot, you must follow U-Boot's rule. And I don't see current DM is a wrong design.
Wrong, U-Boot is given some hardware to run on and a matching description, DT. If both are valid and U-Boot cannot operate on them, then U-Boot is broken and must be fixed.
Quoted 8 lines
Quoted 4 lines
You cannot claim that just because U-Boot behaves in some way, a perfectly good hardware and/or it's description is wrong and needs to be adjusted. That makes no sense.
Again, who said current dts is *invalid*? You keep saying "valid", "valid"... Can you explain why adding a perfectly OK "compatible" string suddenly makes the DT invalid?
Adding a compatible to DT may or may not make it invalid.
Yet, the DT at hand is valid already, so adding extra crap into it just to work around buggy or incomplete implementation of PCI DT parsing is not an option.
Quoted 6 lines
Quoted 4 lines
Just assume the DT is in ROM, it's set in stone and it cannot be changed. Then the entire discussion below becomes pointless and we can focus on fixing U-Boot such that it'd be able to parse the DT properly.
Sometimes we have to update DT as not every working DT is born from day 1.
This DT at hand is working and valid. It cannot and will not be updated only because U-Boot PCI implementation is lacking.
Quoted 43 lines
Quoted 33 lines
Quoted 33 lines
Quoted 12 lines
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...Quoted 1 line
Yes, "recommended" . The compatible string is not a hard requirement.
OK, since you mentioned "recommended", let me paste the bullet 2 from the same spec:
Some recommended practices include:
1. Define a compatible string using the conventions described in section 2.3.1.
2. Use the standard properties (defined in sections 2.3 and 2.4) as applicable for the new device. This usage typically includes the *reg* and interrupts properties at a minimum.
3. Use the conventions specified in section 4 (Device Bindings) if the new device fits into one the DTSpec defined device classes
...Bullet 2 says: This usage *typically* includes the *reg* and interrupts properties at a minimum. That means "reg" is not mandatory.
And now let's see this patch:
df = ofnode_get_addr_size(node, "reg", &size);Quoted 9 lines
Quoted 2 lines
Who says a node must have a "reg" property? Using this as a sign to attach to DT is definitely wrong.
If there is no "reg" property, then you won't get a node associated with the driver instance and that's perfectly fine. Without the "reg" prop, you cannot figure out which PCI device/function the node describes, so how could you possibly associate the node with a driver instance ? You cannot.
Quoted 2 lines
This is a hack. I said many times if you add a "compatible" string DM create the device node for you.
I explained many times that the DT will not be updated to work around lacking implementation of PCI DT parsing in U-Boot. The DT is perfectly fine as-is.
I also explained already that the PCI ID or class is perfectly sufficient to match the driver on.
Quoted 139 lines
Quoted 139 lines
Quoted 33 lines
Quoted 28 lines
Quoted 14 lines
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...Quoted 4 lines
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
Quoted 4 lines
You can't say adding an optional "compatible" is wrong either. Being optional means an implementation can choose to support it according to its needs. U-Boot's DM was designed to use "compatible" when it comes to device binding.
Please assume the DT is in ROM and it cannot be modified.
Again, that's not how U-Boot DM was designed, DM is independent of DT, but discussing that is really off-topic here.
Quoted 23 lines
Quoted 23 lines
Quoted 22 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,&dev); }Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.Quoted 7 lines
Quoted 4 lines
You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
My suggestion was in the first reply: adding "compatible" string in the USB nodes.
NAK, that's a hack to work around broken U-Boot code. Unacceptable, I will not modify the DT for that reason.
Furthermore, the PCI code should match based on PCI ID or class, forcing a compatible could cause problems in case someone exchanges the PCI device and doesn't update the DT, which may not be possible (ROM). Adding the compatible also defeats the PnP behavior of PCI.
Quoted 28 lines
Quoted 13 lines
Mind you,
pci_find_and_bind_driver()seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 9 lines
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
Again, I don't see this is a bug in the U-Boot PCI codes. The scenario of your board has been supported by U-Boot already. You keep saying "Linux can parse DT correctly" and "U-Boot cannot parse a valid DT", which makes no sense to me:
Quoted 4 lines
1. U-Boot can parse DT correctly. Parse means decoding device tree information to U-Boot's internal structure.
2. U-Boot usage of DT is perfectly valid too. How U-Boot uses these information in its internal structure is implementation-specific.That's good and all, but somehow the PCI controller subnodes are not associated with the driver in case they are described in the DT. Thus, U-Boot is not parsing the valid DT completely/correctly.
Quoted 7 lines
Quoted 3 lines
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
What
_allthedetails_? Are you saying that U-Boot should follow Linux's device driver framework, to parse DT and use DT exactly the same way as Linux?No, I am saying U-Boot should be able to extract necessary information from a valid DT. How that happens is up to U-Boot. This is not happening currently and thus U-Boot needs to be fixed.
Quoted 7 lines
Sorry this is terribly wrong. Imagine someone
writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.
Quoted 5 lines
Quoted 3 lines
There is supposed to be only one DT for all the OSes, which has nothing to do with Linux or U-Boot or any of those. If some OS cannot parse an valid DT completely, then it's lacking.
I really don't understand such obsessiveness.
I can say the same thing, I don't understand why you're trying so hard to protect the lacking PCI DT parsing code in U-Boot. That is the part which needs to be fixed.
Quoted 2 lines
Currently there is NO
ALL OSes. There is ONLY Linux.
Er, no. You forgot all the BSDs, SunOS and possibly a few others I forgot.
Quoted 5 lines
What you kept talking about is the
reference implementation from Linux. You need convince me adding a compatible string to the USB node makes the DT invalid. If you admit adding "compatible" is perfectly OK, then per your theory Linux should handle it without any problems.
I think I lost you here. I won't pollute this thread with even more crap. USB is a probable bus, just like PCI, you don't need compatible strings there either.
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.
This is not gonna happen.
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 271 lines · Marek Vasut
Quoted 30 lines · Bin Meng
Hi Marek,
Quoted 27 lines · Marek Vasut
On 08/09/2018 11:41 AM, Bin Meng wrote:
[...]
Quoted 22 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Quoted 8 lines
Quoted 2 lines
Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]Quoted 4 lines
Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
It's not a bug of U-Boot implementation. U-Boot DM was designed this way.
Quoted 6 lines
Quoted 3 lines
Then the design is flawed. (and btw. the U-Boot DM was not designed that way, you can take my word for it :-) )
Then please propose something that that is not flawed. But this patch is not a fix to the design, but a hack.
You are mixing two things in this answer, so it makes no sense. Anyway, let me just stop you here, DM was not designed in such a way, period.
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
If you are in U-Boot, you must follow U-Boot's rule. And I don't see current DM is a wrong design.
Wrong, U-Boot is given some hardware to run on and a matching description, DT. If both are valid and U-Boot cannot operate on them, then U-Boot is broken and must be fixed.
Quoted 8 lines
Quoted 4 lines
You cannot claim that just because U-Boot behaves in some way, a perfectly good hardware and/or it's description is wrong and needs to be adjusted. That makes no sense.
Again, who said current dts is *invalid*? You keep saying "valid", "valid"... Can you explain why adding a perfectly OK "compatible" string suddenly makes the DT invalid?
Adding a compatible to DT may or may not make it invalid.
Yet, the DT at hand is valid already, so adding extra crap into it just to work around buggy or incomplete implementation of PCI DT parsing is not an option.
Quoted 6 lines
Quoted 4 lines
Just assume the DT is in ROM, it's set in stone and it cannot be changed. Then the entire discussion below becomes pointless and we can focus on fixing U-Boot such that it'd be able to parse the DT properly.
Sometimes we have to update DT as not every working DT is born from day 1.
This DT at hand is working and valid. It cannot and will not be updated only because U-Boot PCI implementation is lacking.
Quoted 43 lines
Quoted 33 lines
Quoted 33 lines
Quoted 12 lines
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...Quoted 1 line
Yes, "recommended" . The compatible string is not a hard requirement.
OK, since you mentioned "recommended", let me paste the bullet 2 from the same spec:
Some recommended practices include:
1. Define a compatible string using the conventions described in section 2.3.1.
2. Use the standard properties (defined in sections 2.3 and 2.4) as applicable for the new device. This usage typically includes the *reg* and interrupts properties at a minimum.
3. Use the conventions specified in section 4 (Device Bindings) if the new device fits into one the DTSpec defined device classes
...Bullet 2 says: This usage *typically* includes the *reg* and interrupts properties at a minimum. That means "reg" is not mandatory.
And now let's see this patch:
df = ofnode_get_addr_size(node, "reg", &size);Quoted 9 lines
Quoted 2 lines
Who says a node must have a "reg" property? Using this as a sign to attach to DT is definitely wrong.
If there is no "reg" property, then you won't get a node associated with the driver instance and that's perfectly fine. Without the "reg" prop, you cannot figure out which PCI device/function the node describes, so how could you possibly associate the node with a driver instance ? You cannot.
Quoted 2 lines
This is a hack. I said many times if you add a "compatible" string DM create the device node for you.
I explained many times that the DT will not be updated to work around lacking implementation of PCI DT parsing in U-Boot. The DT is perfectly fine as-is.
I also explained already that the PCI ID or class is perfectly sufficient to match the driver on.
Quoted 139 lines
Quoted 139 lines
Quoted 33 lines
Quoted 28 lines
Quoted 14 lines
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...Quoted 4 lines
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
Quoted 4 lines
You can't say adding an optional "compatible" is wrong either. Being optional means an implementation can choose to support it according to its needs. U-Boot's DM was designed to use "compatible" when it comes to device binding.
Please assume the DT is in ROM and it cannot be modified.
Again, that's not how U-Boot DM was designed, DM is independent of DT, but discussing that is really off-topic here.
Quoted 23 lines
Quoted 23 lines
Quoted 22 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,&dev); }Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.Quoted 7 lines
Quoted 4 lines
You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
My suggestion was in the first reply: adding "compatible" string in the USB nodes.
NAK, that's a hack to work around broken U-Boot code. Unacceptable, I will not modify the DT for that reason.
Furthermore, the PCI code should match based on PCI ID or class, forcing a compatible could cause problems in case someone exchanges the PCI device and doesn't update the DT, which may not be possible (ROM). Adding the compatible also defeats the PnP behavior of PCI.
Quoted 28 lines
Quoted 13 lines
Mind you,
pci_find_and_bind_driver()seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 9 lines
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
Again, I don't see this is a bug in the U-Boot PCI codes. The scenario of your board has been supported by U-Boot already. You keep saying "Linux can parse DT correctly" and "U-Boot cannot parse a valid DT", which makes no sense to me:
Quoted 4 lines
1. U-Boot can parse DT correctly. Parse means decoding device tree information to U-Boot's internal structure.
2. U-Boot usage of DT is perfectly valid too. How U-Boot uses these information in its internal structure is implementation-specific.That's good and all, but somehow the PCI controller subnodes are not associated with the driver in case they are described in the DT. Thus, U-Boot is not parsing the valid DT completely/correctly.
Quoted 7 lines
Quoted 3 lines
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
What
_allthedetails_? Are you saying that U-Boot should follow Linux's device driver framework, to parse DT and use DT exactly the same way as Linux?No, I am saying U-Boot should be able to extract necessary information from a valid DT. How that happens is up to U-Boot. This is not happening currently and thus U-Boot needs to be fixed.
Quoted 7 lines
Sorry this is terribly wrong. Imagine someone
writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.Quoted 5 lines
Quoted 3 lines
There is supposed to be only one DT for all the OSes, which has nothing to do with Linux or U-Boot or any of those. If some OS cannot parse an valid DT completely, then it's lacking.
I really don't understand such obsessiveness.
Quoted 8 lines
I can say the same thing, I don't understand why you're trying so hard to protect the lacking PCI DT parsing code in U-Boot. That is the part which needs to be fixed.
Quoted 2 lines
Currently there is NO
ALL OSes. There is ONLY Linux.Er, no. You forgot all the BSDs, SunOS and possibly a few others I forgot.
In fact, I didn't. I compared many dts files in BSD source codes against the dts files in Linux tree (with the same name, for the same board), and they _are_ unsurprisingly different. Some of nodes indeed have "compatible" string while the other one does not, which reveals the truth that what you kept saying all OSes should use exactly the same DT is purely wrong. You are too Linux-centric.
Quoted 11 lines
Quoted 6 lines
What you kept talking about is the
reference implementation from Linux. You need convince me adding a compatible string to the USB node makes the DT invalid. If you admit adding "compatible" is perfectly OK, then per your theory Linux should handle it without any problems.I think I lost you here. I won't pollute this thread with even more crap. USB is a probable bus, just like PCI, you don't need compatible strings there either.
Didn't you see the "PCI Bus Binding" spec? It's a spec existing for years.
Quoted 4 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.
Quoted 9 lines
This is not gonna happen.
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
The fix in this patch is purely hack, period.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 281 lines · Bin Meng
Hi Marek,
Quoted 278 lines · Marek Vasut
Quoted 30 lines · Bin Meng
Hi Marek,
Quoted 27 lines · Marek Vasut
On 08/09/2018 11:41 AM, Bin Meng wrote:
[...]
Quoted 22 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
Quoted 1 line
Sorry this is a hack to current U-Boot implementation, not fix.
I am waiting for a better solution or suggestion ...
Quoted 1 line
The fix should be adding "ehci-pci" compatible string in the
r8a7794.dtsi.Quoted 8 lines
Quoted 2 lines
Wrong. The DT is perfectly valid as is.
I did not say
r8a7794.dtsiis invalid. Being valid does not mean it works everywhere. Being valid only means its syntax follows the DTS language and does not cause any build error. Adding a "compatible" string to a DT node is also perfectly valid. See "Binding Guidelines" in devicetree-specification-v0.2.pdf [1]Quoted 4 lines
Hacking up DT to work around bugs in an OS implementation makes it OS specific and this is incorrect. It is the OS that should be fixed, in this case U-Boot.
It's not a bug of U-Boot implementation. U-Boot DM was designed this way.
Quoted 6 lines
Quoted 3 lines
Then the design is flawed. (and btw. the U-Boot DM was not designed that way, you can take my word for it :-) )
Then please propose something that that is not flawed. But this patch is not a fix to the design, but a hack.
You are mixing two things in this answer, so it makes no sense. Anyway, let me just stop you here, DM was not designed in such a way, period.
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
If you are in U-Boot, you must follow U-Boot's rule. And I don't see current DM is a wrong design.
Wrong, U-Boot is given some hardware to run on and a matching description, DT. If both are valid and U-Boot cannot operate on them, then U-Boot is broken and must be fixed.
Quoted 8 lines
Quoted 4 lines
You cannot claim that just because U-Boot behaves in some way, a perfectly good hardware and/or it's description is wrong and needs to be adjusted. That makes no sense.
Again, who said current dts is *invalid*? You keep saying "valid", "valid"... Can you explain why adding a perfectly OK "compatible" string suddenly makes the DT invalid?
Adding a compatible to DT may or may not make it invalid.
Yet, the DT at hand is valid already, so adding extra crap into it just to work around buggy or incomplete implementation of PCI DT parsing is not an option.
Quoted 6 lines
Quoted 4 lines
Just assume the DT is in ROM, it's set in stone and it cannot be changed. Then the entire discussion below becomes pointless and we can focus on fixing U-Boot such that it'd be able to parse the DT properly.
Sometimes we have to update DT as not every working DT is born from day 1.
This DT at hand is working and valid. It cannot and will not be updated only because U-Boot PCI implementation is lacking.
Quoted 43 lines
Quoted 33 lines
Quoted 33 lines
Quoted 12 lines
Keep in mind that the DT may even be stored in ROM and can not be modified.
Quoted 9 lines
4.1 Binding Guidelines
4.1.1 General Principles
When creating a new devicetree representation for a device, a binding should be created that fully describes the required properties and value of the device. This set of properties shall be sufficiently descriptive to provide device drivers with needed attributes of the device. Some recommended practices include:
1. Define a *compatible* string using the conventions described in section 2.3.1
...Quoted 1 line
Yes, "recommended" . The compatible string is not a hard requirement.
OK, since you mentioned "recommended", let me paste the bullet 2 from the same spec:
Some recommended practices include:
1. Define a compatible string using the conventions described in section 2.3.1.
2. Use the standard properties (defined in sections 2.3 and 2.4) as applicable for the new device. This usage typically includes the *reg* and interrupts properties at a minimum.
3. Use the conventions specified in section 4 (Device Bindings) if the new device fits into one the DTSpec defined device classes
...Bullet 2 says: This usage *typically* includes the *reg* and interrupts properties at a minimum. That means "reg" is not mandatory.
And now let's see this patch:
df = ofnode_get_addr_size(node, "reg", &size);Quoted 9 lines
Quoted 2 lines
Who says a node must have a "reg" property? Using this as a sign to attach to DT is definitely wrong.
If there is no "reg" property, then you won't get a node associated with the driver instance and that's perfectly fine. Without the "reg" prop, you cannot figure out which PCI device/function the node describes, so how could you possibly associate the node with a driver instance ? You cannot.
Quoted 2 lines
This is a hack. I said many times if you add a "compatible" string DM create the device node for you.
I explained many times that the DT will not be updated to work around lacking implementation of PCI DT parsing in U-Boot. The DT is perfectly fine as-is.
I also explained already that the PCI ID or class is perfectly sufficient to match the driver on.
Quoted 139 lines
Quoted 139 lines
Quoted 33 lines
Quoted 28 lines
Quoted 14 lines
Quoted 8 lines
The device sitting at a particular slot/function can very well be ie. xhci controller and the DT node would be valid for it too, unless you enforce a compatible, which will mess things up.
Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.
No, it's not redundant but complementary to existing PCI enumeration (vendor/device/class/subclass...) mechanism. Please check "PCI Bus Binding" specification [2] which defines how we should describe a PCI device using "compatible" string.
Quoted 13 lines
"compatible" Construct a list of names in most-specific to least-specific order. The names shall be derived from values of the Vendor ID, Device ID, Subsystem Vendor ID, Subsystem ID, Revision ID and Class Code bytes, and shall have the following form, and be placed in the list in the following order:
pciVVVV,DDDD.SSSS.ssss.RR
pciVVVV,DDDD.SSSS.ssss
pciSSSS,ssss
pciVVVV,DDDD.RR
pciVVVV,DDDD
pciclass,CCSSPP
pciclass,CCSS
...Quoted 4 lines
Where does it say that the "compatible" string is mandatory ? I thought you yourself quoted a paragraph from that spec which says it's recommended, which means optional.
Quoted 4 lines
You can't say adding an optional "compatible" is wrong either. Being optional means an implementation can choose to support it according to its needs. U-Boot's DM was designed to use "compatible" when it comes to device binding.
Please assume the DT is in ROM and it cannot be modified.
Again, that's not how U-Boot DM was designed, DM is independent of DT, but discussing that is really off-topic here.
Quoted 23 lines
Quoted 23 lines
Quoted 22 lines
Quoted 4 lines
What is needed here is to assign a valid DT node to a driver instance of a PCI device if such a matching node exists in DT and that is all this patch does.
This patch fixes the wrong place. In
pci_bind_bus_devices(), we have the following codes that firstly check if the device is in DT. If not, then go on with the driver binding using vendor/device/class/subclass... mechanism./* Find this device in the device tree */
ret =pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);/* If nothing in the device tree, bind a device */ if (ret ==
-ENODEV) {
...
ret = pci_find_and_bind_driver(bus,&find_id, bdf,&dev); }Your patch adds some codes in
pci_find_and_bind_driver()to touch DT, which is not the function supposed to do. Hence I call it a hack.Quoted 7 lines
Quoted 4 lines
You can call it whatever you want, even repeatedly, but that does not help.
So what do you suggest ?
My suggestion was in the first reply: adding "compatible" string in the USB nodes.
NAK, that's a hack to work around broken U-Boot code. Unacceptable, I will not modify the DT for that reason.
Furthermore, the PCI code should match based on PCI ID or class, forcing a compatible could cause problems in case someone exchanges the PCI device and doesn't update the DT, which may not be possible (ROM). Adding the compatible also defeats the PnP behavior of PCI.
Quoted 28 lines
Quoted 13 lines
Mind you,
pci_find_and_bind_driver()seems like a perfectly reasonable place to bind a driver instance and a DT node together in my mind.Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
I disagree DT is OS-agnostic. This are lots of stuff in DT that are OS-specific. eg: there are lots of bindings in DT that requires Linux's device driver framework to work with.
This logic is flawed. If there exists a binding which depends on some behavior of specific OS then the binding is likely wrong. That specifically does not imply DT is OS-specific. Again, it is not and that is by design. The DT must be usable by multiple OSes with very different internal design, Solaris, *BSD, Linux, U-Boot to name a few.
Quoted 9 lines
Quoted 5 lines
My suggested fix does not add any OS-specific property. It's one of the basic properties defined by DT. Linux works without "compatible" in this case that's probably due to Linux was designed to work this way. But that does NOT justify we cannot add a "compatible" string to make U-Boot's design work.
Hacking up DT to work around bugs in U-Boot PCI code is not an option. If U-Boot cannot parse a valid DT correctly, then U-Boot needs to be fixed.
Again, I don't see this is a bug in the U-Boot PCI codes. The scenario of your board has been supported by U-Boot already. You keep saying "Linux can parse DT correctly" and "U-Boot cannot parse a valid DT", which makes no sense to me:
Quoted 4 lines
1. U-Boot can parse DT correctly. Parse means decoding device tree information to U-Boot's internal structure.
2. U-Boot usage of DT is perfectly valid too. How U-Boot uses these information in its internal structure is implementation-specific.That's good and all, but somehow the PCI controller subnodes are not associated with the driver in case they are described in the DT. Thus, U-Boot is not parsing the valid DT completely/correctly.
Quoted 7 lines
Quoted 3 lines
It is not because Linux was designed in any way, it is because Linux can parse DT correctly, including all the details. U-Boot cannot.
What
_allthedetails_? Are you saying that U-Boot should follow Linux's device driver framework, to parse DT and use DT exactly the same way as Linux?No, I am saying U-Boot should be able to extract necessary information from a valid DT. How that happens is up to U-Boot. This is not happening currently and thus U-Boot needs to be fixed.
Quoted 7 lines
Sorry this is terribly wrong. Imagine someone
writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.Quoted 5 lines
Quoted 3 lines
There is supposed to be only one DT for all the OSes, which has nothing to do with Linux or U-Boot or any of those. If some OS cannot parse an valid DT completely, then it's lacking.
I really don't understand such obsessiveness.
I can say the same thing, I don't understand why you're trying so hard to protect the lacking PCI DT parsing code in U-Boot. That is the part which needs to be fixed.
Quoted 2 lines
Currently there is NO
ALL OSes. There is ONLY Linux.
Quoted 8 lines
Quoted 1 line
Er, no. You forgot all the BSDs, SunOS and possibly a few others I forgot.
In fact, I didn't. I compared many dts files in BSD source codes against the dts files in Linux tree (with the same name, for the same board), and they _are_ unsurprisingly different. Some of nodes indeed have "compatible" string while the other one does not, which reveals the truth that what you kept saying all OSes should use exactly the same DT is purely wrong. You are too Linux-centric.
Note that while it is true (and has been true for a number of years) that the BSD dts files are very different, unless something has changed, I haven't made it to the DT BoF sessions in a while, an aspiration that everyone be able to use the same DTS files. How far off in the future something like that is, I cannot say. OS implementation is, for things done in the last 5-10 years, unintentional when baked into the bindings, etc in Linux.
Quoted 19 lines
Quoted 10 lines
Quoted 5 lines
What you kept talking about is the
reference implementation from Linux. You need convince me adding a compatible string to the USB node makes the DT invalid. If you admit adding "compatible" is perfectly OK, then per your theory Linux should handle it without any problems.I think I lost you here. I won't pollute this thread with even more crap. USB is a probable bus, just like PCI, you don't need compatible strings there either.
Didn't you see the "PCI Bus Binding" spec? It's a spec existing for years.
Quoted 6 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Quoted 8 lines
Quoted 6 lines
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
The fix in this patch is purely hack, period.
Lets step back for a moment.
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures". Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things. I think knowing where Linux does this would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180813/3430824d/attachment.sig>
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/13/2018 03:39 PM, Tom Rini wrote:
[...]
Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
Quoted 8 lines
Quoted 1 line
The fix in this patch is purely hack, period.
Lets step back for a moment.
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Right, which doesn't apply here. None of those u-boot,... props are needed in this case.
Quoted 4 lines
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures".
You did get an answer to that on irc from George. Looks like of_pci_find_child_device() indrivers/pci/of.c
Quoted 3 lines
Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things.
I disagree with this. It's a bind function and assigns other parameters of the driver instance too.
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.
Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 20 lines · Marek Vasut
On 08/13/2018 03:39 PM, Tom Rini wrote:
[...]Quoted 17 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Quoted 8 lines
Quoted 6 lines
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
The fix in this patch is purely hack, period.
Lets step back for a moment.
Quoted 7 lines
Quoted 4 lines
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Right, which doesn't apply here. None of those u-boot,... props are needed in this case.
Which is why I also mentioned the non-u-boot specific props we also need sometimes. My point is two-fold:
1: We can and will _add_ information to the dts files that come from Linux.
2: Not all information that we add is U-Boot prefixed.
Quoted 7 lines
Quoted 4 lines
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures".
You did get an answer to that on irc from George. Looks like
of_pci_find_child_device()indrivers/pci/of.c
Yeah, George said he thought that might be it but didn't have time to confirm.
Quoted 13 lines
Quoted 3 lines
Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things.
I disagree with this. It's a bind function and assigns other parameters of the driver instance too.
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.
Quoted 4 lines
Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
To try and move things along rather than re-argue the same point, you're saying that our pci_find_and_bind_driver() is the rough equivalent of of_pci_find_child_device() or at least pci_set_of_node() (which calls of_pci_find_child_device()).
So, Bin, if this isn't the right place to start down this path, where would be? Given that Linux can take a DTB and PCI bus with devices and get things right, what would it look like for U-Boot to replicate the same behavior? Instead of having to add explicit compatible nodes for each PCI device, as I understand (but correct me if I'm wrong) we're doing today. Thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180813/872492ea/attachment-0001.sig>
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Tom,
Quoted 26 lines · Tom Rini
Quoted 25 lines · Marek Vasut
On 08/13/2018 03:39 PM, Tom Rini wrote:
[...]Quoted 21 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Quoted 8 lines
Quoted 6 lines
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
The fix in this patch is purely hack, period.
Lets step back for a moment.
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Quoted 9 lines
Quoted 2 lines
Right, which doesn't apply here. None of those u-boot,... props are needed in this case.
Which is why I also mentioned the non-u-boot specific props we also need sometimes. My point is two-fold:
1: We can and will _add_ information to the dts files that come from Linux.
2: Not all information that we add is U-Boot prefixed.
It would be better if we document such DT expectation somewhere.
Quoted 34 lines
Quoted 7 lines
Quoted 4 lines
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures".
You did get an answer to that on irc from George. Looks like
of_pci_find_child_device()indrivers/pci/of.cYeah, George said he thought that might be it but didn't have time to confirm.
Quoted 13 lines
Quoted 3 lines
Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things.
I disagree with this. It's a bind function and assigns other parameters of the driver instance too.
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.Quoted 4 lines
Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
To try and move things along rather than re-argue the same point, you're saying that our
pci_find_and_bind_driver()is the rough equivalent ofof_pci_find_child_device()or at leastpci_set_of_node()(which callsof_pci_find_child_device()).
Quoted 6 lines
So, Bin, if this isn't the right place to start down this path, where would be? Given that Linux can take a DTB and PCI bus with devices and get things right, what would it look like for U-Boot to replicate the same behavior? Instead of having to add explicit compatible nodes for each PCI device, as I understand (but correct me if I'm wrong) we're doing today. Thanks!
So is this a requirement for all U-Boot driver subsystems to replicate the same Linux behavior? If yes, can we have it officially documented somewhere?
Since Marek refused to take the original U-Boot option 1 to support his case, and asked U-Boot to follow Linux's practice on PCI device binding, if we go that way, here is what we can do:
* Keep pci-uclass driver's post_bind() and child_post_bind() only for Sandbox configuration
* Keep the call to pci_bus_find_devfn() in pci_bind_bus_devices() only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
* Assign the DT node to the bound device in pci_find_and_bind_driver() if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only use U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to support U_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and update crownbay.dts and galileo.dts (so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes in doc/driver-model/pci-info.txt
I am not sure if I missed anything. Simon, could you also comment on it?
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 82 lines · Bin Meng
Hi Tom,
Quoted 26 lines · Tom Rini
Quoted 25 lines · Marek Vasut
On 08/13/2018 03:39 PM, Tom Rini wrote:
[...]Quoted 21 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Quoted 8 lines
Quoted 6 lines
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
The fix in this patch is purely hack, period.
Lets step back for a moment.
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Quoted 9 lines
Quoted 2 lines
Right, which doesn't apply here. None of those u-boot,... props are needed in this case.
Which is why I also mentioned the non-u-boot specific props we also need sometimes. My point is two-fold:
1: We can and will _add_ information to the dts files that come from Linux.
2: Not all information that we add is U-Boot prefixed.It would be better if we document such DT expectation somewhere.
Quoted 34 lines
Quoted 7 lines
Quoted 4 lines
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures".
You did get an answer to that on irc from George. Looks like
of_pci_find_child_device()indrivers/pci/of.cYeah, George said he thought that might be it but didn't have time to confirm.
Quoted 13 lines
Quoted 3 lines
Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things.
I disagree with this. It's a bind function and assigns other parameters of the driver instance too.
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.Quoted 4 lines
Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
To try and move things along rather than re-argue the same point, you're saying that our
pci_find_and_bind_driver()is the rough equivalent ofof_pci_find_child_device()or at leastpci_set_of_node()(which callsof_pci_find_child_device()).Quoted 6 lines
So, Bin, if this isn't the right place to start down this path, where would be? Given that Linux can take a DTB and PCI bus with devices and get things right, what would it look like for U-Boot to replicate the same behavior? Instead of having to add explicit compatible nodes for each PCI device, as I understand (but correct me if I'm wrong) we're doing today. Thanks!
Quoted 3 lines
So is this a requirement for all U-Boot driver subsystems to replicate the same Linux behavior? If yes, can we have it officially documented somewhere?
No, because we are not replicating Linux behavior.
Quoted 3 lines
Since Marek refused to take the original U-Boot option 1 to support his case, and asked U-Boot to follow Linux's practice on PCI device binding, if we go that way, here is what we can do:
You are inserting words into my mouth and I dislike that. I never said anything about Linux. I said DT is OS agnostic and U-Boot should be able to parse DT as fully as possible.
Quoted 6 lines
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
I don't think this is limited to sandbox, although I don't see a real-world usecase right now.
Quoted 11 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
I cannot test such changes, but I believe there is PCI_CLASS_COMMUNICATION_SERIAL and matching on that would suffice ?
Quoted 8 lines
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtI am not sure if I missed anything. Simon, could you also comment on it?
Regards,
Bin
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 83 lines · Marek Vasut
Quoted 82 lines · Bin Meng
Hi Tom,
Quoted 26 lines · Tom Rini
Quoted 25 lines · Marek Vasut
On 08/13/2018 03:39 PM, Tom Rini wrote:
[...]Quoted 21 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Quoted 8 lines
Quoted 6 lines
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
The fix in this patch is purely hack, period.
Lets step back for a moment.
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Quoted 9 lines
Quoted 2 lines
Right, which doesn't apply here. None of those u-boot,... props are needed in this case.
Which is why I also mentioned the non-u-boot specific props we also need sometimes. My point is two-fold:
1: We can and will _add_ information to the dts files that come from Linux.
2: Not all information that we add is U-Boot prefixed.It would be better if we document such DT expectation somewhere.
Quoted 40 lines
Quoted 7 lines
Quoted 4 lines
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures".
You did get an answer to that on irc from George. Looks like
of_pci_find_child_device()indrivers/pci/of.cYeah, George said he thought that might be it but didn't have time to confirm.
Quoted 13 lines
Quoted 3 lines
Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things.
I disagree with this. It's a bind function and assigns other parameters of the driver instance too.
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.Quoted 4 lines
Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
To try and move things along rather than re-argue the same point, you're saying that our
pci_find_and_bind_driver()is the rough equivalent ofof_pci_find_child_device()or at leastpci_set_of_node()(which callsof_pci_find_child_device()).So, Bin, if this isn't the right place to start down this path, where would be? Given that Linux can take a DTB and PCI bus with devices and get things right, what would it look like for U-Boot to replicate the same behavior? Instead of having to add explicit compatible nodes for each PCI device, as I understand (but correct me if I'm wrong) we're doing today. Thanks!
Quoted 6 lines
Quoted 3 lines
So is this a requirement for all U-Boot driver subsystems to replicate the same Linux behavior? If yes, can we have it officially documented somewhere?
No, because we are not replicating Linux behavior.
But you kept mentioning you wanted U-Boot to use exactly the same DT from Linux. And I pointed out that FreeBSD's DT files are not the same as Linux. Here you are saying you don't want U-Boot to replicate Linux behavior, if not the Linux behavior, what do you want to suggest then?
Quoted 7 lines
Quoted 3 lines
Since Marek refused to take the original U-Boot option 1 to support his case, and asked U-Boot to follow Linux's practice on PCI device binding, if we go that way, here is what we can do:
You are inserting words into my mouth and I dislike that. I never said anything about Linux. I said DT is OS agnostic and U-Boot should be able to parse DT as fully as possible.
See above comment. I might have used some words that made you feel uncomfortable, and for me I felt the same way. Part of the reason is that I am not a native English speaker and I may mis-use/interpret words. If that's the case I apologize. Anyway I won't quarrel against this over and over again. This does not help to move things forward.
Quoted 11 lines
Quoted 7 lines
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox onlyI don't think this is limited to sandbox, although I don't see a real-world usecase right now.
You are welcome to send patches against sandbox PCI codes to remove such limitation, to make it behave like a real-world bus device.
Quoted 12 lines
Quoted 11 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
Quoted 3 lines
I cannot test such changes, but I believe there is
PCI_CLASS_COMMUNICATION_SERIALand matching on that would suffice ?
Maybe, but I need check the datasheet to confirm. This can be a good start though. Note I can test the changes, and I can do the whole bunch of such proposed design changes if you don't mind, but let's wait for Simon's comments.
Quoted 4 lines
Quoted 4 lines
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtI am not sure if I missed anything. Simon, could you also comment on it?
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/14/2018 11:35 AM, Bin Meng wrote:
[...]
Quoted 27 lines
Quoted 27 lines
Quoted 26 lines
Quoted 16 lines
Quoted 10 lines
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
To try and move things along rather than re-argue the same point, you're saying that our
pci_find_and_bind_driver()is the rough equivalent ofof_pci_find_child_device()or at leastpci_set_of_node()(which callsof_pci_find_child_device()).Quoted 6 lines
So, Bin, if this isn't the right place to start down this path, where would be? Given that Linux can take a DTB and PCI bus with devices and get things right, what would it look like for U-Boot to replicate the same behavior? Instead of having to add explicit compatible nodes for each PCI device, as I understand (but correct me if I'm wrong) we're doing today. Thanks!
So is this a requirement for all U-Boot driver subsystems to replicate the same Linux behavior? If yes, can we have it officially documented somewhere?
Quoted 7 lines
Quoted 2 lines
No, because we are not replicating Linux behavior.
But you kept mentioning you wanted U-Boot to use exactly the same DT from Linux. And I pointed out that FreeBSD's DT files are not the same as Linux. Here you are saying you don't want U-Boot to replicate Linux behavior, if not the Linux behavior, what do you want to suggest then?
Just parse the information out of the DT fully and be done with it. That is what I suggest.
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Since Marek refused to take the original U-Boot option 1 to support his case, and asked U-Boot to follow Linux's practice on PCI device binding, if we go that way, here is what we can do:
You are inserting words into my mouth and I dislike that. I never said anything about Linux. I said DT is OS agnostic and U-Boot should be able to parse DT as fully as possible.
Quoted 5 lines
See above comment. I might have used some words that made you feel uncomfortable, and for me I felt the same way. Part of the reason is that I am not a native English speaker and I may mis-use/interpret words. If that's the case I apologize. Anyway I won't quarrel against this over and over again. This does not help to move things forward.
This is a technical discussion, we should use arguments, not feelings. I am fine, but thanks for your concern.
Quoted 26 lines
Quoted 10 lines
Quoted 6 lines
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox onlyI don't think this is limited to sandbox, although I don't see a real-world usecase right now.
You are welcome to send patches against sandbox PCI codes to remove such limitation, to make it behave like a real-world bus device.
Quoted 12 lines
Quoted 11 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
Quoted 8 lines
Quoted 3 lines
I cannot test such changes, but I believe there is
PCI_CLASS_COMMUNICATION_SERIALand matching on that would suffice ?Maybe, but I need check the datasheet to confirm. This can be a good start though. Note I can test the changes, and I can do the whole bunch of such proposed design changes if you don't mind, but let's wait for Simon's comments.
All those sandbox changes can be done in parallel to this change though, right ?
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtI am not sure if I missed anything. Simon, could you also comment on it?
Regards,
Bin
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Bin MengQuoted 32 lines · Bin Meng
Hi Tom,
Quoted 29 lines · Tom Rini
Quoted 27 lines · Marek Vasut
On 08/13/2018 03:39 PM, Tom Rini wrote:
[...]Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.This is not gonna happen.
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
Quoted 8 lines
Quoted 1 line
The fix in this patch is purely hack, period.
Lets step back for a moment.
First, U-Boot intends to be, in the case where a relevant DTS file exists, the Linux kernel one PLUS additions we require (u-boot,dm-spl, u-boot,dm-pre-reloc, but also sometimes stdout-path or properties that are omitted for various reasons).
Right, which doesn't apply here. None of those u-boot,... props are needed in this case.
Quoted 7 lines
Quoted 5 lines
Which is why I also mentioned the non-u-boot specific props we also need sometimes. My point is two-fold:
1: We can and will _add_ information to the dts files that come from Linux.
2: Not all information that we add is U-Boot prefixed.It would be better if we document such DT expectation somewhere.
Yes, it should be written down somewhere. But it's been a general expectation for a long time. It's why we even have the -u-boot.dtsi auto-include logic, so that the main dts/dtsi files can be re-synced without losing changes U-Boot needs.
Quoted 41 lines
Quoted 34 lines
Quoted 7 lines
Quoted 4 lines
Second, I've asked before (both in this thread and on IRC), and not gotten an answer yet, as to how Linux goes "Oh, _this_ PCI device and _this_ DT node need to be matched and populate some data structures".
You did get an answer to that on irc from George. Looks like
of_pci_find_child_device()indrivers/pci/of.cYeah, George said he thought that might be it but didn't have time to confirm.
Quoted 13 lines
Quoted 3 lines
Marek's patch seems to be, in short "here's where U-Boot needs to wire things up". Bin has said that no, the function in question is for other things.
I disagree with this. It's a bind function and assigns other parameters of the driver instance too.
Quoted 5 lines
I think knowing where Linux does this
would be instructive to figure out where we need to have some additional logic added OR we can make some cost/benefit analysis to see if it makes more sense overall to add compatibles to some nodes rather than add to the binary size.Quoted 4 lines
Adding compatible does not make any sense, the PCI ID provides that information. Adding compatible would only add redundancy which could possibly be even harmful (ie. if the controller got replaced with another one).
To try and move things along rather than re-argue the same point, you're saying that our
pci_find_and_bind_driver()is the rough equivalent ofof_pci_find_child_device()or at leastpci_set_of_node()(which callsof_pci_find_child_device()).Quoted 6 lines
So, Bin, if this isn't the right place to start down this path, where would be? Given that Linux can take a DTB and PCI bus with devices and get things right, what would it look like for U-Boot to replicate the same behavior? Instead of having to add explicit compatible nodes for each PCI device, as I understand (but correct me if I'm wrong) we're doing today. Thanks!
Quoted 3 lines
So is this a requirement for all U-Boot driver subsystems to replicate the same Linux behavior? If yes, can we have it officially documented somewhere?
Without very good and documented reasons, yes, it's an expectation that concepts / details we borrow from Linux should work like or close to Linux. Large parts of the MTD subsystem for example are re-synced.
Quoted 10 lines
Since Marek refused to take the original U-Boot option 1 to support his case, and asked U-Boot to follow Linux's practice on PCI device binding, if we go that way, here is what we can do:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
Yes, Sandbox is special and if we #if that part as needed, that might be good too.
Quoted 14 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
Quoted 1 line
I am not sure if I missed anything. Simon, could you also comment on it?
Yes, some further thoughts on how to move this forward would be helpful, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180814/36ff1731/attachment.sig>
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Bin MengOn 08/13/2018 04:07 AM, Bin Meng wrote:
[...]
Quoted 21 lines
Quoted 21 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Sorry this is terribly wrong. Imagine someone
writes another OS, and all he has is the device tree spec. He follows the spec and writes some codes to parse a valid DT, and it's done. How his OS makes use of the DT is his design decision and none of the device tree specs has hard requiement on it. Of course, using exact the same DT as Linux is nice-to-have feature but that's not the reason to attack has OS has bugs to parse DT.Quoted 5 lines
Quoted 3 lines
There is supposed to be only one DT for all the OSes, which has nothing to do with Linux or U-Boot or any of those. If some OS cannot parse an valid DT completely, then it's lacking.
I really don't understand such obsessiveness.
I can say the same thing, I don't understand why you're trying so hard to protect the lacking PCI DT parsing code in U-Boot. That is the part which needs to be fixed.
Quoted 2 lines
Currently there is NO
ALL OSes. There is ONLY Linux.
Quoted 8 lines
Quoted 1 line
Er, no. You forgot all the BSDs, SunOS and possibly a few others I forgot.
In fact, I didn't. I compared many dts files in BSD source codes against the dts files in Linux tree (with the same name, for the same board), and they _are_ unsurprisingly different. Some of nodes indeed have "compatible" string while the other one does not, which reveals the truth that what you kept saying all OSes should use exactly the same DT is purely wrong. You are too Linux-centric.
Contradiction (!truth) implies anything, that's logic 101.
Quoted 27 lines
Quoted 10 lines
Quoted 5 lines
What you kept talking about is the
reference implementation from Linux. You need convince me adding a compatible string to the USB node makes the DT invalid. If you admit adding "compatible" is perfectly OK, then per your theory Linux should handle it without any problems.I think I lost you here. I won't pollute this thread with even more crap. USB is a probable bus, just like PCI, you don't need compatible strings there either.
Didn't you see the "PCI Bus Binding" spec? It's a spec existing for years.
Quoted 4 lines
Quoted 3 lines
Next step is to upstream the DT
changes to Linux kernel, then sync the changes to U-Boot to satisfy this obsession - using exactly the same DT as Linux.Quoted 9 lines
This is not gonna happen.
Sorry, you're really just wasting my time with this foolishness. If U-Boot cannot parse valid DT bindings while other OSes can, U-Boot is broken and must be fixed. So far I only see you attacking this patch and trying to pull in everything you can do avoid accepting this patch or providing a better alternative. This is not a constructive discussion, so I stop here.
Quoted 1 line
The fix in this patch is purely hack, period.
So while you're constantly yelling "hack" "hack" here, I don't see any constructive feedback. Can you provide any ?
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Marek VasutQuoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
The problem here is that in Linux, something that sees the compatible renesas,pci-r8a7794 or renesas,pci-rcar-gen2 is doing whatever else needs to be done. Or something else? Please explain how what you want to have work here in U-Boot is working in the Linux kernel. Thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180810/0b761643/attachment.sig>
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 4 lines
The problem here is that in Linux, something that sees the compatible renesas,pci-r8a7794 or renesas,pci-rcar-gen2 is doing whatever else needs to be done. Or something else? Please explain how what you want to have work here in U-Boot is working in the Linux kernel. Thanks!
This has nothing to do with a specific controller. iMX6 does the same thing, see ie arch/arm/boot/dts/imx6q-utilite-pro.dts .
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, using U_BOOT_PCI_DEVICE() to declare a device and driver mapping.
You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario to support the 1st scenario.
Quoted 8 lines
Quoted 4 lines
The problem here is that in Linux, something that sees the compatible renesas,pci-r8a7794 or renesas,pci-rcar-gen2 is doing whatever else needs to be done. Or something else? Please explain how what you want to have work here in U-Boot is working in the Linux kernel. Thanks!
This has nothing to do with a specific controller. iMX6 does the same thing, see ie
arch/arm/boot/dts/imx6q-utilite-pro.dts.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:
That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Quoted 12 lines
Quoted 8 lines
Quoted 4 lines
The problem here is that in Linux, something that sees the compatible renesas,pci-r8a7794 or renesas,pci-rcar-gen2 is doing whatever else needs to be done. Or something else? Please explain how what you want to have work here in U-Boot is working in the Linux kernel. Thanks!
This has nothing to do with a specific controller. iMX6 does the same thing, see ie
arch/arm/boot/dts/imx6q-utilite-pro.dts.Regards,
Bin
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 101 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 96 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 7 lines
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Quoted 7 lines
Quoted 7 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.
Quoted 8 lines
Quoted 4 lines
You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
The problem here is that in Linux, something that sees the compatible renesas,pci-r8a7794 or renesas,pci-rcar-gen2 is doing whatever else needs to be done. Or something else? Please explain how what you want to have work here in U-Boot is working in the Linux kernel. Thanks!
This has nothing to do with a specific controller. iMX6 does the same thing, see ie
arch/arm/boot/dts/imx6q-utilite-pro.dts.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 108 lines · Bin Meng
Hi Marek,
Quoted 105 lines · Marek Vasut
Quoted 103 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties of particular PCI devices, ie. a PHY attached to an EHCI controller on a PCI bus. This patch parses those DT subnodes and assigns a node to the PCI device instance, so that the driver can extract details from that node and ie. configure the PHY using the PHY subsystem.
Signed-off-by Marek Vasut <[email protected]>Cc Simon Glass <[email protected]>--- drivers/pci/pci-uclass.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)drivers/pci/pci-uclass.c +11
-0@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,for (id = entry->match; id->vendor || id->subvendor || id->class_mask; id++) { +ofnode node; +if (!pci_match_one_id (id, find_id))continue ;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent, goto error;debug ("%s: Match found: %s\n" , __func__, drv->name); dev->driver_data = find_id->driver_data; + +dev_for_each_subnode (node, parent) { +phys_addr_t df, size; + df =ofnode_get_addr_size (node,"reg" , &size); + +if (PCI_FUNC (df) ==PCI_FUNC (bdf) && +PCI_DEV (df) ==PCI_DEV (bdf)) { + dev->node = node; +break ;Quoted 8 lines
drivers/pci/pci-uclass.c static int pci_find_and_bind_driver(struct udevice *parent, · line 705
Quoted 1 line
drivers/pci/pci-uclass.c +1
-0+ }The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:
Quoted 6 lines
Quoted 3 lines
That documentation is wrong and needs to be fixed. The compatible is optional.
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.
Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 11 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
The problem here is that in Linux, something that sees the compatible renesas,pci-r8a7794 or renesas,pci-rcar-gen2 is doing whatever else needs to be done. Or something else? Please explain how what you want to have work here in U-Boot is working in the Linux kernel. Thanks!
This has nothing to do with a specific controller. iMX6 does the same thing, see ie
arch/arm/boot/dts/imx6q-utilite-pro.dts.Regards,
Bin
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 109 lines · Marek Vasut
Quoted 108 lines · Bin Meng
Hi Marek,
Quoted 105 lines · Marek Vasut
Quoted 103 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 41 lines · Bin Meng
Hi Marek,
Quoted 38 lines · Marek Vasut
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;Quoted 8 lines
Quoted 1 line
+ }
The function
pci_find_and_bind_driver()is supposed to bind devices that are NOT in the device tree. Adding device tree access in this routine is quite odd. You can add the EHCI controller that need such PHY subnodes in the device tree and there is no need to modify anything I believe. If you are looking for an example, please check pciuart0 inarch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
That documentation is wrong and needs to be fixed. The compatible is optional.
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 51 lines · Marek Vasut
Quoted 49 lines · Bin Meng
Hi Marek,
On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Quoted 3 lines
Well this does not work for me, the EHCI PCI doesn't get a DT node assigned, check
r8a7794.dtsifor the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
Quoted 7 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.Quoted 8 lines
Quoted 4 lines
You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
Quoted 7 lines
Quoted 2 lines
That means every single patch anyone submits is now a hack ? Please ...
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
Quoted 54 lines · Marek Vasut
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for these two EHCI PCI nodes.
Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
I am happy to reword the documentation section that's wrong and send a patch for that.
Do we agree this code change goes in this place or where should it go ?
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Bin MengQuoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 60 lines · Bin Meng
Hi Marek,
On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem with it either.
Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180815/57ed103b/attachment.sig>
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 172 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 65 lines · Bin Meng
Hi Marek,
Quoted 62 lines · Marek Vasut
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.Quoted 7 lines
Quoted 3 lines
That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the device tree to a driver, hence no device node created. This is not Linux.
Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Quoted 2 lines
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
So what is the conclusion here ? Patch the design document and apply this patch as is ?
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 173 lines · Marek Vasut
Quoted 172 lines · Tom Rini
Quoted 170 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 74 lines · Marek Vasut
Quoted 72 lines · Bin Meng
Hi Marek,
On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.Quoted 5 lines
DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and must be fixed.
This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Quoted 6 lines
Quoted 2 lines
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 79 lines · Marek Vasut
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
Your proposal mostly covers sandbox and that can be done separately. My proposal is to update documentation and fix the code.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 184 lines · Marek Vasut
Quoted 183 lines · Bin Meng
Hi Marek,
Quoted 179 lines · Marek Vasut
Quoted 172 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 89 lines · Tom Rini
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Quoted 2 lines
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
So what is the conclusion here ? Patch the design document and apply this patch as is ?
Quoted 6 lines
Quoted 3 lines
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
Your proposal mostly covers sandbox and that can be done separately. My proposal is to update documentation and fix the code.
There are more changes than the sandbox. Given the participants in this thread, I suspect nobody else would care the design if you had only changed whatever you like in a patch or two. Then we will end up leaving such incomplete design in the source tree and confusing people maybe for years until someone tries to fix up the things all together. I hope we can do things right from start.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 191 lines · Bin Meng
Hi Marek,
Quoted 188 lines · Marek Vasut
Quoted 186 lines · Bin Meng
Hi Marek,
Quoted 173 lines · Marek Vasut
Quoted 172 lines · Tom Rini
Quoted 170 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 96 lines · Marek Vasut
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Quoted 6 lines
Quoted 2 lines
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
Quoted 8 lines
Quoted 2 lines
Your proposal mostly covers sandbox and that can be done separately. My proposal is to update documentation and fix the code.
There are more changes than the sandbox. Given the participants in this thread, I suspect nobody else would care the design if you had only changed whatever you like in a patch or two. Then we will end up leaving such incomplete design in the source tree and confusing people maybe for years until someone tries to fix up the things all together.
How is that incomplete and confusing , can you elaborate ?
Quoted 1 line
I hope we can do things right from start.
From start ... how ?
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Bin MengHi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 81 lines · Tom Rini
Quoted 79 lines · Marek Vasut
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
Quoted 8 lines
DT should but isn't always OS agnostic. DTS files that reside in the Linux Kernel are in practice is Linux-centric with the expectation that even if you could solve a given problem with valid DTS changes you make whatever is parsing it do additional logic instead. That, approximately, is what your patch is doing. If you added some HW description information to the dtsi file everything would work as expected as your DTS is describing the hardware and U-Boot is reading that description and figuring out what to do with it.
Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me. I would like to see what Bin proposes.
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 91 lines · Marek Vasut
Quoted 89 lines · Tom Rini
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Quoted 5 lines
Yes, you need additional logic to match the PCI controller subnode in DT with PCI device BFD, that's expected. You do NOT need extra compatibles, the PCI bus gives you enough information to match a driver on them. In fact, adding a compatible can interfere with this matching.
Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
Quoted 1 line
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 197 lines · Marek Vasut
Quoted 195 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 100 lines · Bin Meng
Hi Marek,
Quoted 96 lines · Marek Vasut
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Quoted 3 lines
Please, read U-Boot's
doc/driver-model/pci-info.txt. You really don't understand current implementation in U-Boot. In short, U-Boot supports two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.You can choose either two when you support PCI devices on your board, but you cannot mix both support together and make them a mess. In this patch, you hacked
pci_find_and_bind_driver()which is the 2nd scenario to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Quoted 6 lines
Quoted 4 lines
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have PCI_DEVICE() and friends for when we can attach a driver for a PCI device without using a compatible string.
Both of these are defined in the DT specification.
The patch seems to be a rework of PCI_DEVICE() and I cannot why it is necessary.
Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/20/2018 09:29 PM, Simon Glass wrote:
[...]
Quoted 23 lines
Quoted 13 lines
Quoted 13 lines
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Quoted 6 lines
Quoted 4 lines
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
Quoted 6 lines
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.
This is explained in the patch description and the thread again. Please read the thread before replying. Take a look at the r8a7794.dtsi and its PCI bindings, there are PCI controller subnodes which add extra information for PCI devices on the bus. These nodes do not have a compatible string, only a BFD.
This is perfectly valid, since you can match a driver on the PCI IDs or classes (PCI_DEVICE()), but the driver doesn't have a DT node associated with it. If there is a DT node with a matching BFD, it is associated with the driver instance by this patch.
This allows ie. the EHCI PCI driver to access that DT node and extract information about PHYs from the DT (in case of the r8a7794).
[...]
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 40 lines · Marek Vasut
On 08/20/2018 09:29 PM, Simon Glass wrote:
[...]Quoted 23 lines
Quoted 13 lines
Quoted 13 lines
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Quoted 6 lines
Quoted 4 lines
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
Quoted 6 lines
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.This is explained in the patch description and the thread again. Please read the thread before replying. Take a look at the
r8a7794.dtsiand its PCI bindings, there are PCI controller subnodes which add extra information for PCI devices on the bus. These nodes do not have a compatible string, only a BFD.
Quoted 7 lines
This is perfectly valid, since you can match a driver on the PCI IDs or classes (
PCI_DEVICE()), but the driver doesn't have a DT node associated with it. If there is a DT node with a matching BFD, it is associated with the driver instance by this patch.This allows ie. the EHCI PCI driver to access that DT node and extract information about PHYs from the DT (in case of the r8a7794).
But the code to do this already exists in pci_bind_bus_devices().
I know I am late to this thread but no one is going to read 45 messages, sorry.
Why is pci_bus_find_devfn() failing?
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/22/2018 08:08 PM, Simon Glass wrote:
[...]
Quoted 11 lines
Quoted 11 lines
This is explained in the patch description and the thread again. Please read the thread before replying. Take a look at the
r8a7794.dtsiand its PCI bindings, there are PCI controller subnodes which add extra information for PCI devices on the bus. These nodes do not have a compatible string, only a BFD.This is perfectly valid, since you can match a driver on the PCI IDs or classes (
PCI_DEVICE()), but the driver doesn't have a DT node associated with it. If there is a DT node with a matching BFD, it is associated with the driver instance by this patch.
Quoted 6 lines
Quoted 2 lines
This allows ie. the EHCI PCI driver to access that DT node and extract information about PHYs from the DT (in case of the r8a7794).
But the code to do this already exists in
pci_bind_bus_devices().I know I am late to this thread but no one is going to read 45 messages, sorry.
But then what is the point of having ML discussions archived at all if I have to explain the same thing over and over to everyone who comes into the thread ?
Quoted 1 line
Why is
pci_bus_find_devfn()failing?
Because this function is a hack to force-bind drivers to PCI devices which are described in the DT with a compatible string. This does not apply to this case.
If this function fails (correctly, no force-binding needs to happen because there is no compatible string, we want to match on PCI IDs), the code will continue and match on PCI ID/class with pci_find_and_bind_driver() . That function is where we need to verify if there isn't a PCI controller subnode in DT with a matching BFD which should be associated with the new driver instance.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 16 lines · Marek Vasut
On 08/22/2018 08:08 PM, Simon Glass wrote:
[...]Quoted 14 lines
Quoted 13 lines
This is explained in the patch description and the thread again. Please read the thread before replying. Take a look at the
r8a7794.dtsiand its PCI bindings, there are PCI controller subnodes which add extra information for PCI devices on the bus. These nodes do not have a compatible string, only a BFD.This is perfectly valid, since you can match a driver on the PCI IDs or classes (
PCI_DEVICE()), but the driver doesn't have a DT node associated with it. If there is a DT node with a matching BFD, it is associated with the driver instance by this patch.This allows ie. the EHCI PCI driver to access that DT node and extract information about PHYs from the DT (in case of the r8a7794).
Quoted 7 lines
Quoted 3 lines
But the code to do this already exists in
pci_bind_bus_devices().I know I am late to this thread but no one is going to read 45 messages, sorry.
But then what is the point of having ML discussions archived at all if I have to explain the same thing over and over to everyone who comes into the thread ?
It is an in-built admonition for participants to avoid generating more heat than light :-)
I thought someone pulled me into this thread, but perhaps I am mistaken.
Quoted 6 lines
Quoted 2 lines
Why is
pci_bus_find_devfn()failing?Because this function is a hack to force-bind drivers to PCI devices which are described in the DT with a compatible string. This does not apply to this case.
pci_bus_find_devfn() does not check compatible strings. It checks the PCI devfn stuff. If the node is in the DT and has the correct devfn, then pci_bus_find_devfn() should find it.
It does require that the node produced a device, which does indeed require a compatible string, I think.
We support either using DT with a compatible string or using PCI_DEVICE() without a DT node. But you already know that.
Quoted 7 lines
If this function fails (correctly, no force-binding needs to happen because there is no compatible string, we want to match on PCI IDs), the code will continue and match on PCI ID/class with
pci_find_and_bind_driver(). That function is where we need to verify if there isn't a PCI controller subnode in DT with a matching BFD which should be associated with the new driver instance.
So all of this is to avoid having a compatible string in the DT node for PCI?
Quoted 1 line · Earlier I
Quoted 1 line
So can you just add a compatible string and everything works?
and you replied:
Quoted 4 lines
No, because that makes no sense. The code can very well match the driver on the PCI IDs or classes, the DT node is supplementary information and it needs to be made available to the matched driver if present in the DT. The DT node is matched on the BFD (the reg property in the DT).
Yes the DT node is matched on the BFD. Yes we can match the node as you say.
Quoted 5 lines
The compatible string would only add redundancy and can in fact be harmful in case the PCI device could be replaced (ie. swapping USB EHCI controller for USB xHCI controller while retaining the USB PHY ; the controller itself could be discovered on the PCI bus, but the PHY can not and must be described in the DT).
This seems a bit odd. Without the compatible string we don't know what driver to use, except through the PCI_DEVICE() mechanism. Is that what you are using?
So is this a reason why we need this 3rd option? For your example are you saying that there are two different settings for a device, which result in using a different driver? How would DT normally handle this? Overlays? Having two nodes and marking one status = "disabled"? This problem does not seem unique to PCI. I could have a similar problem with USB or even with a standard SoC having a memory-mapped USB controller that can support both protocols (controlled by a setting somewhere).
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
Also, what if these two devices each had their own PHY and there were settings in that PHY DT node? You would need a separate node for each one, right?
I suggest that we don't NEED this third way. The question in my mind is whether it is necessary and doesn't just add confusion.
The code in Linux seems to be:
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn)
{
struct device_node *node, *node2;
for_each_child_of_node(parent, node) {
if (__of_pci_pci_compare(node, devfn))
return node;
/*
* Some OFs create a parent node "multifunc-device" as
* a fake root for all functions of a multi-function
* device we go down them as well.
*/
if (!strcmp(node->name, "multifunc-device")) {
for_each_child_of_node(node, node2) {
if (__of_pci_pci_compare(node2, devfn)) {
of_node_put(node);
return node2;
}
}
}
}
return NULL;
}void pci_set_of_node(struct pci_dev *dev)
{
if (!dev->bus->dev.of_node)
return;
dev->dev.of_node = of_pci_find_child_device(dev->bus->dev.of_node,
dev->devfn);
}There is no comment but it looks like this is where Linux does its 'fallback' to find a node with no compatible string. The relevant commit is:
commit 98d9f30c820d509145757e6ecbc36013aa02f7bc
Author: Benjamin Herrenschmidt <[email protected]> Date: Mon Apr 11 11:37:07 2011 +1000
pci/of: Match PCI devices to OF nodes dynamically
powerpc has two different ways of matching PCI devices to their corresponding OF node (if any) for historical reasons. The ppc64 one does a scan looking for matching bus/dev/fn, while the ppc32 one does a scan looking only for matching dev/fn on each level in order to be agnostic to busses being renumbered (which Linux does on some platforms).
This removes both and instead moves the matching code to the PCI core itself. It's the most logical place to do it: when a pci_dev is created, we know the parent and thus can do a single level scan for the matching device_node (if any).
The benefit is that all archs now get the matching for free. There's one hook the arch might want to provide to match a PHB bus to its device node. A default weak implementation is provided that looks for the parent device device node, but it's not entirely reliable on powerpc for various reasons so powerpc provides its own.
I don't know if this helps us very much. Having just 2 ways seems better than 3, and the compatible string is definitely a preferred way in general. The mention of different ways of doing things seems like something we should avoid in U-Boot if we can. It's a bootloader and PCI is probed in SPL on some platforms, so code size is at a premium. We also end up with confusion since it's hard or impossible to find the drivers (right?).
But if we want to follow what Linux does, then we need a 3rd way. So...how much do we want to follow Linux?
I think Tom should make the call here.
Whichever we do, the documentation needs updating. If we change it, tests need updating too.
In any case, re Bin's list of things that need doing, I worry about having different code for sandbox than other archs. It invalidates our sandbox testing. Granted, we have to support the PCI emulators, but that's OK since that code is not used except in sandbox. We still want to support compatible strings in the DT for PCI devices, right?
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/23/2018 12:45 PM, Simon Glass wrote:
[...]
Quoted 6 lines
Quoted 5 lines
Quoted 1 line
Why is
pci_bus_find_devfn()failing?Because this function is a hack to force-bind drivers to PCI devices which are described in the DT with a compatible string. This does not apply to this case.
Quoted 6 lines
pci_bus_find_devfn()does not check compatible strings. It checks the PCI devfn stuff. If the node is in the DT and has the correct devfn, thenpci_bus_find_devfn()should find it.It does require that the node produced a device, which does indeed require a compatible string, I think.
Well, yeah, I skipped the middle step for the sake of brevity. Ultimately, you need a compat string there.
Quoted 2 lines
We support either using DT with a compatible string or using
PCI_DEVICE()without a DT node. But you already know that.
Right
Quoted 8 lines
Quoted 6 lines
If this function fails (correctly, no force-binding needs to happen because there is no compatible string, we want to match on PCI IDs), the code will continue and match on PCI ID/class with
pci_find_and_bind_driver(). That function is where we need to verify if there isn't a PCI controller subnode in DT with a matching BFD which should be associated with the new driver instance.So all of this is to avoid having a compatible string in the DT node for PCI?
Yes, because it is redundant and possibly harmful. And because I want to parse existing DTs without special U-Boot modifications or hacking/twisting U-Boot in some obscure way which doesn't scale.
Quoted 19 lines
Quoted 1 line · Earlier I
Quoted 1 line
So can you just add a compatible string and everything works?
and you replied:
Quoted 4 lines
No, because that makes no sense. The code can very well match the driver on the PCI IDs or classes, the DT node is supplementary information and it needs to be made available to the matched driver if present in the DT. The DT node is matched on the BFD (the reg property in the DT).
Yes the DT node is matched on the BFD. Yes we can match the node as you say.
Quoted 5 lines
The compatible string would only add redundancy and can in fact be harmful in case the PCI device could be replaced (ie. swapping USB EHCI controller for USB xHCI controller while retaining the USB PHY ; the controller itself could be discovered on the PCI bus, but the PHY can not and must be described in the DT).
Quoted 3 lines
This seems a bit odd. Without the compatible string we don't know what driver to use, except through the
PCI_DEVICE()mechanism. Is that what you are using?
Of course, you can match on PCI IDs or PCI class already, PCI is a discoverable bus.
Quoted 3 lines
So is this a reason why we need this 3rd option? For your example are you saying that there are two different settings for a device, which result in using a different driver?
What I am saying is the following needs to be supported:
pci-controller at 100 {
...
usb at 1,0 {
reg = <0x800 0 0 0 0>;
phys = <&usb0 0>;
phy-names = "usb";
};
...
};You want to match the PCI device in BFD x.1.0 using PCI ID (ie. the driver that matches in this case is *hci-pci) and then associate the node usb at 1,0 , which contains PHY information for that *hci-pci driver, with it.
Quoted 1 line
How would DT normally handle this?
That's how DTs do it, even for other than r8axxxx devices. There are iMX devices which use the same approach for associating ethernet MAC with a PCI NIC for example.
Quoted 5 lines
Overlays? Having two nodes and marking one status = "disabled"? This problem does not seem unique to PCI. I could have a similar problem with USB or even with a standard SoC having a memory-mapped USB controller that can support both protocols (controlled by a setting somewhere).
You don't need overlays at all, the base DT is sufficient as is.
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
Quoted 71 lines
Also, what if these two devices each had their own PHY and there were settings in that PHY DT node? You would need a separate node for each one, right?
I suggest that we don't NEED this third way. The question in my mind is whether it is necessary and doesn't just add confusion.
The code in Linux seems to be:
struct
device_node*of_pci_find_child_device(structdevice_node*parent,
unsigned int devfn){ struct device_node *node, *node2; for_each_child_of_node(parent, node) { if (__of_pci_pci_compare(node, devfn)) return node; /* * Some OFs create a parent node "multifunc-device" as * a fake root for all functions of a multi-function * device we go down them as well. */ if (!strcmp(node->name, "multifunc-device")) { for_each_child_of_node(node, node2) { if (__of_pci_pci_compare(node2, devfn)) { of_node_put(node); return node2; } } } } return NULL; }void
pci_set_of_node(struct pci_dev *dev){ if (!dev->bus->dev.of_node) return; dev->dev.of_node = of_pci_find_child_device(dev->bus->dev.of_node, dev->devfn); }There is no comment but it looks like this is where Linux does its 'fallback' to find a node with no compatible string. The relevant commit is:
commit
98d9f30c820d509145757e6ecbc36013aa02f7bcAuthor: Benjamin Herrenschmidt <[email protected]> Date: Mon Apr 11 11:37:07 2011 +1000pci/of: Match PCI devices to OF nodes dynamically
powerpc has two different ways of matching PCI devices to their corresponding OF node (if any) for historical reasons. The ppc64 one does a scan looking for matching bus/dev/fn, while the ppc32 one does a scan looking only for matching dev/fn on each level in order to be agnostic to busses being renumbered (which Linux does on some platforms).
This removes both and instead moves the matching code to the PCI core itself. It's the most logical place to do it: when a
pci_devis created, we know the parent and thus can do a single level scan for the matchingdevice_node(if any).The benefit is that all archs now get the matching for free. There's one hook the arch might want to provide to match a PHB bus to its device node. A default weak implementation is provided that looks for the parent device device node, but it's not entirely reliable on powerpc for various reasons so powerpc provides its own.
Quoted 7 lines
I don't know if this helps us very much. Having just 2 ways seems better than 3, and the compatible string is definitely a preferred way in general. The mention of different ways of doing things seems like something we should avoid in U-Boot if we can. It's a bootloader and PCI is probed in SPL on some platforms, so code size is at a premium. We also end up with confusion since it's hard or impossible to find the drivers (right?).
Well the DT parsing functions are already in U-Boot if you use the PCI, so the code size impact of this change is negligible.
Quoted 2 lines
But if we want to follow what Linux does, then we need a 3rd way. So...how much do we want to follow Linux?
My argument is that I want to be able to parse DTs without hacking them up for U-Boot. If adding a few lines of code and few bytes to the size of bulky subsystem like PCI does that, that's fine in my book.
Quoted 10 lines
I think Tom should make the call here.
Whichever we do, the documentation needs updating. If we change it, tests need updating too.
In any case, re Bin's list of things that need doing, I worry about having different code for sandbox than other archs. It invalidates our sandbox testing. Granted, we have to support the PCI emulators, but that's OK since that code is not used except in sandbox. We still want to support compatible strings in the DT for PCI devices, right?
We do, since there seems to be usecase for those too.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 89 lines · Marek Vasut
On 08/23/2018 12:45 PM, Simon Glass wrote:
[...]Quoted 6 lines
Quoted 5 lines
Quoted 1 line
Why is
pci_bus_find_devfn()failing?Because this function is a hack to force-bind drivers to PCI devices which are described in the DT with a compatible string. This does not apply to this case.
Quoted 6 lines
pci_bus_find_devfn()does not check compatible strings. It checks the PCI devfn stuff. If the node is in the DT and has the correct devfn, thenpci_bus_find_devfn()should find it.It does require that the node produced a device, which does indeed require a compatible string, I think.
Well, yeah, I skipped the middle step for the sake of brevity. Ultimately, you need a compat string there.
Quoted 2 lines
We support either using DT with a compatible string or using
PCI_DEVICE()without a DT node. But you already know that.Right
Quoted 8 lines
Quoted 6 lines
If this function fails (correctly, no force-binding needs to happen because there is no compatible string, we want to match on PCI IDs), the code will continue and match on PCI ID/class with
pci_find_and_bind_driver(). That function is where we need to verify if there isn't a PCI controller subnode in DT with a matching BFD which should be associated with the new driver instance.So all of this is to avoid having a compatible string in the DT node for PCI?
Yes, because it is redundant and possibly harmful. And because I want to parse existing DTs without special U-Boot modifications or hacking/twisting U-Boot in some obscure way which doesn't scale.
Quoted 19 lines
Quoted 1 line · Earlier I
Quoted 1 line
So can you just add a compatible string and everything works?
and you replied:
Quoted 4 lines
No, because that makes no sense. The code can very well match the driver on the PCI IDs or classes, the DT node is supplementary information and it needs to be made available to the matched driver if present in the DT. The DT node is matched on the BFD (the reg property in the DT).
Yes the DT node is matched on the BFD. Yes we can match the node as you say.
Quoted 5 lines
The compatible string would only add redundancy and can in fact be harmful in case the PCI device could be replaced (ie. swapping USB EHCI controller for USB xHCI controller while retaining the USB PHY ; the controller itself could be discovered on the PCI bus, but the PHY can not and must be described in the DT).
Quoted 3 lines
This seems a bit odd. Without the compatible string we don't know what driver to use, except through the
PCI_DEVICE()mechanism. Is that what you are using?Of course, you can match on PCI IDs or PCI class already, PCI is a discoverable bus.
Quoted 3 lines
So is this a reason why we need this 3rd option? For your example are you saying that there are two different settings for a device, which result in using a different driver?
What I am saying is the following needs to be supported:
pci-controller at 100 { ... usb at 1,0 { reg = <0x800 0 0 0 0>; phys = <&usb0 0>; phy-names = "usb"; }; ... };You want to match the PCI device in BFD x.1.0 using PCI ID (ie. the driver that matches in this case is *hci-pci) and then associate the node usb at 1,0 , which contains PHY information for that *hci-pci driver, with it.
Quoted 1 line
How would DT normally handle this?
That's how DTs do it, even for other than r8axxxx devices. There are iMX devices which use the same approach for associating ethernet MAC with a PCI NIC for example.
Quoted 8 lines
Quoted 5 lines
Overlays? Having two nodes and marking one status = "disabled"? This problem does not seem unique to PCI. I could have a similar problem with USB or even with a standard SoC having a memory-mapped USB controller that can support both protocols (controlled by a setting somewhere).
You don't need overlays at all, the base DT is sufficient as is.
Everything up to here seems OK.
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 12 lines
Quoted 12 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
Also, what if these two devices each had their own PHY and there were settings in that PHY DT node? You would need a separate node for each one, right?
I suggest that we don't NEED this third way. The question in my mind is whether it is necessary and doesn't just add confusion.
[...]
Quoted 7 lines
Quoted 5 lines
In any case, re Bin's list of things that need doing, I worry about having different code for sandbox than other archs. It invalidates our sandbox testing. Granted, we have to support the PCI emulators, but that's OK since that code is not used except in sandbox. We still want to support compatible strings in the DT for PCI devices, right?
We do, since there seems to be usecase for those too.
OK, well let's make sure we have some compatible notes too in sandbox, so we retain testing.
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
Quoted 9 lines
Quoted 1 line
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
Quoted 8 lines
[...]
Quoted 6 lines
Quoted 5 lines
In any case, re Bin's list of things that need doing, I worry about having different code for sandbox than other archs. It invalidates our sandbox testing. Granted, we have to support the PCI emulators, but that's OK since that code is not used except in sandbox. We still want to support compatible strings in the DT for PCI devices, right?
Quoted 4 lines
Quoted 1 line
We do, since there seems to be usecase for those too.
OK, well let's make sure we have some compatible notes too in sandbox, so we retain testing.
I'm not changing anything in sandbox, so the original case is covered as is.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 18 lines · Marek Vasut
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
- Simon
Quoted 19 lines
Quoted 9 lines
[...]
Quoted 6 lines
Quoted 5 lines
In any case, re Bin's list of things that need doing, I worry about having different code for sandbox than other archs. It invalidates our sandbox testing. Granted, we have to support the PCI emulators, but that's OK since that code is not used except in sandbox. We still want to support compatible strings in the DT for PCI devices, right?
Quoted 4 lines
Quoted 1 line
We do, since there seems to be usecase for those too.
OK, well let's make sure we have some compatible notes too in sandbox, so we retain testing.
I'm not changing anything in sandbox, so the original case is covered as is.
--
Best regards,
Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 30 lines · Simon Glass
Hi Marek,
Quoted 18 lines · Marek Vasut
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
Quoted 7 lines
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
I think I lost you. But this discussion is really hypothetical. You _can_ have a USB PHY which can attach to both USB 2 and USB 3 controller, in which case you would have only one DT node to describe it.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 35 lines · Marek Vasut
Quoted 34 lines · Simon Glass
Hi Marek,
Quoted 18 lines · Marek Vasut
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
Quoted 7 lines
Quoted 3 lines
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
I think I lost you. But this discussion is really hypothetical. You _can_ have a USB PHY which can attach to both USB 2 and USB 3 controller, in which case you would have only one DT node to describe it.
Can you point to an example of this? Otherwise it seems hypothetical.
As a counter-example, see exynos54xx.dtsi.
I believe the correct way to do this is to enable/disable DT nodes. Do you have any pointers to suggest that the same node should be used for two devices?
Also, what settings are you actually adding to your DT node? Can you please point to it again?
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 42 lines · Simon Glass
Hi Marek,
Quoted 39 lines · Marek Vasut
Quoted 37 lines · Simon Glass
Hi Marek,
Quoted 18 lines · Marek Vasut
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
Quoted 5 lines
Quoted 3 lines
I think I lost you. But this discussion is really hypothetical. You _can_ have a USB PHY which can attach to both USB 2 and USB 3 controller, in which case you would have only one DT node to describe it.
Can you point to an example of this? Otherwise it seems hypothetical.
Nope, it's just electrically viable.
Quoted 1 line
As a counter-example, see
exynos54xx.dtsi.
What exactly am I looking for ?
Quoted 3 lines
I believe the correct way to do this is to enable/disable DT nodes. Do you have any pointers to suggest that the same node should be used for two devices?
Nope
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 43 lines · Marek Vasut
Quoted 42 lines · Simon Glass
Hi Marek,
Quoted 39 lines · Marek Vasut
Quoted 37 lines · Simon Glass
Hi Marek,
Quoted 18 lines · Marek Vasut
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I think I lost you. But this discussion is really hypothetical. You _can_ have a USB PHY which can attach to both USB 2 and USB 3 controller, in which case you would have only one DT node to describe it.
Can you point to an example of this? Otherwise it seems hypothetical.
Nope, it's just electrically viable.
OK, well I'm not sure that we can make any claims about any of this unless it is used somewhere.
Quoted 4 lines
Quoted 2 lines
As a counter-example, see
exynos54xx.dtsi.What exactly am I looking for ?
You can see a USB3 PHY which is attached to a USB3 host.
Quoted 6 lines
Quoted 4 lines
I believe the correct way to do this is to enable/disable DT nodes. Do you have any pointers to suggest that the same node should be used for two devices?
Nope
Then I believe that is incorrect, and it should be handled using two separate notes, with only one enabled at run-time.
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 65 lines · Simon Glass
Hi Marek,
Quoted 43 lines · Marek Vasut
Quoted 42 lines · Simon Glass
Hi Marek,
Quoted 39 lines · Marek Vasut
Quoted 37 lines · Simon Glass
Hi Marek,
Quoted 18 lines · Marek Vasut
Quoted 1 line · Simon Glass
Hi Marek,
Hi,
[...]
Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
For the PHY case, it's controller-type-independent.
What do you mean? Your example of why you can't use compatible strings says you might have two different PHYs. But I think you should answer my questions:
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
If you have both EHCI and a xHCI controller which can occupy the same BFD, then how would you supply in the DT options needed by the controller itself? Don't you need two nodes in that case?
You need only one node (if the PHY works with both controller options), which contains "reg" and "phy" properties. The driver matching is done on the PCI ID/class and the node is associated with the driver based on the "reg" property.
I think you need two nodes if there are DT options that are different for each PHY. In fact I think this is impossible to do with the reg scheme.
In effect the PHYs are different. They have different drivers, assuming drivers are needed. So I feel that using a common address to match two different devices is actually just weird.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I think I lost you. But this discussion is really hypothetical. You _can_ have a USB PHY which can attach to both USB 2 and USB 3 controller, in which case you would have only one DT node to describe it.
Can you point to an example of this? Otherwise it seems hypothetical.
Nope, it's just electrically viable.
OK, well I'm not sure that we can make any claims about any of this unless it is used somewhere.
Quoted 4 lines
Quoted 2 lines
As a counter-example, see
exynos54xx.dtsi.What exactly am I looking for ?
You can see a USB3 PHY which is attached to a USB3 host.
Quoted 1 line
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
I believe the correct way to do this is to enable/disable DT nodes. Do you have any pointers to suggest that the same node should be used for two devices?
Nope
Then I believe that is incorrect, and it should be handled using two separate notes, with only one enabled at run-time.
I don't think you can claim it's either correct or incorrect if there is no such hardware.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Simon GlassHi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
Quoted 103 lines · Bin Meng
Hi Marek,
On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is optional.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and the driver instance. Clearly, we need option 3 for this.
Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's post_bind() and child_post_bind() only for Sandbox configuration
* Keep the call to pci_bus_find_devfn() in pci_bind_bus_devices() only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
* Assign the DT node to the bound device in pci_find_and_bind_driver() if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only use U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to support U_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and update crownbay.dts and galileo.dts (so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes in doc/driver-model/pci-info.txt
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 241 lines · Bin Meng
Hi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
On 08/13/2018 04:24 AM, Bin Meng wrote:
Hi Marek,On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is
optional.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and
the driver instance. Clearly, we need option 3 for this.Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
Quoted 8 lines
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
The above three points can be done separately and I don't care about this too much.
Quoted 3 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
This is what this patch does. And in fact, I have real hardware which needs this patch to be useful and on which I can test if this works.
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 251 lines · Marek Vasut
Quoted 241 lines · Bin Meng
Hi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut <[email protected]> wrote:
On 08/13/2018 04:24 AM, Bin Meng wrote:
Hi Marek,On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is
optional.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date
U-Boot support of PCI bus with DM.Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 18 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Again, the DT contains all the required information to bind the node and
the driver instance. Clearly, we need option 3 for this.Then that's a new design proposal. Anything that wants to mess up
current design is a hack.That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
Quoted 8 lines
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design. Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Quoted 7 lines
Quoted 3 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device treeThis is what this patch does. And in fact, I have real hardware which needs this patch to be useful and on which I can test if this works.
You can do this in your own fork. Nothing prevents you from doing that.
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
Quoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/21/2018 06:15 AM, Bin Meng wrote:
[...]
Quoted 47 lines
Quoted 47 lines
Quoted 46 lines
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
Quoted 6 lines
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design.
Incomplete how ?
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device treeThis is what this patch does. And in fact, I have real hardware which needs this patch to be useful and on which I can test if this works.
You can do this in your own fork. Nothing prevents you from doing that.
I am at loss for words, really.
Quoted 17 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Quoted 4 lines
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 50 lines · Marek Vasut
On 08/21/2018 06:15 AM, Bin Meng wrote:
[...]Quoted 47 lines
Quoted 47 lines
Quoted 46 lines
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design.
Incomplete how ?
I explained several times. I have to repeat here once again:
Currently U-Boot supports two scenarios for PCI driver binding:
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, using U_BOOT_PCI_DEVICE() to declare a device and driver mapping.
You are creating a 3rd scenario which is a mix up of both scenario#1 and #2 in this patch, yet without any documentation, plus any additional changes to impacted drivers.
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 6 lines
Quoted 4 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
Quoted 35 lines
Quoted 10 lines
Quoted 8 lines
Quoted 4 lines
* Assign the DT node to the bound device in
pci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device treeThis is what this patch does. And in fact, I have real hardware which needs this patch to be useful and on which I can test if this works.
You can do this in your own fork. Nothing prevents you from doing that.
I am at loss for words, really.
Quoted 17 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Quoted 4 lines
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
Quoted 8 lines
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design. Second, doing such is necessary to make the design clean and complete. Yes, I am glad to do the whole changes if everyone agrees. I am more glad if you can do such changes in a batch too.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/21/2018 06:56 AM, Bin Meng wrote:
[...]
Quoted 29 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox onlyQuoted 8 lines
Quoted 6 lines
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design.
Incomplete how ?
I explained several times. I have to repeat here once again:
Currently U-Boot supports two scenarios for PCI driver binding:
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.
Quoted 3 lines
You are creating a 3rd scenario which is a mix up of both scenario#1 and #2 in this patch, yet without any documentation, plus any additional changes to impacted drivers.
I am extending both, it's not a "third scenario".
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
So again, how is the state of PCI more incomplete with this patch than without it ?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
So what is it about ? And how does this core change impact anything ? Does it change behavior for some board or break some tests for you ?
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
Quoted 4 lines
Quoted 4 lines
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
You did not answer this question.
Quoted 6 lines
Quoted 3 lines
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design.
It is not a new design, just an extension of the current one.
Driver cleanups where you match on PCI IDs or classes instead of compatible strings are completely orthogonal to this change, you don't even need this patch to do such a cleanup. Same applies for the x86 DT cleanup, you don't need this patch for those either.
So please stop lumping those together with this patch, they are unrelated.
Quoted 2 lines
Second, doing such is necessary to make
the design clean and complete.
No, doing so is orthogonal, see above.
Quoted 3 lines
Yes, I am glad to do the whole changes
if everyone agrees. I am more glad if you can do such changes in a batch too.
Feel free to submit your sandbox and ns16550 and whatever other improvements. I have neither an x86 with U-Boot nor ns16550 card available, so I cannot test those.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 47 lines · Marek Vasut
On 08/21/2018 06:56 AM, Bin Meng wrote:
[...]Quoted 29 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox onlyQuoted 8 lines
Quoted 6 lines
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design.
Incomplete how ?
I explained several times. I have to repeat here once again:
Currently U-Boot supports two scenarios for PCI driver binding:
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.Quoted 3 lines
You are creating a 3rd scenario which is a mix up of both scenario#1 and #2 in this patch, yet without any documentation, plus any additional changes to impacted drivers.
I am extending both, it's not a "third scenario".
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 5 lines
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
OK, now new comments :) So you admit "compatible" can be valid for some cases. I have to point out that your theory on PCI device probing is self-contradictory. You refuse to add a "compatible" string to your PCI device because you said the vendor/device id/class provides enough information to bind the driver, then why do you want to specify your devices in the device tree in the first place. According to your theory, "Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.", I would argue why not just creating a dedicate PCI device driver using PCI ID and class information to do the driver binding and start from there. As you mentioned PCI bus is probable bus like USB, everything can be self-contained in the PCI device driver itself. There is no need to create nothing in the device tree. If you want an example, check 8250_pci.c in the Linux kernel. Everything that is needed to configure the driver is included in the driver itself. It does not read anything from the device tree.
Quoted 36 lines
So again, how is the state of PCI more incomplete with this patch than without it ?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
So what is it about ? And how does this core change impact anything ? Does it change behavior for some board or break some tests for you ?
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
You did not answer this question.
It's too early to go testing at this point because we are still discussing the design. BTW your patch does not check the return value of ofnode_get_addr_size(). It's possible to write a DT without "reg" property in a device node.
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design.
Quoted 7 lines
It is not a new design, just an extension of the current one.
Driver cleanups where you match on PCI IDs or classes instead of compatible strings are completely orthogonal to this change, you don't even need this patch to do such a cleanup. Same applies for the x86 DT cleanup, you don't need this patch for those either.
Why would I? If there is no design changes, the clean up work to current drivers is out of the question as these drivers are supported user cases by current U-Boot PCI implementation.
Quoted 7 lines
So please stop lumping those together with this patch, they are unrelated.
Quoted 2 lines
Second, doing such is necessary to make
the design clean and complete.No, doing so is orthogonal, see above.
Quoted 8 lines
Quoted 3 lines
Yes, I am glad to do the whole changes
if everyone agrees. I am more glad if you can do such changes in a batch too.Feel free to submit your sandbox and ns16550 and whatever other improvements. I have neither an x86 with U-Boot nor ns16550 card available, so I cannot test those.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 50 lines · Bin Meng
Hi Marek,
Quoted 47 lines · Marek Vasut
On 08/21/2018 06:56 AM, Bin Meng wrote:
[...]Quoted 29 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox onlyQuoted 8 lines
Quoted 6 lines
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design.
Incomplete how ?
I explained several times. I have to repeat here once again:
Currently U-Boot supports two scenarios for PCI driver binding:
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.Quoted 3 lines
You are creating a 3rd scenario which is a mix up of both scenario#1 and #2 in this patch, yet without any documentation, plus any additional changes to impacted drivers.
I am extending both, it's not a "third scenario".
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 8 lines
Quoted 5 lines
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
OK, now new comments :) So you admit "compatible" can be valid for some cases.
_some_ select ones, and that is a _very_ important distinction.
Quoted 5 lines
I have to point out that your theory on PCI device probing is self-contradictory.You refuse to add a "compatible" string to your PCI device because you said the vendor/device id/class provides enough information to bind the driver, then why do you want to specify your devices in the device tree in the first place.
Because of the USB PHY , which is attached to that device and can not be probed on the PCI bus, unlike the device itself ?
Quoted 7 lines
According to your
theory, "Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.", I would argue why not just creating a dedicate PCI device driver using PCI ID and class information to do the driver binding and start from there.
Because the same device with the same PCI ID can be used without that PHY .
Quoted 6 lines
As you mentioned PCI bus is probable bus like USB, everything can be self-contained in the PCI device driver itself. There is no need to create nothing in the device tree. If you want an example, check
8250_pci.cin the Linux kernel. Everything that is needed to configure the driver is included in the driver itself. It does not read anything from the device tree.
Well, see above for why this approach doesn't work.
Quoted 41 lines
Quoted 41 lines
So again, how is the state of PCI more incomplete with this patch than without it ?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
So what is it about ? And how does this core change impact anything ? Does it change behavior for some board or break some tests for you ?
Quoted 26 lines
Quoted 26 lines
Quoted 17 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Quoted 4 lines
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
Quoted 5 lines
Quoted 2 lines
You did not answer this question.
It's too early to go testing at this point because we are still discussing the design.
OK, so basically you didn't even try this patch to see if it actually has any impact anywhere. Sigh ...
Quoted 3 lines
BTW your patch does not check the return value
ofofnode_get_addr_size(). It's possible to write a DT without "reg" property in a device node.
That would be invalid DT, since you won't be able to match on the BFD. But that check can be added in V2.
Quoted 15 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design.
Quoted 7 lines
It is not a new design, just an extension of the current one.
Driver cleanups where you match on PCI IDs or classes instead of compatible strings are completely orthogonal to this change, you don't even need this patch to do such a cleanup. Same applies for the x86 DT cleanup, you don't need this patch for those either.
Quoted 3 lines
Why would I? If there is no design changes, the clean up work to current drivers is out of the question as these drivers are supported user cases by current U-Boot PCI implementation.
Then leave them as is. But don't request unrelated cleansup from me either. I really do not understand why I should do those cleanups to get in an completely unrelated patch, that's just nonsense.
[...]
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 62 lines · Marek Vasut
Quoted 50 lines · Bin Meng
Hi Marek,
Quoted 47 lines · Marek Vasut
On 08/21/2018 06:56 AM, Bin Meng wrote:
[...]Quoted 29 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox onlyQuoted 8 lines
Quoted 6 lines
Quoted 3 lines
The above three points can be done separately and I don't care about this too much.
That's my concern. Only doing this created confusing and incomplete design.
Incomplete how ?
I explained several times. I have to repeat here once again:
Currently U-Boot supports two scenarios for PCI driver binding:
- Declare a PCI device in the device tree. That requires specifying a 'compatible' string as well as 'reg' property as defined by the 'PCI Bus Binding' spec. DM uses the 'compatible' string to bind the driver for the device.
- Don't declare a PCI device in the device tree. Instead, usingU_BOOT_PCI_DEVICE()to declare a device and driver mapping.Quoted 3 lines
You are creating a 3rd scenario which is a mix up of both scenario#1 and #2 in this patch, yet without any documentation, plus any additional changes to impacted drivers.
I am extending both, it's not a "third scenario".
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 8 lines
Quoted 5 lines
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
OK, now new comments :) So you admit "compatible" can be valid for some cases.
_some_ select ones, and that is a _very_ important distinction.
Quoted 9 lines
Quoted 5 lines
I have to point out that your theory on PCI device probing is self-contradictory.You refuse to add a "compatible" string to your PCI device because you said the vendor/device id/class provides enough information to bind the driver, then why do you want to specify your devices in the device tree in the first place.
Because of the USB PHY , which is attached to that device and can not be probed on the PCI bus, unlike the device itself ?
You can create a new EHCI PCI driver to match your USB EHCI controller's vendor id/device id, and do any additional PHY setup in that driver. BTW what's the vendor id and device id of the EHCI controller on your board? I can have a look up at the PCI database.
Quoted 10 lines
Quoted 7 lines
According to your
theory, "Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.", I would argue why not just creating a dedicate PCI device driver using PCI ID and class information to do the driver binding and start from there.Because the same device with the same PCI ID can be used without that PHY .
Quoted 8 lines
Quoted 6 lines
As you mentioned PCI bus is probable bus like USB, everything can be self-contained in the PCI device driver itself. There is no need to create nothing in the device tree. If you want an example, check
8250_pci.cin the Linux kernel. Everything that is needed to configure the driver is included in the driver itself. It does not read anything from the device tree.Well, see above for why this approach doesn't work.
Please explain why it does not work. I see Intel e1000 driver in the Linux kernel has lots of PHY configuration within the driver. It does not use any external PHY (eg: Marvell 88exxx) driver that Linux already has. The Ethernet PHY are not probeable on the PCI bus too.
Quoted 42 lines
Quoted 42 lines
Quoted 42 lines
So again, how is the state of PCI more incomplete with this patch than without it ?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
So what is it about ? And how does this core change impact anything ? Does it change behavior for some board or break some tests for you ?
Quoted 26 lines
Quoted 26 lines
Quoted 17 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Quoted 4 lines
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
You did not answer this question.
It's too early to go testing at this point because we are still discussing the design.
OK, so basically you didn't even try this patch to see if it actually has any impact anywhere. Sigh ...
I tend not to test a patch that is still under discussion to save some time. As there are several x86 boards to test with, along with sandbox. BTW you can test sandbox yourself.
Quoted 22 lines
Quoted 3 lines
BTW your patch does not check the return value
ofofnode_get_addr_size(). It's possible to write a DT without "reg" property in a device node.That would be invalid DT, since you won't be able to match on the BFD. But that check can be added in V2.
Quoted 15 lines
Quoted 14 lines
Quoted 6 lines
Quoted 3 lines
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design.
It is not a new design, just an extension of the current one.
Driver cleanups where you match on PCI IDs or classes instead of compatible strings are completely orthogonal to this change, you don't even need this patch to do such a cleanup. Same applies for the x86 DT cleanup, you don't need this patch for those either.
Quoted 7 lines
Quoted 3 lines
Why would I? If there is no design changes, the clean up work to current drivers is out of the question as these drivers are supported user cases by current U-Boot PCI implementation.
Then leave them as is. But don't request unrelated cleansup from me either. I really do not understand why I should do those cleanups to get in an completely unrelated patch, that's just nonsense.
"Leave them as is", so what do we want to tell other PCI device driver developers in the community? To use whatever way they like? Eventually you created a 3rd scenario.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
On 08/22/2018 04:14 AM, Bin Meng wrote:
[...]
Quoted 27 lines
Quoted 27 lines
Quoted 10 lines
Quoted 10 lines
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 8 lines
Quoted 5 lines
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
OK, now new comments :) So you admit "compatible" can be valid for some cases.
_some_ select ones, and that is a _very_ important distinction.
Quoted 5 lines
I have to point out that your theory on PCI device probing is self-contradictory.You refuse to add a "compatible" string to your PCI device because you said the vendor/device id/class provides enough information to bind the driver, then why do you want to specify your devices in the device tree in the first place.
Quoted 8 lines
Quoted 3 lines
Because of the USB PHY , which is attached to that device and can not be probed on the PCI bus, unlike the device itself ?
You can create a new EHCI PCI driver to match your USB EHCI controller's vendor id/device id, and do any additional PHY setup in that driver. BTW what's the vendor id and device id of the EHCI controller on your board? I can have a look up at the PCI database.
You can not.
1033:00e0 -- https://pci-ids.ucw.cz/read/PC/1033/00e0
You can buy that controller as a discrete chip on a PCI card or have one in an SoC on a PCI bus, I have both.
Quoted 17 lines
Quoted 17 lines
Quoted 7 lines
According to your
theory, "Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.", I would argue why not just creating a dedicate PCI device driver using PCI ID and class information to do the driver binding and start from there.Because the same device with the same PCI ID can be used without that PHY .
Quoted 6 lines
As you mentioned PCI bus is probable bus like USB, everything can be self-contained in the PCI device driver itself. There is no need to create nothing in the device tree. If you want an example, check
8250_pci.cin the Linux kernel. Everything that is needed to configure the driver is included in the driver itself. It does not read anything from the device tree.
Quoted 6 lines
Quoted 1 line
Well, see above for why this approach doesn't work.
Please explain why it does not work. I see Intel e1000 driver in the Linux kernel has lots of PHY configuration within the driver. It does not use any external PHY (eg: Marvell 88exxx) driver that Linux already has. The Ethernet PHY are not probeable on the PCI bus too.
That's a different thing, the ethernet MACs have an internal MDIO interface and you can scan the MDIO bus and read out PHY registers 0/1 to get the PHY ID.
This does not apply to this particular usecase here. In this case, the controller can be either embedded or discrete, with PHY or without PHY.
Quoted 47 lines
Quoted 47 lines
Quoted 46 lines
Quoted 36 lines
So again, how is the state of PCI more incomplete with this patch than without it ?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
So what is it about ? And how does this core change impact anything ? Does it change behavior for some board or break some tests for you ?
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
You did not answer this question.
It's too early to go testing at this point because we are still discussing the design.
Quoted 7 lines
Quoted 3 lines
OK, so basically you didn't even try this patch to see if it actually has any impact anywhere. Sigh ...
I tend not to test a patch that is still under discussion to save some time. As there are several x86 boards to test with, along with sandbox. BTW you can test sandbox yourself.
I am positive this has nothing to do with sandbox, so I will not do that. If you think this patch has some potential impact on sandbox, please detail that or drop the sandbox topic from the discussion.
Quoted 26 lines
Quoted 26 lines
Quoted 3 lines
BTW your patch does not check the return value
ofofnode_get_addr_size(). It's possible to write a DT without "reg" property in a device node.That would be invalid DT, since you won't be able to match on the BFD. But that check can be added in V2.
Quoted 18 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design.
Quoted 7 lines
It is not a new design, just an extension of the current one.
Driver cleanups where you match on PCI IDs or classes instead of compatible strings are completely orthogonal to this change, you don't even need this patch to do such a cleanup. Same applies for the x86 DT cleanup, you don't need this patch for those either.
Why would I? If there is no design changes, the clean up work to current drivers is out of the question as these drivers are supported user cases by current U-Boot PCI implementation.
Quoted 7 lines
Quoted 3 lines
Then leave them as is. But don't request unrelated cleansup from me either. I really do not understand why I should do those cleanups to get in an completely unrelated patch, that's just nonsense.
"Leave them as is", so what do we want to tell other PCI device driver developers in the community? To use whatever way they like? Eventually you created a 3rd scenario.
The message right now is there there is massive unwillingness to take PCI core changes, the current discussion just drags on and on and is just tiring, without any progress or constructive feedback. The only input I see is a mix of requests for clean-ups of unrelated DTs and drivers, which I cannot test and which can be done independently of this patch. It all feels like stalling to me, but I don't understand what the real goal is.
And regarding "leave them as is", yes, asking developers to clean up random unrelated part of U-Boot, just because they want to get a core patch in, doesn't make sense. If you want to send cleanups for your x86 or sandbox stuff, fine by me.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 38 lines · Marek Vasut
On 08/22/2018 04:14 AM, Bin Meng wrote:
[...]Quoted 27 lines
Quoted 27 lines
Quoted 10 lines
Quoted 10 lines
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 8 lines
Quoted 5 lines
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
OK, now new comments :) So you admit "compatible" can be valid for some cases.
_some_ select ones, and that is a _very_ important distinction.
Quoted 5 lines
I have to point out that your theory on PCI device probing is self-contradictory.You refuse to add a "compatible" string to your PCI device because you said the vendor/device id/class provides enough information to bind the driver, then why do you want to specify your devices in the device tree in the first place.
Quoted 8 lines
Quoted 3 lines
Because of the USB PHY , which is attached to that device and can not be probed on the PCI bus, unlike the device itself ?
You can create a new EHCI PCI driver to match your USB EHCI controller's vendor id/device id, and do any additional PHY setup in that driver. BTW what's the vendor id and device id of the EHCI controller on your board? I can have a look up at the PCI database.
Quoted 6 lines
You can not.
1033:00e0 -- https://pci-ids.ucw.cz/read/PC/1033/00e0
You can buy that controller as a discrete chip on a PCI card or have one in an SoC on a PCI bus, I have both.
Hardware vendors like to create such fantastic stuff in their SoCs, sigh. So how about subvendor and subdevice id? The embedded one can't be the same as the the discrete one. If they are really all the same, then why can't we add a specific compatible string to describe such device? The compatible idea was invented to describe devices that cannot be discovered via some probeable ways.
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
Quoted 8 lines
According to your
theory, "Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.", I would argue why not just creating a dedicate PCI device driver using PCI ID and class information to do the driver binding and start from there.Because the same device with the same PCI ID can be used without that PHY .
Quoted 6 lines
As you mentioned PCI bus is probable bus like USB, everything can be self-contained in the PCI device driver itself. There is no need to create nothing in the device tree. If you want an example, check
8250_pci.cin the Linux kernel. Everything that is needed to configure the driver is included in the driver itself. It does not read anything from the device tree.Well, see above for why this approach doesn't work.
Quoted 9 lines
Quoted 4 lines
Please explain why it does not work. I see Intel e1000 driver in the Linux kernel has lots of PHY configuration within the driver. It does not use any external PHY (eg: Marvell 88exxx) driver that Linux already has. The Ethernet PHY are not probeable on the PCI bus too.
That's a different thing, the ethernet MACs have an internal MDIO interface and you can scan the MDIO bus and read out PHY registers 0/1 to get the PHY ID.
Yes, I know. But my point is that Linux drivers are not always consistent. There is diversity and Linux is fine with that. There is also diversity when it comes to U-Boot PCI support and we have 2 supported PCI scenarios, the 1st of which can satisfy your use case.
Quoted 3 lines
This does not apply to this particular usecase here. In this case, the controller can be either embedded or discrete, with PHY or without PHY.
Does the embedded one have no register that can identify the PHY presence?
Quoted 101 lines
Quoted 47 lines
Quoted 47 lines
Quoted 46 lines
Quoted 36 lines
So again, how is the state of PCI more incomplete with this patch than without it ?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Yes, you probably don't care about this. But I care about this as it impacts some other things like PCI uart driver which is used by some x86 boards.
Sandbox changes impact PCI UART driver and x86 boards how ?
See above. It's not about sandbox!
So what is it about ? And how does this core change impact anything ? Does it change behavior for some board or break some tests for you ?
Quoted 22 lines
Quoted 22 lines
Quoted 21 lines
Quoted 11 lines
Quoted 10 lines
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txtQuoted 5 lines
I think you're just adding completely orthogonal stuff to this 5-liner patch into the list and overly complicate the situation. Sure, if you want to do all this, go ahead, but I don't see how this prevents this particular patch from being applied , except maybe for the documentation tweak.
Please, think from the maintainer perspective. It's nothing related to number of LOCs. It's that we need create a clean design. You probably don't want someone just submits a single patch that changed current USB design without a full consideration on all possible impacts.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
OK, after reading all this, what I gather from the discussion is that this patch somehow breaks the design or the other platforms, which is why you fight against it so much. Does it, yes or no? And if so, you still failed to explain how, so, how ?
You did not answer this question.
It's too early to go testing at this point because we are still discussing the design.
Quoted 7 lines
Quoted 3 lines
OK, so basically you didn't even try this patch to see if it actually has any impact anywhere. Sigh ...
I tend not to test a patch that is still under discussion to save some time. As there are several x86 boards to test with, along with sandbox. BTW you can test sandbox yourself.
I am positive this has nothing to do with sandbox, so I will not do that. If you think this patch has some potential impact on sandbox, please detail that or drop the sandbox topic from the discussion.
Quoted 26 lines
Quoted 26 lines
Quoted 3 lines
BTW your patch does not check the return value
ofofnode_get_addr_size(). It's possible to write a DT without "reg" property in a device node.That would be invalid DT, since you won't be able to match on the BFD. But that check can be added in V2.
Quoted 18 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Improving sandbox and x86 PCI handling is orthogonal to this change, so are ns16550 driver improvements and if you want to work on them, nothing prevents you from doing so.
First of all, it's not x86 PCI handling. It's PCI device driver clean up to match the new design.
Quoted 7 lines
It is not a new design, just an extension of the current one.
Driver cleanups where you match on PCI IDs or classes instead of compatible strings are completely orthogonal to this change, you don't even need this patch to do such a cleanup. Same applies for the x86 DT cleanup, you don't need this patch for those either.
Why would I? If there is no design changes, the clean up work to current drivers is out of the question as these drivers are supported user cases by current U-Boot PCI implementation.
Quoted 7 lines
Quoted 3 lines
Then leave them as is. But don't request unrelated cleansup from me either. I really do not understand why I should do those cleanups to get in an completely unrelated patch, that's just nonsense.
"Leave them as is", so what do we want to tell other PCI device driver developers in the community? To use whatever way they like? Eventually you created a 3rd scenario.
The message right now is there there is massive unwillingness to take PCI core changes, the current discussion just drags on and on and is just tiring, without any progress or constructive feedback. The only input I see is a mix of requests for clean-ups of unrelated DTs and drivers, which I cannot test and which can be done independently of this patch. It all feels like stalling to me, but I don't understand what the real goal is.
Quoted 5 lines
And regarding "leave them as is", yes, asking developers to clean up random unrelated part of U-Boot, just because they want to get a core patch in, doesn't make sense. If you want to send cleanups for your x86 or sandbox stuff, fine by me.
Regards,
Bin
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 1 line · Bin Meng
Hi Marek,
Hello Bin,
Quoted 46 lines · Marek Vasut
Quoted 38 lines · Bin Meng
[...]
Quoted 27 lines
Quoted 27 lines
Quoted 10 lines
Quoted 10 lines
I said in the previous discussion I am willing to update the documentation to match the implementation, but that's about it.
Quoted 6 lines
So far almost all PCI device drivers in U-Boot supports both scenarios, except PCI UART which currently only supports scenario#1. If you declare what you do in this patch is pureblood then you should revoke the other 2 at the same time. Leaving such in the mainstream only creates chaos in the future and we should avoid doing that, given we already had lots of discussion here.
Quoted 8 lines
Quoted 5 lines
No. The compatible is valid for some PCI subdevs, ie. bridges, so that has to stay. You also need compatible for sandbox, you said that yourself. And declaring a PCI device with BFD in DT is needed, ie. for the r8a7794-style bindings.
OK, now new comments :) So you admit "compatible" can be valid for some cases.
_some_ select ones, and that is a _very_ important distinction.
Quoted 5 lines
I have to point out that your theory on PCI device probing is self-contradictory.You refuse to add a "compatible" string to your PCI device because you said the vendor/device id/class provides enough information to bind the driver, then why do you want to specify your devices in the device tree in the first place.
Quoted 8 lines
Quoted 3 lines
Because of the USB PHY , which is attached to that device and can not be probed on the PCI bus, unlike the device itself ?
You can create a new EHCI PCI driver to match your USB EHCI controller's vendor id/device id, and do any additional PHY setup in that driver. BTW what's the vendor id and device id of the EHCI controller on your board? I can have a look up at the PCI database.
Quoted 6 lines
You can not.
1033:00e0 -- https://pci-ids.ucw.cz/read/PC/1033/00e0
You can buy that controller as a discrete chip on a PCI card or have one in an SoC on a PCI bus, I have both.
Quoted 6 lines
Hardware vendors like to create such fantastic stuff in their SoCs, sigh. So how about subvendor and subdevice id? The embedded one can't be the same as the the discrete one. If they are really all the same, then why can't we add a specific compatible string to describe such device? The compatible idea was invented to describe devices that cannot be discovered via some probeable ways.
I cannot if you look at the r8a7794 PHY phandles in the DT. The PHY connects to two devices and this is well modeled in DT.
Quoted 34 lines
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
According to your
theory, "Each PCI device already has a PCI ID and class which is used to identify it and based on which the drivers bind to it, so a DT compatible is NOT needed and is actually redundant and harmful.", I would argue why not just creating a dedicate PCI device driver using PCI ID and class information to do the driver binding and start from there.Because the same device with the same PCI ID can be used without that PHY .
Quoted 6 lines
As you mentioned PCI bus is probable bus like USB, everything can be self-contained in the PCI device driver itself. There is no need to create nothing in the device tree. If you want an example, check
8250_pci.cin the Linux kernel. Everything that is needed to configure the driver is included in the driver itself. It does not read anything from the device tree.Well, see above for why this approach doesn't work.
Quoted 9 lines
Quoted 4 lines
Please explain why it does not work. I see Intel e1000 driver in the Linux kernel has lots of PHY configuration within the driver. It does not use any external PHY (eg: Marvell 88exxx) driver that Linux already has. The Ethernet PHY are not probeable on the PCI bus too.
That's a different thing, the ethernet MACs have an internal MDIO interface and you can scan the MDIO bus and read out PHY registers 0/1 to get the PHY ID.
Yes, I know. But my point is that Linux drivers are not always consistent. There is diversity and Linux is fine with that. There is also diversity when it comes to U-Boot PCI support and we have 2 supported PCI scenarios, the 1st of which can satisfy your use case.
Quoted 5 lines
Quoted 3 lines
This does not apply to this particular usecase here. In this case, the controller can be either embedded or discrete, with PHY or without PHY.
Does the embedded one have no register that can identify the PHY presence?
No, why would it ? They are two completely separate blocks .
[...]
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
In reply to Bin MengHi Bin,
Quoted 254 lines · Bin Meng
Hi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
Quoted 108 lines · Marek Vasut
On 08/13/2018 04:24 AM, Bin Meng wrote:
Hi Marek,On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is
optional.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date U-Boot support of PCI bus with DM.
Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 12 lines
Quoted 12 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Quoted 6 lines
Quoted 3 lines
Again, the DT contains all the required information to bind the node and
the driver instance. Clearly, we need option 3 for this.Then that's a new design proposal. Anything that wants to mess up current design is a hack.
That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
* Assign the DT node to the bound device inpci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
Quoted 9 lines
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only use
U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
Thanks very much for all the info. But I don't understand why we want to remove compatible strings? They are part of the DT specification.
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 267 lines · Simon Glass
Hi Bin,
Quoted 254 lines · Bin Meng
Hi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
Quoted 112 lines · Bin Meng
Hi Marek,
On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut <[email protected]> wrote:
On 08/13/2018 04:24 AM, Bin Meng wrote:
Hi Marek,On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is
optional.Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
No it is not wrong. The documentation reflects the update-to-date
U-Boot support of PCI bus with DM.Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
Quoted 18 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Again, the DT contains all the required information to bind the node and
the driver instance. Clearly, we need option 3 for this.Then that's a new design proposal. Anything that wants to mess up
current design is a hack.That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
* Assign the DT node to the bound device inpci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:Quoted 9 lines
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only use
U_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
Quoted 2 lines
Thanks very much for all the info. But I don't understand why we want to remove compatible strings? They are part of the DT specification.
Unrelated orthogonal cleanup / optimization IMO.
Signature · 2 lines
Best regards, Marek Vasut
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Hi Marek,
Quoted 269 lines · Marek Vasut
Quoted 267 lines · Simon Glass
Hi Bin,
Quoted 263 lines · Bin Meng
Hi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 116 lines · Bin Meng
Hi Marek,
Quoted 113 lines · Marek Vasut
On 08/14/2018 03:46 AM, Bin Meng wrote:
Hi Marek,On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut <[email protected]> wrote:
On 08/13/2018 04:24 AM, Bin Meng wrote:
Hi Marek,On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is
optional.Quoted 8 lines
Quoted 5 lines
No it is not wrong. The documentation reflects the update-to-date
U-Boot support of PCI bus with DM.Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing subnodes with a "compatible" string existence.
It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
Quoted 21 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Again, the DT contains all the required information to bind the node and
the driver instance. Clearly, we need option 3 for this.Then that's a new design proposal. Anything that wants to mess up
current design is a hack.That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You are inserting words into my mouth and I dislike that." I said your current patch is against the design, and mess up current design which is a hack.
But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
* Assign the DT node to the bound device inpci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
Quoted 4 lines
Quoted 2 lines
Thanks very much for all the info. But I don't understand why we want to remove compatible strings? They are part of the DT specification.
Unrelated orthogonal cleanup / optimization IMO.
So can you just add a compatible string and everything works?
Regards,
Simon
PATCH 1/1 pci: Support parsing PCI controller DT subnodes
Quoted 272 lines · Simon Glass
Hi Marek,
Quoted 269 lines · Marek Vasut
Quoted 267 lines · Simon Glass
Hi Bin,
Quoted 263 lines · Bin Meng
Hi Simon,
Quoted 197 lines · Simon Glass
Hi Marek,
Quoted 194 lines · Marek Vasut
Quoted 192 lines · Simon Glass
Hi Bin,
Quoted 179 lines · Bin Meng
Hi Marek,
Quoted 176 lines · Marek Vasut
Quoted 174 lines · Tom Rini
Quoted 164 lines · Bin Meng
Hi Marek,
Quoted 152 lines · Marek Vasut
Quoted 124 lines · Bin Meng
Hi Marek,
On Tue, Aug 14, 2018 at 4:55 PM, Marek Vasut <[email protected]> wrote:
On 08/14/2018 03:46 AM, Bin Meng wrote:
Hi Marek,On Mon, Aug 13, 2018 at 9:46 PM, Marek Vasut <[email protected]> wrote:
On 08/13/2018 04:24 AM, Bin Meng wrote:
Hi Marek,On Fri, Aug 10, 2018 at 8:38 PM, Marek Vasut <[email protected]> wrote:
On 08/10/2018 02:01 PM, Tom Rini wrote:
On Wed, Aug 08, 2018 at 09:37:25PM +0200, Marek Vasut wrote:
On 08/08/2018 05:32 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 10:33 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:39 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:24 PM, Marek Vasut <[email protected]> wrote:
On 08/08/2018 03:14 PM, Bin Meng wrote:
Hi Marek,On Wed, Aug 8, 2018 at 9:03 PM, Marek Vasut <[email protected]> wrote:
The PCI controller can have DT subnodes describing extra properties
of particular PCI devices, ie. a PHY attached to an EHCI controller
on a PCI bus. This patch parses those DT subnodes and assigns a node
to the PCI device instance, so that the driver can extract details
from that node and ie. configure the PHY using the PHY subsystem.Signed-off-by: Marek Vasut <[email protected]>
Cc: Simon Glass <[email protected]>
---
drivers/pci/pci-uclass.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 46e9c71bdf..306bea0dbf 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -662,6 +662,8 @@ static int pci_find_and_bind_driver(struct udevice *parent,
for (id = entry->match;
id->vendor || id->subvendor || id->class_mask;
id++) {
+ ofnode node;
+
if (!pci_match_one_id(id, find_id))
continue;@@ -691,6 +693,18 @@ static int pci_find_and_bind_driver(struct udevice *parent,
goto error;
debug("%s: Match found: %s\n", __func__, drv->name);
dev->driver_data = find_id->driver_data;
+
+ dev_for_each_subnode(node, parent) {
+ phys_addr_t df, size;
+ df = ofnode_get_addr_size(node, "reg", &size);
+
+ if (PCI_FUNC(df) == PCI_FUNC(bdf) &&
+ PCI_DEV(df) == PCI_DEV(bdf)) {
+ dev->node = node;
+ break;
+ }The function pci_find_and_bind_driver() is supposed to bind devices
that are NOT in the device tree. Adding device tree access in this
routine is quite odd. You can add the EHCI controller that need such
PHY subnodes in the device tree and there is no need to modify
anything I believe. If you are looking for an example, please check
pciuart0 in arch/x86/dts/crownbay.dts.Well this does not work for me, the EHCI PCI doesn't get a DT node
assigned, check r8a7794.dtsi for the PCI devices I use.I think that's because you don't specify a "compatible" string for
these two EHCI PCI nodes.That's perfectly fine, why should I specify it ? Linux has no problem
with it either.Without a "compatible" string, DM does not bind any device in the
device tree to a driver, hence no device node created. This is not
Linux.DT is NOT Linux specific, it is OS-agnostic, DT describes hardware and
hardware only. If U-Boot cannot parse DT correctly, U-Boot is broken and
must be fixed.This is a fix. If there is a better fix, I am open to it.
DT should but isn't always OS agnostic. DTS files that reside in the
Linux Kernel are in practice is Linux-centric with the expectation that
even if you could solve a given problem with valid DTS changes you make
whatever is parsing it do additional logic instead. That,
approximately, is what your patch is doing. If you added some HW
description information to the dtsi file everything would work as
expected as your DTS is describing the hardware and U-Boot is reading
that description and figuring out what to do with it.Yes, you need additional logic to match the PCI controller subnode in DT
with PCI device BFD, that's expected. You do NOT need extra compatibles,
the PCI bus gives you enough information to match a driver on them. In
fact, adding a compatible can interfere with this matching.Please, read U-Boot's doc/driver-model/pci-info.txt. You really don't
understand current implementation in U-Boot. In short, U-Boot supports
two scenarios for PCI driver binding:That documentation is wrong and needs to be fixed. The compatible is
optional.No it is not wrong. The documentation reflects the update-to-date
U-Boot support of PCI bus with DM.Which is incomplete, as it cannot parse subnodes without compatible strings.
No, it's by design, as I said many times. It can support parsing
subnodes with a "compatible" string existence.It can support parsing subnodes with a "compatible" string existence AND It can NOT support parsing subnodes without a "compatible" string existence THUS It is incomplete.
Quoted 22 lines
- Declare a PCI device in the device tree. That requires specifying a
'compatible' string as well as 'reg' property as defined by the 'PCI
Bus Binding' spec. DM uses the 'compatible' string to bind the driver
for the device.
- Don't declare a PCI device in the device tree. Instead, using
U_BOOT_PCI_DEVICE() to declare a device and driver mapping.You can choose either two when you support PCI devices on your board,
but you cannot mix both support together and make them a mess. In this
patch, you hacked pci_find_and_bind_driver() which is the 2nd scenario
to support the 1st scenario.Again, the DT contains all the required information to bind the node and
the driver instance. Clearly, we need option 3 for this.Then that's a new design proposal. Anything that wants to mess up
current design is a hack.That means every single patch anyone submits is now a hack ? Please ...
Quoted 8 lines
Quoted 4 lines
I never said "every single patch anyone submits is now a hack". "You
are inserting words into my mouth and I dislike that." I said your
current patch is against the design, and mess up current design which
is a hack.But then every patch which changes the behavior is against "the design" and thus is a hack. Ultimately, most improvements would be considered a hack.
Quoted 6 lines
No it depends. For this case, there are two options that DM PCI currently provides. You created a 3rd option that bring option 1 and 2 together in a mixed way, yet without any documenting and additional other changes. If you posted such changes in a series and have all stuff well considered, I would not consider it a hack, but a proposed design change.
Also, the design document is not immutable and can and should be updated as needed to match changes in the code.
Quoted 7 lines
Quoted 3 lines
So what is the conclusion here ? Patch the design document and apply this patch as is ?
I think we should see Simon's comments before we move forward. The proposal I made before should come in a series, not just documentation.
This thread is too long :-)
Yes, too long discussion :)
Quoted 18 lines
Quoted 9 lines
Quoted 7 lines
From what I understand, Marek and Bin are discussing whether a compatible string is needed to bind a driver.
Generally it is. But with PCI and USB we have a search mechanism which can be used instead.
The patch Marek submitted does not seems at all desirable to me.
Can you explain why ?
We already have a compatible string as the standard way to attach drivers to devices.
For PCI, we already have
PCI_DEVICE()and friends for when we can attach a driver for a PCI device without using a compatible string.Both of these are defined in the DT specification.
Quoted 8 lines
The patch seems to be a rework of
PCI_DEVICE()and I cannot why it is necessary.Quoted 4 lines
Quoted 2 lines
I would like to see what Bin proposes.
Me too, so far I only see "not Marek's patch" and no real alternative.
Bin, do you have a patch you can share?
No, I don't have any patch series for now, although I offered to work on a series to implement my proposal. I haven't started it as I wanted to hear your thoughts. The proposal I made is to satisfy the requirement that Marek insisted on. Basically Marek thought current DM PCI implementation is wrong to ask for a "compatible" string of a PCI device in the device tree, because he thought adding "compatible" to DT is invalid and Linux does not do that either. While I disagree we have to 100% follow Linux's implementation, I am still open for any possible design changes, if that's the preferable practice in U-Boot (but we have to make it clear and document this officially somewhere).
The proposal I made is:
* Keep pci-uclass driver's
post_bind()andchild_post_bind()only for Sandbox configuration
* Keep the call topci_bus_find_devfn()inpci_bind_bus_devices()only for Sandbox configuration
* Sandbox is special. We should limit the mechanism of matching PCI emulation device via "compatible" to sandbox only
* Assign the DT node to the bound device inpci_find_and_bind_driver()if there is a valid PCI "reg" encoding for a specific PCI device in the device tree
* Create DM PCI test case against the DT node assignment
* Remove all compatible string in U-Boot's PCI device drivers: eg:
ehci_pci_ids[], xhci_pci_ids[], etc. IOW, all PCI device drivers should only useU_BOOT_PCI_DEVICE(), aka the original U-Boot option 2
* Fork a "pci-ns16550" driver to supportU_BOOT_PCI_DEVICE(), as currently PCI ns16550 device driver uses "compatible" string to do the matching, and updatecrownbay.dtsandgalileo.dts(so far I only know two boards are using PCI ns16550 serial port)
* Make sure all DM PCI test cases are not broken
* Document all of the above changes indoc/driver-model/pci-info.txt
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Thanks very much for all the info. But I don't understand why we want to remove compatible strings? They are part of the DT specification.
Unrelated orthogonal cleanup / optimization IMO.
So can you just add a compatible string and everything works?
No, because that makes no sense. The code can very well match the driver on the PCI IDs or classes, the DT node is supplementary information and it needs to be made available to the matched driver if present in the DT. The DT node is matched on the BFD (the reg property in the DT).
The compatible string would only add redundancy and can in fact be harmful in case the PCI device could be replaced (ie. swapping USB EHCI controller for USB xHCI controller while retaining the USB PHY ; the controller itself could be discovered on the PCI bus, but the PHY can not and must be described in the DT).
Signature · 2 lines
Best regards, Marek Vasut