RE: [PATCH net-next v2] macb: Common code to enable ptp support for MACB/GEM

[Rafal Ozieblo]

>-----Original Message-----
>From: Nicolas Ferre [mailto:nicolas.ferre@xxxxxxxxx] 
>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:harinikatakamlinux@xxxxxxxxx] 
>>> 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 <rafalo@xxxxxxxxxxx> wrote:
>>>>> -----Original Message-----
>>>>> From: Andrei Pistirica [mailto:andrei.pistirica@xxxxxxxxxxxxx]
>>>>> 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
>