On Wed, Mar 11, 2015 at 11:20:59AM +0000, Stathis Voukelatos wrote: > Our feeling is that we will have to test and verify that a move to gPTP > will fit with the use cases that we have to support and that will > require a fair amount of effort and rewrite of application software. > If the driver is not acceptable with the current interface we may need > to maintain it as a private patch until we are ready to move to gPTP > as you recommend. Sure, there is nothing wrong with that. For the kernel, we want to build good interfaces for future applications. Sometimes reworking the applications that use the old, private interfaces is just too much work, so you have to maintain those interfaces in your products. > I was referring to the Songcast protocol we are using which is part > of the OpenHome suite (www.openhome.org) and runs on top of UDP. > It could be filtered by testing the first 5 bytes of the payload. Sounds promising. > In our implementation we also add the destination IP and port to > the filter to make it more reliable, but hwtstamp_rx_filters cannot > accept parameters. If the IP is a defined multicast group address, and if the port is well a known port, then you should of course include them in the driver level filter. Adding a unicast destination IP doesn't make it more reliable, because frames addressed to other hosts are switched away from the host (or dropped by the MAC). > However, I will test that and maybe come back with > a patch to expand the hwtstamp_rx_filter enum initially? It probably makes more sense to present the expanded filter list in the same patch series with the new driver that uses it, in order to see the context. So I would hold off posting until both are ready. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
