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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ