On Sun, Sep 18, 2016 at 04:30:21PM -0400, Nicolas Pitre wrote:
> I don't think the driver changes are significant enough to warrant a ACK
> from individual driver maintainers.
>
> Yours would be welcome though. ;-)
Acked-by: Richard Cochran
> Then I'll resend the
On Sun, Sep 18, 2016 at 04:30:21PM -0400, Nicolas Pitre wrote:
> I don't think the driver changes are significant enough to warrant a ACK
> from individual driver maintainers.
>
> Yours would be welcome though. ;-)
Acked-by: Richard Cochran
> Then I'll resend the whole thing to John as a
On Sun, 18 Sep 2016, Richard Cochran wrote:
> On Sun, Sep 18, 2016 at 02:49:08PM -0400, Nicolas Pitre wrote:
> > Who should merge this patch?
>
> John, I guess. Or do we need acks from the driver maintainers? In
> that case, please post to netdev, and then davem can merge it.
I don't think
On Sun, 18 Sep 2016, Richard Cochran wrote:
> On Sun, Sep 18, 2016 at 02:49:08PM -0400, Nicolas Pitre wrote:
> > Who should merge this patch?
>
> John, I guess. Or do we need acks from the driver maintainers? In
> that case, please post to netdev, and then davem can merge it.
I don't think
On Sun, Sep 18, 2016 at 02:49:08PM -0400, Nicolas Pitre wrote:
> Who should merge this patch?
John, I guess. Or do we need acks from the driver maintainers? In
that case, please post to netdev, and then davem can merge it.
Thanks,
Richard
On Sun, Sep 18, 2016 at 02:49:08PM -0400, Nicolas Pitre wrote:
> Who should merge this patch?
John, I guess. Or do we need acks from the driver maintainers? In
that case, please post to netdev, and then davem can merge it.
Thanks,
Richard
On Sun, 18 Sep 2016, Richard Cochran wrote:
> On Sun, Sep 18, 2016 at 12:54:58PM -0400, Nicolas Pitre wrote:
> > > > +config PTP_1588_CLOCK_DEFAULT
> > > > + tristate
> > >
> > > I see what this option is doing, but I wonder about the name
> > > "DEFAULT". In what sense is this a default?
On Sun, 18 Sep 2016, Richard Cochran wrote:
> On Sun, Sep 18, 2016 at 12:54:58PM -0400, Nicolas Pitre wrote:
> > > > +config PTP_1588_CLOCK_DEFAULT
> > > > + tristate
> > >
> > > I see what this option is doing, but I wonder about the name
> > > "DEFAULT". In what sense is this a default?
On Sun, Sep 18, 2016 at 12:54:58PM -0400, Nicolas Pitre wrote:
> > > +config PTP_1588_CLOCK_DEFAULT
> > > + tristate
> >
> > I see what this option is doing, but I wonder about the name
> > "DEFAULT". In what sense is this a default?
>
> It provides the default answer for when the
On Sun, Sep 18, 2016 at 12:54:58PM -0400, Nicolas Pitre wrote:
> > > +config PTP_1588_CLOCK_DEFAULT
> > > + tristate
> >
> > I see what this option is doing, but I wonder about the name
> > "DEFAULT". In what sense is this a default?
>
> It provides the default answer for when the
On Sun, 18 Sep 2016, Richard Cochran wrote:
> On Fri, Sep 16, 2016 at 10:57:58PM -0400, Nicolas Pitre wrote:
> > Subject: [PATCH] ptp_clock: allow for it to be optional
> >
> > In order to break the hard dependency between the PTP clock subsystem and
> > ethernet drivers capable of being clock
On Sun, 18 Sep 2016, Richard Cochran wrote:
> On Fri, Sep 16, 2016 at 10:57:58PM -0400, Nicolas Pitre wrote:
> > Subject: [PATCH] ptp_clock: allow for it to be optional
> >
> > In order to break the hard dependency between the PTP clock subsystem and
> > ethernet drivers capable of being clock
On Fri, Sep 16, 2016 at 10:57:58PM -0400, Nicolas Pitre wrote:
> Subject: [PATCH] ptp_clock: allow for it to be optional
>
> In order to break the hard dependency between the PTP clock subsystem and
> ethernet drivers capable of being clock providers, this patch provides
> simple PTP stub
On Fri, Sep 16, 2016 at 10:57:58PM -0400, Nicolas Pitre wrote:
> Subject: [PATCH] ptp_clock: allow for it to be optional
>
> In order to break the hard dependency between the PTP clock subsystem and
> ethernet drivers capable of being clock providers, this patch provides
> simple PTP stub
On Fri, 16 Sep 2016, Richard Cochran wrote:
> On Thu, Sep 15, 2016 at 02:56:49PM -0700, Josh Triplett wrote:
> > > I suspect there is more of a case for having net drivers _without_ ptp
> > > support. This could be implemented with a ptp_clock_register() stub
> > > returning NULL when ptp is
On Fri, 16 Sep 2016, Richard Cochran wrote:
> On Thu, Sep 15, 2016 at 02:56:49PM -0700, Josh Triplett wrote:
> > > I suspect there is more of a case for having net drivers _without_ ptp
> > > support. This could be implemented with a ptp_clock_register() stub
> > > returning NULL when ptp is
Hi Nicolas,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.8-rc6 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to
Hi Nicolas,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.8-rc6 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to
On Thu, Sep 15, 2016 at 02:56:49PM -0700, Josh Triplett wrote:
> > I suspect there is more of a case for having net drivers _without_ ptp
> > support. This could be implemented with a ptp_clock_register() stub
> > returning NULL when ptp is not configured. I didn't look at most
> > drivers
On Thu, Sep 15, 2016 at 02:56:49PM -0700, Josh Triplett wrote:
> > I suspect there is more of a case for having net drivers _without_ ptp
> > support. This could be implemented with a ptp_clock_register() stub
> > returning NULL when ptp is not configured. I didn't look at most
> > drivers
On Thu, Sep 15, 2016 at 05:35:28PM -0400, Nicolas Pitre wrote:
> On Thu, 15 Sep 2016, Josh Triplett wrote:
>
> > On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote:
> > > On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> > > > This doesn't look too bad.
> > >
> > > I
On Thu, Sep 15, 2016 at 05:35:28PM -0400, Nicolas Pitre wrote:
> On Thu, 15 Sep 2016, Josh Triplett wrote:
>
> > On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote:
> > > On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> > > > This doesn't look too bad.
> > >
> > > I
On Thu, 15 Sep 2016, Josh Triplett wrote:
> On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote:
> > On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> > > This doesn't look too bad.
> >
> > I disagree. It looks ugly. If tinification means sprinkling more and
> > more
On Thu, 15 Sep 2016, Josh Triplett wrote:
> On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote:
> > On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> > > This doesn't look too bad.
> >
> > I disagree. It looks ugly. If tinification means sprinkling more and
> > more
On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> This doesn't look too bad.
Actually, it is worse than ugly. It is a disaster. With this change,
registration will succeed and MAC drivers will happily report the PTP
devices in 'ethtool -T', but there won't be anything behind them.
On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> This doesn't look too bad.
Actually, it is worse than ugly. It is a disaster. With this change,
registration will succeed and MAC drivers will happily report the PTP
devices in 'ethtool -T', but there won't be anything behind them.
On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote:
> On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> > This doesn't look too bad.
>
> I disagree. It looks ugly. If tinification means sprinkling more and
> more of these conditionals all over the place, then it is
On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote:
> On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> > This doesn't look too bad.
>
> I disagree. It looks ugly. If tinification means sprinkling more and
> more of these conditionals all over the place, then it is
On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> This doesn't look too bad.
I disagree. It looks ugly. If tinification means sprinkling more and
more of these conditionals all over the place, then it is going to be
a tough sell.
> Richard: Your thoughts?
We decided to have MAC
On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote:
> This doesn't look too bad.
I disagree. It looks ugly. If tinification means sprinkling more and
more of these conditionals all over the place, then it is going to be
a tough sell.
> Richard: Your thoughts?
We decided to have MAC
On Thu, Sep 15, 2016 at 12:31 PM, Nicolas Pitre
wrote:
> On Thu, 15 Sep 2016, John Stultz wrote:
>
>> On Thu, Sep 15, 2016 at 11:37 AM, Nicolas Pitre
>> wrote:
>> > On Thu, 15 Sep 2016, John Stultz wrote:
>> >
>> >> On Thu, Sep 15, 2016 at
On Thu, Sep 15, 2016 at 12:31 PM, Nicolas Pitre
wrote:
> On Thu, 15 Sep 2016, John Stultz wrote:
>
>> On Thu, Sep 15, 2016 at 11:37 AM, Nicolas Pitre
>> wrote:
>> > On Thu, 15 Sep 2016, John Stultz wrote:
>> >
>> >> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
>> >> wrote:
>> >> > On Thu, 15
On Thu, 15 Sep 2016, John Stultz wrote:
> On Thu, Sep 15, 2016 at 11:37 AM, Nicolas Pitre
> wrote:
> > On Thu, 15 Sep 2016, John Stultz wrote:
> >
> >> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
> >> wrote:
> >> > On Thu, 15 Sep 2016,
On Thu, 15 Sep 2016, John Stultz wrote:
> On Thu, Sep 15, 2016 at 11:37 AM, Nicolas Pitre
> wrote:
> > On Thu, 15 Sep 2016, John Stultz wrote:
> >
> >> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
> >> wrote:
> >> > On Thu, 15 Sep 2016, John Stultz wrote:
> >> >
> >> >> > diff --git
On Thu, Sep 15, 2016 at 11:37 AM, Nicolas Pitre
wrote:
> On Thu, 15 Sep 2016, John Stultz wrote:
>
>> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
>> wrote:
>> > On Thu, 15 Sep 2016, John Stultz wrote:
>> >
>> >> > diff --git
On Thu, Sep 15, 2016 at 11:37 AM, Nicolas Pitre
wrote:
> On Thu, 15 Sep 2016, John Stultz wrote:
>
>> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
>> wrote:
>> > On Thu, 15 Sep 2016, John Stultz wrote:
>> >
>> >> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
>> >> > index
On Thu, 15 Sep 2016, John Stultz wrote:
> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
> wrote:
> > On Thu, 15 Sep 2016, John Stultz wrote:
> >
> >> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> >> > index 62824f2fe4..62504a2c9f 100644
> >> > ---
On Thu, 15 Sep 2016, John Stultz wrote:
> On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
> wrote:
> > On Thu, 15 Sep 2016, John Stultz wrote:
> >
> >> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> >> > index 62824f2fe4..62504a2c9f 100644
> >> > --- a/kernel/time/Kconfig
> >> > +++
On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
wrote:
> On Thu, 15 Sep 2016, John Stultz wrote:
>
>> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
>> > index 62824f2fe4..62504a2c9f 100644
>> > --- a/kernel/time/Kconfig
>> > +++ b/kernel/time/Kconfig
>> > @@
On Thu, Sep 15, 2016 at 11:28 AM, Nicolas Pitre
wrote:
> On Thu, 15 Sep 2016, John Stultz wrote:
>
>> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
>> > index 62824f2fe4..62504a2c9f 100644
>> > --- a/kernel/time/Kconfig
>> > +++ b/kernel/time/Kconfig
>> > @@ -195,3 +195,21 @@ config
On Thu, 15 Sep 2016, John Stultz wrote:
> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> > index 62824f2fe4..62504a2c9f 100644
> > --- a/kernel/time/Kconfig
> > +++ b/kernel/time/Kconfig
> > @@ -195,3 +195,21 @@ config HIGH_RES_TIMERS
> >
> > endmenu
> > endif
> > +
> > +config
On Thu, 15 Sep 2016, John Stultz wrote:
> > diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> > index 62824f2fe4..62504a2c9f 100644
> > --- a/kernel/time/Kconfig
> > +++ b/kernel/time/Kconfig
> > @@ -195,3 +195,21 @@ config HIGH_RES_TIMERS
> >
> > endmenu
> > endif
> > +
> > +config
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 62824f2fe4..62504a2c9f 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -195,3 +195,21 @@ config HIGH_RES_TIMERS
>
> endmenu
> endif
> +
> +config POSIX_TIMERS
> + bool "Posix Clocks & timers" if EMBEDDED
>
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 62824f2fe4..62504a2c9f 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -195,3 +195,21 @@ config HIGH_RES_TIMERS
>
> endmenu
> endif
> +
> +config POSIX_TIMERS
> + bool "Posix Clocks & timers" if EMBEDDED
>
On Thu, 15 Sep 2016, John Stultz wrote:
> On Wed, Sep 14, 2016 at 8:47 PM, Nicolas Pitre
> wrote:
> > Many embedded systems typically don't need them. This removes about
> > 22KB from the kernel binary size on ARM when configured out.
> >
> > Corresponding syscalls
On Thu, 15 Sep 2016, John Stultz wrote:
> On Wed, Sep 14, 2016 at 8:47 PM, Nicolas Pitre
> wrote:
> > Many embedded systems typically don't need them. This removes about
> > 22KB from the kernel binary size on ARM when configured out.
> >
> > Corresponding syscalls are routed to a stub logging
On Wed, Sep 14, 2016 at 8:47 PM, Nicolas Pitre wrote:
> Many embedded systems typically don't need them. This removes about
> 22KB from the kernel binary size on ARM when configured out.
>
> Corresponding syscalls are routed to a stub logging the attempt to
> use those
On Wed, Sep 14, 2016 at 8:47 PM, Nicolas Pitre wrote:
> Many embedded systems typically don't need them. This removes about
> 22KB from the kernel binary size on ARM when configured out.
>
> Corresponding syscalls are routed to a stub logging the attempt to
> use those syscalls which should be
48 matches
Mail list logo