On Sat, Sep 22, 2012 at 06:16:49PM +0200, Christophe Leroy wrote:
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:
Revision A2 of LXT973 chip randomly returns the contents of the previous even
register when you read a odd
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
--- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
+++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
@@ -175,6 +292,16 @@
On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote:
A2 chip has phy_id 0x00137a10
A3 chip has phy_id 0x00137a11
Okay then, thanks.
Acked-by: Richard Cochran richardcoch...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
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
Cc: Richard Cochran richardcoch...@gmail.com
Cc: David S. Miller da...@davemloft.net
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
Acked-by: Richard Cochran richardcoch...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Sun, Oct 21, 2012 at 02:02:42PM +0800, caiyuqing wrote:
hi, all.
I have some questions about context switch on arm Linux (my target is
ARMv7-a).
1. Does arm linux support FCSE to handle the context switch?
No, mainline Linux does not support FCSE. However, you can use Gilles'
unoffical
On Sun, Oct 21, 2012 at 04:19:50PM +0800, caiyuqing wrote:
Richard, thanks for your reply.
mainline Linux doesn't support FCSE, if so, when kernel switch a
process to another(these two process share the same virtual memory
space), that means the vitrual-to-physical address should be
remaped,
On Tue, Oct 23, 2012 at 01:03:09PM -0700, Kees Cook wrote:
This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
CC: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Kees Cook keesc
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote:
Don't get me wrong. If I had time for this it could be different.
Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at
this point. Given the raised barriers to participate, probably aimed at
paid
On Wed, Apr 03, 2013 at 10:50:57AM -0700, John Stultz wrote:
I get the reasoning around reusing the fd we already have, but is
the possibility of a dynamic chardev pathname really a big concern?
I have been following this thread, and, not knowing very much about
perf, I would think that the
On Fri, Apr 05, 2013 at 07:16:53PM +0100, Pawel Moll wrote:
Ok, so how about the code below? Disclaimer: this is just a proposal.
I'm not sure how welcomed would be an extra field in struct file, but
this makes the clocks ultimately flexible - one can attach the clock
to any arbitrary struct
On Mon, Apr 08, 2013 at 12:05:52PM -0700, John Stultz wrote:
So thinking this through further, I'm worried we may _not_ be able
to eventually enable this to be a vdso as I had earlier hoped.
Mostly because I'm not sure how the fd - file - clock lookup could
be done in userland (any ideas?).
On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
This should be fixed with the above mentioned patch. The issue is that the
bios fumbles around with the output configuration behind our backs, so the
new paranoid modeset code in 3.7+ freaks out about the state mismatch
between
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
It's written against drm-intel-next-queued at
http://cgit.freedesktop.org/~danvet/drm-intel
I've thought that it should apply pretty cleanly against older kernels,
too. Apparently it conflicts a bit in
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
That patch should crash at all, so this is not expected. Can you pls
check whether plain drm-intel-nightly is broken, too?
I did try drm-intel-nightly just now (1dd83e3), and it also freezes
the machine. I first verified that the
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
I've just tracked down and fixed an bug which can lead to a hard-hang
in the crtc restore code (which is used both in the lid handler when
opening and on resume). If you could please test this patch (on top of
drm-intel-nightly):
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
I've just tracked down and fixed an bug which can lead to a hard-hang
in the crtc restore code (which is used both in the lid handler when
opening and on resume). If you could please test this patch (on top of
drm-intel-nightly):
I have an Acer Aspire One netbook, and on it I get the following
warning when closing and opening the lid. I think this warning first
appeared in 3.7.
Does this need fixing? If so, who can do it?
Thanks,
Richard
** close lid
Mar 16 11:32:03 netboy kernel: [ 287.429404]
I have an Acer Aspire One netbook with a built in card reader, and I
have two cards, one with 32 MB and one with 4 GB. The card reader used
to work with the staging driver in 3.7.10, but the new 3.8.3 driver
does not work with the larger card. The old driver was removed in
commit cd211222.
Now,
On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote:
Another pesky BIOS which changes the display state behind our back on lid
closing! Should be duct-tapped over with
commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Nov 23
On Mon, Mar 18, 2013 at 09:58:46AM +0800, wwang wrote:
Hi Richard:
Could you please describe the detailed model of your 4G card? It
would be better if you can take a picture of that card or give me
the Amazon link of it. It looks like a compatibility issue.
The lettering on the card is:
On Thu, Mar 21, 2013 at 12:22:57PM +0400, Konstantin Khlebnikov wrote:
This patch adds new kind of dependencies between kconfig symbols,
and new kconfig keyword 'apply' for them.
'apply' works mostly like 'select', but it allows to disable target symbol.
Thus target symbol will be either
On Thu, Mar 21, 2013 at 03:06:11PM +0400, Konstantin Khlebnikov wrote:
As I see this technology requires special dedicated server in the local
network, thus it's unusable in most situations. But it starts working
without any actions from the user (please fix me if I'm wrong).
Perhaps you
On Tue, Mar 26, 2013 at 12:18:04PM +0900, kpark3...@gmail.com wrote:
From: Sahara keun-o.p...@windriver.com
This fixes a number of sparse warnings like:
warning: incorrect type in argument 2 (different address spaces)
expected void volatile [noderef] asn:2*addr
got unsigned int
On Mon, Mar 25, 2013 at 01:08:10PM -0700, John Stultz wrote:
This patchset makes the lock ownership lines less obvious, but I've
been sure to keep the ntp state static to ntp.c and instead provided
some accessors via ntp-internal.h that timekeping code can use to
make changes. The only
to enable this 'new' option. That is really annoying,
especially with non-atom and non-x86 builds.
Ben, you removed the PCH_GBE dependency in 18d359ce. Are you sure that
was the right thing to do?
Thanks,
Richard
Cc: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Jeff Mahoney je
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote:
Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
While at it, added a non-NAPI mode (which is easier to debug), plus
some general fixes.
I have a few issues with this patch:
1. This is a networking
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote:
Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
While at it, added a non-NAPI mode (which is easier to debug), plus
some general fixes.
This patch does not apply to net-next.
When you do post to
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote:
Hi Richard,
Yes, I guess this was more of a drive-by patch dump - but people need this
to get PG2.0 silicon to work on am33xx.
And what is PG2.0?
And no, I don't think having a non-NAPI code path is backwards, especially
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote:
Speaking of which, I'm probably the original developer of the fec driver.
BTW, as I mentioned, someone is converting fec to napi. Care to take a
look to make sure it is done right?
Thanks,
Richard
--
To unsubscribe from this
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
It's a lot of code for a 50ms boot-time improvement. Does anyone have
any opinions on whether or not the benefits are worth the cost?
In the embedded space, quick boot is a really important feature to
have. Many people resort to
On Mon, Sep 10, 2012 at 05:45:49PM +0200, Christophe Leroy wrote:
This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
precautions linked to ERRATA Item 4:
I have a few nit picking remarks, below...
Item 4: MDIO Interface and Repeated Polling
Problem: Repeated
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
2. There's nothing vsyscall-specific about the code in
vclock_gettime.c. In fact, the VVAR macro should work just fine in
kernel code. If you moved all this code into a header, then
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
I believe its mostly historical, but on some architectures that
history has become an established ABI, making it technical.
Fine, but what do you mean by ABI? Are you talking about magic
addresses for functions?
Without knowing the
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
On powerpc, I mean magic addresses where userland can find
structures that it can use to calculate time.
...
With powerpc, there is no arch specific kernel code involved, its
just a data structure the kernel exports that is
On Wed, Sep 19, 2012 at 02:11:02PM -0700, John Stultz wrote:
Now, I suspect the difficult part will be finding someone with the
time and interest to try get the vdso gettime working on ia64 (or
s390 or powerpc), and then try to unify the kernel side
implementation. Reducing the maintenance
On Mon, Aug 27, 2012 at 10:38:33AM -0700, Joe Perches wrote:
commit ec21e2ec36769 (freescale: Move the Freescale drivers)
moved the files, update the pattern.
Thanks for spotting this, Joe.
Acked-by: Richard Cochran richardcoch...@gmail.com
--
To unsubscribe from this list: send the line
On Tue, Nov 27, 2012 at 09:41:51AM +0100, Tim Sander wrote:
Hi
I have been trying to get the 3.7-rc6 kernel to compile for a beaglebone
board
with device tree but it seems there are still bits missing. Especially it
seems as if the sd card reader and network is not working properly?
The
On Tue, Nov 27, 2012 at 03:23:51PM +0100, Yegor Yefremov wrote:
How do you load your rootfs: embedded into kernel or separately?
Separately. I gave up on the embedded option on ARM (IXP) long ago,
since I never could getaw it to work.
Do you know if frame buffer is functioning in main line?
On Thu, Jan 03, 2013 at 11:20:52AM +0100, Julia Lawall wrote:
There has been a discussion recently about how the result of get_clk
should be an opaque handle, not a value that can be dereferenced:
https://lkml.org/lkml/2012/12/20/105
There is such a dereference in
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote:
The following patchset introduces Device Tree overlays, a method
of dynamically altering the kernel's live Device Tree.
It would be nice to know the motivation for this code.
What is the use case? What problem or issue is being
On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote:
The problem being addressed is discussed in this thread:
http://permalink.gmane.org/gmane.linux.kernel/1389017
Thanks for the link.
Since the motivation is already documented in that post, why not add
it into
Acked-by: Richard Cochran richardcoch...@gmail.com
(Adding John Stultz on CC)
---
kernel/posix-timers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
index 69185ae..10349d5 100644
--- a/kernel/posix-timers.c
+++ b/kernel
I see the following error, using the .config inline, below.
arch/m68k/mm/init.c: In function 'print_memmap':
arch/m68k/mm/init.c:139:2: error: 'KMAP_START' undeclared (first use in this
function)
arch/m68k/mm/init.c:139:2: note: each undeclared identifier is reported only
once for each function
On Tue, Jan 08, 2013 at 01:59:22PM +0100, Florian Fainelli wrote:
This patch makes CONFIG_PPS_DEBUG and CONFIG_NTP_PPS be hidden if
CONFIG_PPS is not selected, such that we are not prompted for these
configuration options if CONFIG_PPS is not set.
Signed-off-by: Florian Fainelli
- Support SIOCSHWTSTAMP ioctl appopriately
- Rebased to be the last patch in the series to simplify development
Anyhow, this looks much better to me now.
Acked-by: Richard Cochran richardcoch...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote:
I don't think having people rely on the bindings is the issue so much
as the awareness that if they do, there will be compatibility issues for
unstable bindings.
On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote:
On 07/25/2013 11:48 AM, Richard Cochran wrote:
On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote:
As long as we can make sufficiently clear that trying to use an unstable
binding is going to be *very* painful
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
We use DT has a kernel configuration input. Our environment is
designed to guarantee 100% that the kernel and DT match exactly. DT
very deliberately isn't an ABI boundary in our systems.
It is nice that you use DT in that way,
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
We use DT has a kernel configuration input. Our environment is
designed to guarantee 100% that the kernel and DT match exactly. DT
very deliberately isn't an ABI boundary in our systems.
Think about what you just said.
The DT
On Wed, Jul 24, 2013 at 03:05:20PM -0700, Greg Kroah-Hartman wrote:
The dev_attrs field of struct class is going away soon, dev_groups
should be used instead. This converts the ptp class code to use the
correct field.
Cc: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Greg Kroah
On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote:
On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote:
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote:
We use DT has a kernel configuration input. Our environment is
designed to guarantee 100
On Fri, Jul 26, 2013 at 11:36:13AM -0500, Rob Herring wrote:
On 07/26/2013 10:49 AM, Olof Johansson wrote:
On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown broo...@kernel.org wrote:
On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote:
Unless I totally misunderstood, the thread
On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:
Long term, final goal is likely to be close to what Russell is saying
Why is this a long term goal? Start today.
-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
Further, every other kernel release tended to break the board.c files,
just due to the usual kernel churn.
Yes...
DT is much better, the stuff that can be described in DT is broader
and more thought tends to have been put
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
On Fri, Jul 26, 2013 at 06:54:33AM +0200, Richard Cochran wrote:
I too work on commercial embedded systems, and DT has proven to be
one gigantic *PITA*.
Why do you think our experiences are so different?
Here are a few
On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
[ I disagree about the more thought part. The current discussion,
coming years too late after the introduction of DT to ARM Linux, is
contrary evidence enough
On Sat, Jul 27, 2013 at 12:36:02PM +0100, Mark Brown wrote:
On Sat, Jul 27, 2013 at 10:53:01AM +0200, Richard Cochran wrote:
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote:
Why do you think our experiences are so different?
Here are a few recent examples:
OK, let's
On Sat, Jul 27, 2013 at 10:57:09AM -0700, David Lang wrote:
On Sat, 27 Jul 2013, Richard Cochran wrote:
On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote:
On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote:
[ I disagree about the more thought part. The current
On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote:
That is a nice summary of how we got from null to now and Richard
seems to be simply saying: let's stop mucking about and make this a
project with a well-defined process of dealing with staging and
stable bindings and keep
On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote:
On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote:
Frankly, I am really surprised and shocked at the cavalier attitude
expressed here WRT DT bindings in released kernels. Think about the
*users* of this code
On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote:
I'm not really sure what effect on users this has. Maybe you should define
users.
...
Care to explain this reasoning?
Use Case
User acquires a machine running ARM Linux version 3.x, with u-boot
and dtb in a read only
On Sun, Jul 28, 2013 at 03:39:56PM +0200, Tomasz Figa wrote:
There are many possible options:
...
Wow, you totally ignored the use case.
Please note, though, I'm _not_ trying to convince you that this kind of
solutions is good, as I'm not convinced either. That's why we are
discussing
On Sun, Jul 28, 2013 at 10:09:57AM -0400, jonsm...@gmail.com wrote:
3.z kernel is free to alter the schema. But it will have to supply the
necessary quirks needed to keep those old dtb's functioning.
The quirks idea sounds okay to me, if it can really provide forward
compatibility. In
On Mon, Jul 29, 2013 at 09:31:23AM +0200, Maxime Ripard wrote:
I'm afraid this kind of use case will never be properly supported, DT
stable ABI or not.
Think about this: what kernel will actually be shipped in that board?
Most likely, it will be a BSP kernel from the vendor. Does the
On Mon, Jul 29, 2013 at 08:38:52PM +0200, Richard Cochran wrote:
Right, we can and should do better. I got the beaglebone Ethernet
working in mainline (not by writing the driver, but by complaining
over and over again). I except that it will continue to work
On Thu, Jul 11, 2013 at 02:22:14PM -0700, Mark Galeck wrote:
The answer to is it desirable to improve X? is always yes. But
the only way to make progress in Linux is to actually post patches
that improve X. This is unlike many corporate environments, where
you might need to get somebody's
On Mon, Sep 09, 2013 at 10:47:01AM -0700, Andy Lutomirski wrote:
I think that coming up with something that's both non-POSIX and
half-arsed is a bad idea, but doing something that's non-POSIX and
well thought-through could be valuable.
I know Harlan Stenn of the Network Time Foundation is
On Wed, Jul 31, 2013 at 12:59:59PM +0200, Tomasz Figa wrote:
On Wednesday 31 of July 2013 12:37:37 Maxime Bizon wrote:
Board files are C code anyone has the skill to edit/understand/refactor.
Moving to DT and keep them in tree tightly coupled with the kernel
version just adds another
On Wed, Jul 31, 2013 at 05:23:35PM +0200, Tomasz Figa wrote:
I said it many, many times, that a) and b) I proposed are just two extremes.
It is unlikely that an extreme solution will be the best option to choose. I
am strongly for something in the middle, just like I wrote in several of my
On Wed, Jul 31, 2013 at 09:29:35PM +0200, Tomasz Figa wrote:
I showed you two example solutions that could handle this use case without
stable binding ABI, just to prove that b) is not the only option (even if
it's the best one, which I continue to agree on, don't get me wrong).
You only
On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
This patch add a method into testptp.c to measure the time offset
between phc and system clock through the ioctl PTP_SYS_OFFSET.
This is a nice addition to the testptp program. I do have a few
comments, below.
First off, the subject
On Sat, Sep 14, 2013 at 11:39:52PM +0800, Dong Zhu wrote:
On Sat, Sep 14, 2013 at 04:31:46PM +0200, Richard Cochran wrote:
On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
This patch add a method into testptp.c to measure the time offset
between phc and system clock through
On Wed, Nov 27, 2013 at 10:35:25AM +0100, Geert Uytterhoeven wrote:
For v3.13-rc1, the top 10 is:
Disabling CONFIG_NET saves 1038404 bytes
Disabling CONFIG_INET saves 572034 bytes
...
I hope you find this useful!
As another poor soul stuck with tiny resources, thank you for this
work!
On Tue, Nov 19, 2013 at 03:13:19PM +0100, Richard Cochran wrote:
In this test, the update rate is once per second. When using longer
intervals, the problem becomes worse.
Here is another pair of example runs on an idle system, this time with
a 32 second update interval.
* Periodic Case
On Thu, Nov 14, 2013 at 03:50:40PM +0100, Miroslav Lichvar wrote:
include/linux/timekeeper_internal.h | 4 +
kernel/time/timekeeping.c | 209
+---
2 files changed, 31 insertions(+), 182 deletions(-)
This looks like an impressive simplification...
On Mon, Nov 18, 2013 at 01:28:07PM -0800, John Stultz wrote:
Also, just for clarity's sake, when you're seeing things broken,
curious how/what you are measuring?
Here is the background for this issue. The linuxptp stack has a
program called phc2sys whose purpose is to synchronize the Linux
ptp_find_pin() logic
- use correct test when checking whether the pin with the
calibration function is being reprogrammed
Richard Cochran (9):
ptp: introduce programmable pins.
ptp: add the pin GET/SETFUNC ioctls to the testptp program.
ptp: expose the programmable pins via sysfs
ptp
This patch changes the driver to use the new pin configuration method when
programming the external time stamp input signals.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers
This patch changes the driver use the new pin configuration method when
programming the periodic output signal.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers
This patch adds a pair of new ioctls to the PTP Hardware Clock device
interface. Using the ioctls, user space programs can query each pin to
find out its current function and also reprogram a different function
if desired.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp
This patch adapts the dp83640 driver to allow reconfiguration of which
auxiliary function goes on which pin. The functions may be reassigned
freely with the one exception of the calibration function.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 52
This patch updates the many PTP Hardware Clock drivers with the
newly introduced field that advertises the number of programmable
pins. Some of these devices do have programmable pins, but the
implementation will have to wait for follow on patches.
Signed-off-by: Richard Cochran richardcoch
The phyter driver incorrectly feeds the value of the period into what
is in fact a pulse width register, resulting in the actual period
being twice the dialed value. This patch fixes the issue and renames a
variable to make the code at bit more clear.
Signed-off-by: Richard Cochran richardcoch
This patch adds the sysfs hooks needed in order to get and set the
programmable pin settings.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
Documentation/ABI/testing/sysfs-ptp | 20 +++
drivers/ptp/ptp_private.h |3 +
drivers/ptp/ptp_sysfs.c | 112
This patch adds a option to the test program that lists the
programmable pins on a PTP Hardware Clock device, assuming there
are any such pins. A second option lets the user reprogram the
auxiliary function of a single pin.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 98e7cbf..d6c1061 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy
On Fri, Feb 21, 2014 at 05:56:18PM -, Thomas Gleixner wrote:
Expose the deferrable timer mode to user space by adding a new
TDF_TIMER_DEFERRABLE flag.
The deferrable mode is available through the syscall timerfd_settime()
by handing in TDF_TIMER_IS_DEFERRABLE via the 'flags' argument.
On Fri, Feb 21, 2014 at 11:54:35PM +0100, Thomas Gleixner wrote:
To be honest, it's not the prettiest thing, but timespec is not pretty
to begin with.
yes...
Sure our normalize function can cope with that, but where is the
point?
and yes...
Now if we allow that we also need to allow
I stumbled across this in fs/kernfs/dir.c:39.
/* Reserve hash numbers 0, 1 and INT_MAX for magic directory entries */
if (hash 1)
hash += 2;
if (hash = INT_MAX)
hash = INT_MAX - 1;
Shouldn't that be (hash 2), or is 1 not reserved?
On Tue, Mar 04, 2014 at 11:11:21PM +0100, Thomas Gleixner wrote:
Once we agree on a solution to the Y2038 issue on 32bit with a unified
32/64 bit syscall interface which simply gets rid of the timespec/val
nonsense and takes a simple u64 nsec value we can add the slack
property to that
The hash values 0 and 1 are reserved for magic directory entries, but
the code only prevents names hashing to 0. This patch fixes the test
to also prevent hash value 1.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
Cc: sta...@vger.kernel.org
---
fs/kernfs/dir.c |2 +-
1 file
This patch adds the sysfs hooks needed in order to get and set the
programmable pin settings.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
Documentation/ABI/testing/sysfs-ptp | 20 +++
drivers/ptp/ptp_private.h |3 +
drivers/ptp/ptp_sysfs.c | 109
actually hook the phyter's pins into the new
system.
Comments and questions are most welcome.
Thanks,
Richard
Richard Cochran (9):
ptp: introduce programmable pins.
ptp: add the pin GET/SETFUNC ioctls to the testptp program.
ptp: expose the programmable pins via sysfs
ptp: drivers: set
This patch adapts the dp83640 driver to allow reconfiguration of which
auxiliary function goes on which pin. The functions may be reassigned
freely with the one exception of the calibration function.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 52
-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 98e7cbf..d6c1061 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy
This patch changes the driver use the new pin configuration method when
programming the periodic output signal.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers
The phyter driver incorrectly feeds the value of the period into what
is in fact a pulse width register, resulting in the actual period
being twice the dialed value. This patch fixes the issue and renames a
variable to make the code at bit more clear.
Signed-off-by: Richard Cochran richardcoch
This patch changes the driver to use the new pin configuration method when
programming the external time stamp input signals.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers
1 - 100 of 1646 matches
Mail list logo
