On Wed, Dec 18, 2013 at 05:43:59PM -0500, David Miller wrote: > From: Richard Cochran <richardcoch...@gmail.com> > Date: Mon, 16 Dec 2013 09:58:40 +0100 > > > On Mon, Dec 16, 2013 at 02:14:15AM +0530, Rashika Kheria wrote: > >> --- > >> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 9 --------- > >> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 1 + > >> drivers/ptp/ptp_pch.c | 1 + > >> include/linux/ptp_pch.h | 16 ++++++++++++++++ > >> 4 files changed, 18 insertions(+), 9 deletions(-) > >> create mode 100644 include/linux/ptp_pch.h > > > > Instead of adding a random driver header into include/linux, I would > > prefer that you just move the ptp_pch.c from drivers/ptp to > > drivers/net/ethernet/oki-semi/pch_gbe. Then you can just include > > pch_gbe.h directly. > > 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? > > Moving ptp_pch.c elsehwere is not desirable, it's a PTP driver so > it belongs under drivers/ptp.
For the moment, at least, would it be reasonable to have a proper header for these functions since pch_gbe is currently calling them? Making that driver *not* call those functions might well be a sensible cleanup, but does fixing this issue need to wait for that cleanup to happen? - Josh Triplett -- 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/
