[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <14dfa3ac-344f-5185-fd83-06b3c9884b5c@kernel.org>
Date: Fri, 13 Jan 2023 12:21:37 +0200
From: Roger Quadros <rogerq@...nel.org>
To: Siddharth Vadapalli <s-vadapalli@...com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, robh+dt@...nel.org,
krzysztof.kozlowski@...aro.org, krzysztof.kozlowski+dt@...aro.org,
nm@...com, kristo@...nel.org, vigneshr@...com, nsekhar@...com,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
srk@...com
Subject: Re: [PATCH net-next 0/5] Add PPS support to am65-cpts driver
On 13/01/2023 11:56, Siddharth Vadapalli wrote:
> Hello Roger,
>
> On 13/01/23 15:18, Roger Quadros wrote:
>> Siddharth,
>>
>> On 11/01/2023 13:44, Siddharth Vadapalli wrote:
>>> The CPTS hardware doesn't support PPS signal generation. Using the GenFx
>>> (periodic signal generator) function, it is possible to model a PPS signal
>>> followed by routing it via the time sync router to the CPTS_HWy_TS_PUSH
>>> (hardware time stamp) input, in order to generate timestamps at 1 second
>>> intervals.
>>>
>>> This series adds driver support for enabling PPS signal generation.
>>> Additionally, the documentation for the am65-cpts driver is updated with
>>> the bindings for the "ti,pps" property, which is used to inform the
>>> pair [CPTS_HWy_TS_PUSH, GenFx] to the cpts driver. The PPS example is
>>> enabled for AM625-SK board by default, by adding the timesync_router node
>>> to the AM62x SoC, and configuring it for PPS in the AM625-SK board dts.
>>>
>>> Grygorii Strashko (3):
>>> dt-binding: net: ti: am65x-cpts: add 'ti,pps' property
>>> net: ethernet: ti: am65-cpts: add pps support
>>> net: ethernet: ti: am65-cpts: adjust pps following ptp changes
>>>
>>> Siddharth Vadapalli (2):
>>> arm64: dts: ti: k3-am62-main: Add timesync router node
>>> arm64: dts: ti: k3-am625-sk: Add cpsw3g cpts PPS support
>>
>> Device tree patches need to be sent separately. You don't need to involve
>> net maintainers for that.
>>
>> If you introduce a new binding then that needs to be in maintainer's
>> tree before you can send a related device tree patch.
>
> Thank you for letting me know. Would I need to resend the series in order for it
> to be reviewed? I was hoping that if I get feedback for this series, I will
> implement it and post just the bindings and driver patches as the v2 series,
> dropping the device tree patches. Please let me know.
You could wait a couple of days for more comments here before spinning off a v2 ;)
cheers,
-roger
Powered by blists - more mailing lists