From: Haicheng Li
Date: Sun, 07 Oct 2012 01:21:09 +0800
> Take IXGBE_PTP as example, it explicitly selects PPS, and also depends
> on EXPERIMENTAL:
> config IXGBE_PTP
> bool "PTP Clock Support"
> default n
> depends on IXGBE && EXPERIMENTAL
> select PPS
>
On 10/06/2012 10:21 PM, David Miller wrote:
From: Haicheng Li
Date: Sat, 06 Oct 2012 22:07:23 +0800
On 10/06/2012 09:22 PM, David Miller wrote:
From: Haicheng Li
Date: Sat, 06 Oct 2012 20:07:08 +0800
The failure is due to the CONFIG_PPS is not set there, consequently
CONFIG_PTP_1588_CLOCK
On Sat, Oct 06, 2012 at 10:07:23PM +0800, Haicheng Li wrote:
>
> IMHO, the reason why the dependency of PCH_PTP becomes so tricky is
> that the code of these two modules call the functions of each other
> (bad code structure?).
Yes, that is the source of the problem. I don't recall how this
From: Haicheng Li
Date: Sat, 06 Oct 2012 22:07:23 +0800
> On 10/06/2012 09:22 PM, David Miller wrote:
>> From: Haicheng Li
>> Date: Sat, 06 Oct 2012 20:07:08 +0800
>>
>>> The failure is due to the CONFIG_PPS is not set there, consequently
>>> CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
On 10/06/2012 09:22 PM, David Miller wrote:
From: Haicheng Li
Date: Sat, 06 Oct 2012 20:07:08 +0800
The failure is due to the CONFIG_PPS is not set there, consequently
CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
So David's patch of "da1586461e53a4dd045738cce309ab488970f0ef [1/9]
From: Haicheng Li
Date: Sat, 06 Oct 2012 20:07:08 +0800
> The failure is due to the CONFIG_PPS is not set there, consequently
> CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
>
> So David's patch of "da1586461e53a4dd045738cce309ab488970f0ef [1/9]
> pch_gbe: Fix PTP dependencies" is buggy.
The failure is due to the CONFIG_PPS is not set there, consequently
CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
So David's patch of "da1586461e53a4dd045738cce309ab488970f0ef [1/9] pch_gbe:
Fix PTP dependencies" is buggy. Furthermore, I think using "selects" to
resolve such dependency
The failure is due to the CONFIG_PPS is not set there, consequently
CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
So David's patch of da1586461e53a4dd045738cce309ab488970f0ef [1/9] pch_gbe:
Fix PTP dependencies is buggy. Furthermore, I think using selects to
resolve such dependency issue
From: Haicheng Li haicheng...@linux.intel.com
Date: Sat, 06 Oct 2012 20:07:08 +0800
The failure is due to the CONFIG_PPS is not set there, consequently
CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
So David's patch of da1586461e53a4dd045738cce309ab488970f0ef [1/9]
pch_gbe: Fix PTP
On 10/06/2012 09:22 PM, David Miller wrote:
From: Haicheng Lihaicheng...@linux.intel.com
Date: Sat, 06 Oct 2012 20:07:08 +0800
The failure is due to the CONFIG_PPS is not set there, consequently
CONFIG_PTP_1588_CLOCK can not be set as =y anyway.
So David's patch of
From: Haicheng Li haicheng...@linux.intel.com
Date: Sat, 06 Oct 2012 22:07:23 +0800
On 10/06/2012 09:22 PM, David Miller wrote:
From: Haicheng Lihaicheng...@linux.intel.com
Date: Sat, 06 Oct 2012 20:07:08 +0800
The failure is due to the CONFIG_PPS is not set there, consequently
On Sat, Oct 06, 2012 at 10:07:23PM +0800, Haicheng Li wrote:
IMHO, the reason why the dependency of PCH_PTP becomes so tricky is
that the code of these two modules call the functions of each other
(bad code structure?).
Yes, that is the source of the problem. I don't recall how this habit
of
On 10/06/2012 10:21 PM, David Miller wrote:
From: Haicheng Lihaicheng...@linux.intel.com
Date: Sat, 06 Oct 2012 22:07:23 +0800
On 10/06/2012 09:22 PM, David Miller wrote:
From: Haicheng Lihaicheng...@linux.intel.com
Date: Sat, 06 Oct 2012 20:07:08 +0800
The failure is due to the
From: Haicheng Li haicheng...@linux.intel.com
Date: Sun, 07 Oct 2012 01:21:09 +0800
Take IXGBE_PTP as example, it explicitly selects PPS, and also depends
on EXPERIMENTAL:
config IXGBE_PTP
bool PTP Clock Support
default n
depends on IXGBE EXPERIMENTAL
14 matches
Mail list logo