RE: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHYlayer functionality

[Joakim Tjernlund]

[SNIP]
> ^^ the correct solution is to implement arch_initcall function
> which will create fixed PHYs, and then leave only
> snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data); part in the
> fs_enet's find_phy().
> 
> Try add something like this to the fsl_soc.c (compile untested):
> 
> - - - -
> static int __init of_add_fixed_phys(void)
> {
> 	struct device_node *np;
> 	const u32 *prop;
> 	struct fixed_phy_status status = {};
> 
> 	while ((np = of_find_node_by_name(NULL, "ethernet"))) {
> 		data  = of_get_property(np, "fixed-link", NULL);
> 		if (!data)
> 			continue;
> 
> 		status.link = 1;
> 		status.duplex = data[1];
> 		status.speed  = data[2];

What about Pause and Asym_Pause? Dunno why so few, if any, eth drivers
impl. it, but the PHY lib supports it.
Even if fixed PHYs doesn't support it directly I think the OF interface
should have it.

    - fixed-link : <a b c d e> where a is emulated phy id - choose any,
      but unique to the all specified fixed-links, b is duplex - 0 half,
      1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no pause,
      1 pause, d asym_pause - 0 no asym_pause, 1 asym_pause.

Jocke

> 
> 		ret = fixed_phy_add(PHY_POLL, data[0], &status);
> 		if (ret)
> 			return ret;
> 	}
> 
> 	return 0;
> }
> arch_initcall(of_add_fixed_phys);
> - - - -
> 
> And remove fixed_phy_add() from the fs_enet. This should work
> nicely and also should be ideologically correct. ;-)
> 
> > How is this supposed to work for modules or for the
> > PPC_CPM_NEW_BINDING mode where the device tree is no longer scanned
> > during fs_soc initialization but during device initialization?
> 
> We should mark fixed.c as bool. Fake/virtual/fixed/platform PHYs
> creation is architecture code anyway, can't be =m.
> 
> -- 
> Anton Vorontsov
> email: cbou@xxxxxxx
> backup email: ya-cbou@xxxxxxxxx
> irc://irc.freenode.net/bd2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/