From: Nicolas Pitre
Date: Tue, 20 Sep 2016 15:56:38 -0400
> Many embedded systems don't need the full POSIX timer support.
> Configuring them out provides a nice kernel image size reduction.
>
> When POSIX timers are configured out, the PTP clock subsystem should be
> left out as well. However a
On Wed, 21 Sep 2016 10:38:52 +0200, Richard Cochran wrote:
> Embedded people like to optimize their systems. One pattern I have
> more than once is that a multihomed design designates a special PTP
> interface, often with a different HW than the other ports. PTP
> support adds extra code into the
On Tue, 20 Sep 2016 23:09:52 +0200 (CEST), Thomas Gleixner wrote:
> Now if you want to distangle PTP from a driver then you split it at the
> driver level and not at the PTP level:
>
> DRIVER_X
> tristate "Driver X"
>
> DRIVER_X_PTP
> bool "Enable PTP suppo
On Tue, 20 Sep 2016, Nicolas Pitre wrote:
> There are way more drivers than subsystems and if you had to go around
> unselecting all NIC drivers for CONFIG_ETHERNET to be turned off, and
> with CONFIG_ETHERNET=n you'd finally be able to turn networking off,
> then this would be a nightmare.
It'
On Tue, Sep 20, 2016 at 06:47:02PM -0400, Nicolas Pitre wrote:
> IMHO it is much nicer for the poor user configuring the kernel to have a
> single configuration prompt for PTP support, and then have whatever
> driver that can provide a PTP clock just do it (or omit it) based on
> that single pro
On Tue, 20 Sep 2016, Thomas Gleixner wrote:
> I think the whole approach is wrong because it makes the PTP split at the
> wrong level.
>
> Currently we have:
>
> DRIVER_X
> tristate "Driver X"
> select PTP
>
> In order to make POSIX_CLOCK configurable we should have
>
>
On Tue, 20 Sep 2016, Nicolas Pitre wrote:
> On Tue, 20 Sep 2016, Richard Cochran wrote:
>
> > On Tue, Sep 20, 2016 at 10:25:56PM +0200, Richard Cochran wrote:
> > > After this series, if I don't pay enough attention to dmesg, then I
> > > have lost functionality that I had in step #1. That sucks,
On Tue, 20 Sep 2016, Richard Cochran wrote:
> On Tue, Sep 20, 2016 at 10:25:56PM +0200, Richard Cochran wrote:
> > After this series, if I don't pay enough attention to dmesg, then I
> > have lost functionality that I had in step #1. That sucks, and it has
> > nothing to do with the tinification
On Tue, 20 Sep 2016, Richard Cochran wrote:
> On Tue, Sep 20, 2016 at 03:56:38PM -0400, Nicolas Pitre wrote:
> > - Add a warning for the case where PTP clock subsystem is modular and a
> > driver providing a clock is built-in rather than silently ignoring it.
> > Suggested by Jiri Benc.
>
> S
On Tue, Sep 20, 2016 at 10:25:56PM +0200, Richard Cochran wrote:
> After this series, if I don't pay enough attention to dmesg, then I
> have lost functionality that I had in step #1. That sucks, and it has
> nothing to do with the tinification option at all. It will bite even
> if I have no know
On Tue, Sep 20, 2016 at 03:56:38PM -0400, Nicolas Pitre wrote:
> - Add a warning for the case where PTP clock subsystem is modular and a
> driver providing a clock is built-in rather than silently ignoring it.
> Suggested by Jiri Benc.
So I am really not happy with this. Here is a common embe
Many embedded systems don't need the full POSIX timer support.
Configuring them out provides a nice kernel image size reduction.
When POSIX timers are configured out, the PTP clock subsystem should be
left out as well. However a bunch of ethernet drivers currently *select*
it in their Kconfig entr
12 matches
Mail list logo