On 08/14/2012 06:08 PM, Timur Tabi wrote:
Scott Wood wrote:
quoted
If anything, I'd make the ordering be "wrong" to force that code path to
be tested -- though ideally there would be a more systematic approach to
such testing, that doesn't require inefficiency during normal boot.
I can't force the ordering to be wrong, because it's the only entry in the
list. The DPAA entries are not there yet.
Right, I mean once the DPAA entries are added.
This is what I have now:
static const struct of_device_id of_device_ids[] __devinitconst = {
{
.compatible = "simple-bus"
},
{
.compatible = "fsl,srio",
},
{
.compatible = "fsl,p4080-pcie",
},
{
.compatible = "fsl,qoriq-pcie-v2.2",
},
{
.compatible = "fsl,qoriq-pcie-v2.3",
},
{
.compatible = "fsl,qoriq-pcie-v2.4",
},
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
},
{
.name = "handles",
},
{
/*
* Warning: this entry might need to be located before those
* for the Fman Ethernet nodes, although using EPROBE_DEFER
* in the DPAA drivers could fix that.
*/
.compatible = "mdio-mux",
},
I'd either say nothing here or say only "The ethernet driver should use
EPROBE_DEFER to ensure that the mdio-mux is probed first". Don't give
whoever submits the DPAA ethernet driver the idea that relying on list
order is an acceptable solution.
-Scott