On Wed, Dec 18, 2013 at 05:43:59PM -0500, David Miller wrote: > > I think this begs an even more fundamental question, why isn't the PTP > driver abstraction providing the necessary methods and interfaces so > that pch_gbe doesn't have to call into the ptp_pch.c code directly?
Really it is more of a driver issue. For MAC based PTP clocks, they are so tightly coupled to the MAC driver that it is better *not* to have the PTP functions in a separate module. Instead, if having the PTP stuff optional makes sense, then the PTP parts are just a compile time option in the MAC driver. This is how the other MAC drivers with optional PTP are structured. > Moving ptp_pch.c elsehwere is not desirable, it's a PTP driver so > it belongs under drivers/ptp. > > Someone who understands all of these components needs to sort this > out cleanly, this patch isn't it. I am getting a bit tired of all the trouble over the past year caused by this particular driver. After it got merged, the original authors disappeared. I would really like to see this driver follow the pattern of bfin_mac, ti/cpts, and tile. Maybe I'll have to do it myself, like the Red Hen. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
