Hi,
On Tue, Oct 6, 2015 at 12:39 AM, Joe Hershberger
<joe.hershber...@gmail.com> wrote:
> 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).
>
>From what I read to this codes, the work done in the hook is to
program the MAC's clock, not the PHY. So not sure if the PHY uclass
can help here.
> 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.
>
Has anyone looked at my suggestion about where we should insert the hook?
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
