[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130308.112219.1999774630969953487.davem@davemloft.net>
Date: Fri, 08 Mar 2013 11:22:19 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: peppe.cavallaro@...com
Cc: netdev@...r.kernel.org, bh74.an@...sung.com,
rayagond@...avyalabs.com
Subject: Re: [net-next.git 0/9] stmmac: update to March_2013 (adding PTP &
RGMII/SGMII)
From: Giuseppe CAVALLARO <peppe.cavallaro@...com>
Date: Fri, 08 Mar 2013 08:16:24 +0100
> Hello David
>
> On 3/7/2013 9:34 PM, David Miller wrote:
>> From: Giuseppe CAVALLARO <peppe.cavallaro@...com>
>> Date: Thu, 7 Mar 2013 11:50:10 +0100
>>
>>> The PTP support is quite intrusive because it needs to support the
>>> extended
>>> descriptors used for saving the HW timestamps.
>>> These are available in new chip generations, only.
>>> So we have actually found useful to use some Kconfig options to
>>> surround PTP and extended descriptor support. This approach helped on
>>> old platform (embeeded system) where PTP is not supported and where we
>>> do not want to pay extra code and check in critical rx/tx paths.
>>
>> I would prefer run time handling of all of this.
>>
>> You do not need to put extra checks in the fast paths, instead you
>> have different methods that get hooked up into the netdev_ops
>> based upon chip capabilities/features/mode.
...
> Welcome advice.
Exactly what I told you above. You have two sets of routines,
one that deal with the older descriptors and one set that deals
with the new descriptors that can do PTP.
And you hook up different interrupt handler, NAPI poll, and
netdev_ops based upon the chip's capabilities.
You need no runtime testing, only a test a probe time to setup
things up properly.
What is so hard about this to understand?
--
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