Hi Sjoerd,
On Mon, Oct 5, 2015 at 3:55 AM, Sjoerd Simons
<sjoerd.sim...@collabora.co.uk> wrote:
>
> On Sat, 2015-10-03 at 15:30 +0100, Simon Glass wrote:
> > Hi Sjoerd,
>
> > > static int designware_eth_send(struct udevice *dev, void *packet,
> > > int length)
> > > diff --git a/drivers/net/designware.h b/drivers/net/designware.h
> > > index 47e727b..b45599b 100644
> > > --- a/drivers/net/designware.h
> > > +++ b/drivers/net/designware.h
> > > @@ -236,6 +236,10 @@ struct dw_eth_dev {
> > > #endif
> > > struct phy_device *phydev;
> > > struct mii_dev *bus;
> > > +
> > > +#ifdef CONFIG_DM_ETH
> > > + int (*started)(struct udevice *dev);
> > > +#endif
> >
> > With driver model we should not need to add such hooks. is this
> > needed
> > because we don't have a PHY uclass yet?
>
> Essentially I need to be able to configure one of the GMAC clocks
> depending on the result of the phy negotiation. Looking at the linux
> kernel this seems a rather common item for the dw gmac interface.
>
> I guess, I could do without that hook by exporting all functions
> required to fill the eth_ops struct and override the start function.
> Would you prefer that?
I prefer the hook.
> I guess a PHY uclass would also help here, assuming such a uclass would
> provide a callback for link state changes (e.g. like of_phy_connect in
> Linux).
I agree that once we have the phy uclass then we should handle it much
more like Linux, but for now the hook seems cleaner.
> > > };
> > >
> > > #ifdef CONFIG_DM_ETH
> > > --
> > > 2.5.3
> > >
> >
> > Regards,
> > Simon
>
> --
> Sjoerd Simons
> Collabora Ltd.
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
