Thread (15 messages) flat view 15 messages, 3 authors, 2012-09-24

Re: [PATCH net-next 3/3] ptp: derive the device name from the parent device

From: Richard Cochran <richardcochran@gmail.com>
Date: 2012-09-21 17:37:21

On Fri, Sep 21, 2012 at 06:19:25PM +0100, Ben Hutchings wrote:
On Fri, 2012-09-21 at 19:00 +0200, Richard Cochran wrote:
quoted
PTP Hardware Clock device have a name that appears under sysfs that should
identify the underlying device. Instead of leaving it up to the driver to
invent a name, this patch changes the registration to automatically use
the name from the parent device.
I thought you wanted the driver name and not the parent device name?
Yes, I originally wanted the driver name, because it gives the user
information about the expected performance. But here I am bowing to
Jacob's suggestion that we really need to identify the device. Intel
cards with two ports have *two* clocks. Sad but true.
quoted
+       ptp->name = parent ? dev_name(parent) : dev_name(ptp->dev);
+
The fallback of using dev_name(ptp->dev) is a bit sad, as that's the
same name userland already has when it reads this attribute.
This fallback only exists for the ixp46x, since that driver has no
proper platform or device tree device.
quoted
-	ixp_clock.ptp_clock = ptp_clock_register(&ixp_clock.caps);
+	ixp_clock.ptp_clock = ptp_clock_register(&ixp_clock.caps, NULL);
[...]

I think this should really register a platform driver and a platform
device to be the parent of the clock device.  And then you don't need
the fallback for parent == NULL.
That chip is long past EOL, and its PTP capabilities are pretty poor,
and so it is not worth the trouble of fixing it up.

All other (and future) drivers must provide the pointer.
 
Since David has pulled the addition of PTP/PHC support to sfc, that will
need to be adjusted as well.
Okay, I will add that to the series.

Thanks,
Richard
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help