netdev - Re: [PATCH] dp83640: Support a configurable number of periodic outputs

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: <1391511238.3003.25.camel@deadeye.wl.decadent.org.uk>
Date:	Tue, 04 Feb 2014 10:53:58 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Stefan Sørensen 
	<stefan.sorensen@...ctralink.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] dp83640: Support a configurable number of periodic
 outputs

On Tue, 2014-02-04 at 10:29 +0100, Richard Cochran wrote:
> On Tue, Feb 04, 2014 at 09:52:22AM +0100, Stefan Sørensen wrote:
> > The driver is currently limited to a single periodic output.
> > This patch makes the number of peridodic output dynamic by
> > dropping the gpio_tab module parameter and adding cal_gpio,
> > perout_gpio_tab and extts_gpio_tabs parameters.
> 
> ...
> 
> >  module_param(chosen_phy, int, 0444);
> > -module_param_array(gpio_tab, ushort, NULL, 0444);
> > +module_param(cal_gpio, int, 0444);
> > +module_param_array(perout_gpio_tab, int, &n_perout, 0444);
> > +module_param_array(extts_gpio_tab, int, &n_extts, 0444);
> >  
> >  MODULE_PARM_DESC(chosen_phy, \
> >  	"The address of the PHY to use for the ancillary clock features");
> > -MODULE_PARM_DESC(gpio_tab, \
> > -	"Which GPIO line to use for which purpose: cal,perout,extts1,...,extts6");
> > +MODULE_PARM_DESC(cal_gpio, "Which GPIO line to use for calibration");
> > +MODULE_PARM_DESC(perout_gpio_tab, "Which GPIO lines to use for periodic output");
> > +MODULE_PARM_DESC(extts_gpio_tab, "Which GPIO lines to use for external timestamping");
> 
> Modules parameters are surely easiest (for the developer), but perhaps
> the time has come for the "right way."
> 
> Currently there is no interface for configuring the GPIOs used by PHC
> devices, and last year I was going to add the GPIOs to the igb
> driver. The conclusion of the discussion was that module parameters
> are bad for this, but ethtool is good.
> 
>   http://www.spinics.net/lists/netdev/msg237692.html
> 
> [ I did not follow through to come up with an ethtool way of configuring
>   the igb pins. ]
> 
> Even though it is more work, I think the way forward is to invent a
> way to let the user configure this kind of thing via ethtool. Would
> you care to take a stab at this?

It seems to me that this is board configuration, not user configuration,
so it should be defined in DT or ACPI or whatever.

Are there boards which expose multiple GPIOs for users to plug together
PPS signals?

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)