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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120921173709.GB6129@netboy.at.omicron.at>
Date:	Fri, 21 Sep 2012 19:37:10 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Jacob Keller <jacob.e.keller@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	John Stultz <john.stultz@...aro.org>,
	Matthew Vick <matthew.vick@...el.com>
Subject: Re: [PATCH net-next 3/3] ptp: derive the device name from the
 parent device

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:
> > 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.

> > +       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.

> > -	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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html