On Tue, Aug 31, 2010 at 10:48 AM, Julia Lawall wrote:
> Add a call to of_node_put in the error handling code following a call to
> of_find_compatible_node or of_find_node_by_type.
>
> This patch also substantially reorganizes the error handling code in the
> function, to that it is possible first
On Tue, Aug 31, 2010 at 10:48 AM, Julia Lawall wrote:
> Add a call to of_node_put in the error handling code following a call to
> of_parse_phandle.
>
> This patch also moves the existing call to of_node_put tothe end of the
> error handling code, to make it possible to jump to of_node_put without
From: Wolfgang Grandegger
Date: Tue, 31 Aug 2010 21:22:07 +0200
> On 08/31/2010 09:10 PM, Wolfram Sang wrote:
>> On Tue, Aug 31, 2010 at 07:44:00PM +0200, Julia Lawall wrote:
>>> Add a call to of_node_put in the error handling code following a call to
>>> of_find_matching_node.
>>>
>>> This patch
On Thu, Aug 05, 2010 at 02:43:25PM +1000, David Gibson wrote:
> On Fri, Jun 11, 2010 at 04:59:46PM -0600, Grant Likely wrote:
> > I've been doing a bit of work on some introductory level documentation
> > of the flattened device tree. I've got a rough copy up on the
> > devicetree.org wiki, and I
Grant Likely schrieb:
> On Tue, Aug 31, 2010 at 10:16 AM, Vasiliy Kulikov wrote:
>> On Tue, Aug 31, 2010 at 18:08 +0200, Julia Lawall wrote:
>>> On Tue, 31 Aug 2010, walter harms wrote:
> if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
> strncmp(model, "iBook", strle
Julia Lawall schrieb:
> Add a call to of_node_put in the error handling code following a call to
> of_find_node_by_path.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @r exists@
> local idexpression x;
> expression E,E1;
> statement S;
>
Hi Lorenzo,
> > - the SMSC911x host bus size can be retrieved from the chip idrev (for
> > chip idrev having just 16-bit bus IF) or for controllers like 9118
that
> > can have both (32/16), there is a D32/D16 HW strap readable from
HW_CFG.
> > The problem with these flags is that they define bus
Alan Cox wrote:
The master node in a PTP network probably takes its time from a
precise external time source, like GPS. The GPS provides a 1 PPS
directly to the PTP clock hardware, which latches the PTP hardware
clock time on the PPS edge. This provides one sample as input to a
clock servo (in th
On Fri, 2010-08-27 at 14:03 +0200, Arnd Bergmann wrote:
> On Friday 27 August 2010, Richard Cochran wrote:
> > On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote:
> > > On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> > > > On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann
On Fri, 2010-08-27 at 14:38 +0200, Richard Cochran wrote:
> On Mon, Aug 23, 2010 at 01:08:45PM -0700, john stultz wrote:
> > On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> > > The clockid_t CLOCK_PTP will be arch-neutral.
> >
> > Sure, but are they conceptually neutral? There are othe
On Wed, 2010-08-25 at 11:40 +0200, Christian Riesch wrote:
> What you describe here is only one of the use cases. If the hardware
> has a single network port and operates as a PTP slave, it timestamps
> the PTP packets that are sent and received and subsequently uses these
> timestamps and the info
On Fri, 2010-08-27 at 13:08 +0200, Richard Cochran wrote:
> On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote:
> > On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> > > On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > > > My point was that a syscall is better t
On Fri, Aug 27, 2010 at 8:06 AM, Alan Cox wrote
> > > system time bimble track a source makes sense just as with NTP but
> making
> > > it a new clock seems the wrong model extending a non-too-bright API
> when
> > > you can just put the time sources in a file tree.
> >
> > Don't get your meaning
Hi!
I'd like to add my two cents about the discussion. Just to shortly
introduce myself: I'm working with PTP since version 2002 (now 2008 or
PTPv2) and I'm developing matching network cards, drivers, and also
sometimes a bit of the stack.
I always had the problem of different HW implementations
This patch adds an interface to the ethtool subsystem and
implements read/write functionality for handling settings with the
ethtool_cmd structure. "Speed" is the only setting implemented so far.
Other settings (like reading the duplex value) can be easily implemented
later on.
One can read the sp
On Mon, Aug 23, 2010 at 10:08 PM, john stultz wrote:
> On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
>> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
>> > Again, my knowledge in the networking stack is pretty limited. But it
>> > would seem that having an interface that
On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > My point was that a syscall is better than an ioctl based interface here,
> > which I definitely still think. Given that John knows much more about
> > clocks than I do, we
Sorry for the slow response here, I got busy with other work at the end
of last week.
On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> > On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > > The timer/alarm stuff i
On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote:
>>
> > So while to me, it think it would be more ideal (or maybe just less
> > different) to have a read-only interface (like the RTC), leaving PTPd to
> > manage offset calculat
On Tue, 2010-08-17 at 13:36 +0200, Arnd Bergmann wrote:
> On Tuesday 17 August 2010, Richard Cochran wrote:
> > On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote:
> > > Another difference is that we generally use ioctl for devices that can
> > > be enumerated, while syscalls are for sys
On Tue, 2010-08-17 at 10:53 +0200, Richard Cochran wrote:
> On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote:
> > 3) I'm not sure I see the benefit of being able to have multiple
> > frequency corrected time domains. In other words, what benefit would
> > you get from adjusting a PTP cl
On Mon, Aug 16, 2010 at 12:24 PM, john stultz wrote:
> On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran
> A few comments below
>
>> +** PTP user space API
>> +
>> + The class driver creates a character device for each registered PTP
>> + clock. User space programs may control the clock usi
On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran
wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> exposed to user space a
This patch adds support for the PTP clock found on the DP83640.
The basic clock operations and one external time stamp have
been implemented.
Signed-off-by: Richard Cochran
---
drivers/net/phy/Kconfig | 29 ++
drivers/net/phy/Makefile |1 +
drivers/net/phy/dp83640.c | 904 +
24 matches
Mail list logo
