>-----Original Message----- >From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] >Sent: 27 stycznia 2017 11:28 >Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support for >MACB/GEM > >Le 27/01/2017 à 11:26, Rafal Ozieblo a écrit : >>> -----Original Message----- >>> From: Harini Katakam [mailto:harinikatakamli...@gmail.com] >>> Sent: 27 stycznia 2017 06:43 >>> Subject: Re: [PATCH net-next v2] macb: Common code to enable ptp support >>> for MACB/GEM >>> >>> Hi Rafal, >>> >>> On Thu, Jan 26, 2017 at 8:45 PM, Rafal Ozieblo <raf...@cadence.com> wrote: >>>>> -----Original Message----- >>>>> From: Andrei Pistirica [mailto:andrei.pistir...@microchip.com] >>>>> Sent: 19 stycznia 2017 16:56 >>>>> Subject: [PATCH net-next v2] macb: Common code to enable ptp support for >>>>> MACB/GEM >>>>> >>>>> >>>>> +static inline bool gem_has_ptp(struct macb *bp) >>>>> +{ >>>>> + return !!(bp->caps & MACB_CAPS_GEM_HAS_PTP); >>>>> +} >>>> Why don't you use hardware capabilities here? Would it be better to read >>>> it from hardware instead adding it to many configuration? >>> >>> If you are referring to TSU bit in DCFG5, then we will be relying on >>> Cadence IP's information irrespective of the SoC capability >>> and whether the PTP support was adequate. >>> I think the capability approach gives better control and >>> it is not really much to add. >>> >>> Regards, >>> Harini >>> >> Yes, I'm referring to TSU bit. >> What if SoC contains multiple Cadence GEMs, some with PTP support and others >> without? > >Simply define different DT compatibility strings and we're good.
What with GEM on PCI ? There is no DT. >> Relevant will be checking both, hardware capabilities and SoC capabilities >> from "caps" field. >> > > >-- >Nicolas Ferre >
