* Markus Pargmann <mpa@xxxxxxxxxxxxxx> [140908 23:05]:
> On Mon, Sep 08, 2014 at 09:51:17AM -0700, Tony Lindgren wrote:
> > * Markus Pargmann <mpa@xxxxxxxxxxxxxx> [140907 10:20]:
> > > This patch adds a function to get the MACIDs from the am33xx SoC
> > > control module registers which hold unique vendor MACIDs. This is only
> > > used if of_get_mac_address() fails to get a valid mac address.
> > ...
> >
> > > @@ -1928,8 +1960,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
> > > PHY_ID_FMT, mdio->name, phyid);
> > >
> > > mac_addr = of_get_mac_address(slave_node);
> > > - if (mac_addr)
> > > + if (mac_addr) {
> > > memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
> > > + } else {
> > > + if (of_machine_is_compatible("ti,am33xx")) {
> > > + ret = cpsw_am33xx_cm_get_macid(&pdev->dev, i,
> > > + slave_data->mac_addr);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > + }
> > >
> > > slave_data->phy_if = of_get_phy_mode(slave_node);
> > > if (slave_data->phy_if < 0) {
> >
> > Thanks for updating this, this looks more future proof for adding
> > the dra7 related patch.
> >
> > For the long run, it probably makes sense to add SoC specific
> > compatible values such as "ti,cpsw-am3350" and so on. Then the
> > mac address functions can be initialized based on the of_device_id
> > entry for .data. The wiring is cleary SoC specific here.
>
> The hardware doesn't differ across the SoCs, so I thought it may be
> better to keep one compatible and parse the machine compatible for the
> MACID location. But different compatible values are also ok.
Yes both will work, and you're right the Ethernet hardware is
the same. I already forgot that we're getting mac address from the
system control module.. And that's really SoC specific so your solution
is better at least for now.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
