On Fri, Jun 29, 2007 at 04:55:47PM +0100, David Woodhouse wrote:
You missed one. This should be -EFAULT too. And there's not a huge
amount of point in keeping the access_ok() checks elsewhere, since
copy_to_user() does that for itself.
Ok, fixed.
Oh, and I think you do need compat magic for
On Fri, Jun 29, 2007 at 05:23:28PM +0100, David Woodhouse wrote:
You'll need to put it in an #else case, not in #ifndef __KERNEL__.
Sorry. :)
diff --git a/include/linux/pps.h b/include/linux/pps.h
index 6b53864..9e3af51 100644
--- a/include/linux/pps.h
+++ b/include/linux/pps.h
@@ -34,6 +34,8
On Thu, Jun 28, 2007 at 12:44:20PM +0100, David Woodhouse wrote:
>
> It's nice if you can do so, but I wouldn't suggest that you _have_ to.
> I have to admit that I rarely bother actually wiring new system calls up
> on anything but PowerPC to start with.
>
> The important thing is that you've
On Thu, Jun 28, 2007 at 09:31:14AM +0100, David Woodhouse wrote:
> On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> > Do you think I should add these functions into my patch, even if I
> > cannot test it, or it's enought providing just the
> > compat_sys_time
On Thu, Jun 28, 2007 at 09:08:53AM +0100, David Woodhouse wrote:
> On Thu, 2007-06-28 at 00:46 +0200, Rodolfo Giometti wrote:
> > Just last question: I still don't well understand where I should
> > declare the new compat_sys_time_pps_fetch() syscall... it's
> > automagically
On Thu, Jun 28, 2007 at 09:08:53AM +0100, David Woodhouse wrote:
On Thu, 2007-06-28 at 00:46 +0200, Rodolfo Giometti wrote:
Just last question: I still don't well understand where I should
declare the new compat_sys_time_pps_fetch() syscall... it's
automagically defined by the system when
On Thu, Jun 28, 2007 at 09:31:14AM +0100, David Woodhouse wrote:
On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
Do you think I should add these functions into my patch, even if I
cannot test it, or it's enought providing just the
compat_sys_time_pps_fetch() function
On Thu, Jun 28, 2007 at 12:44:20PM +0100, David Woodhouse wrote:
It's nice if you can do so, but I wouldn't suggest that you _have_ to.
I have to admit that I rarely bother actually wiring new system calls up
on anything but PowerPC to start with.
The important thing is that you've
On Wed, Jun 27, 2007 at 06:49:48PM +0100, David Woodhouse wrote:
>
> Looks better. All I can find to complain about is the fact that you
> return whatever copy_from_user() returns. Don't -- that's the number of
> bytes left to copy. It should be if (copy_from_user(..)) return -EFAULT;
Ok, I'll
On Wed, Jun 27, 2007 at 05:11:00PM +0100, David Woodhouse wrote:
> No, because you're passing a _kernel_ pointer to sys_time_pps_fetch()
> where it expects a userspace pointer. Use compat_alloc_user_space() to
> find somewhere to put it in user space, instead. Or change your internal
>
On Wed, Jun 27, 2007 at 11:18:30AM +0100, David Woodhouse wrote:
> On Wed, 2007-06-27 at 12:14 +0200, Rodolfo Giometti wrote:
> > On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
> > >
> > > 64-bit kernels can run 32-bit userspace programs. But som
On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
>
> 64-bit kernels can run 32-bit userspace programs. But some structures
> come out _differently_ between 32-bit and 64-bit compilation, so the
> system call needs a special 'compat' handler instead of just running the
> normal
On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
64-bit kernels can run 32-bit userspace programs. But some structures
come out _differently_ between 32-bit and 64-bit compilation, so the
system call needs a special 'compat' handler instead of just running the
normal 64-bit
On Wed, Jun 27, 2007 at 11:18:30AM +0100, David Woodhouse wrote:
On Wed, 2007-06-27 at 12:14 +0200, Rodolfo Giometti wrote:
On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
64-bit kernels can run 32-bit userspace programs. But some structures
come out _differently_
On Wed, Jun 27, 2007 at 05:11:00PM +0100, David Woodhouse wrote:
No, because you're passing a _kernel_ pointer to sys_time_pps_fetch()
where it expects a userspace pointer. Use compat_alloc_user_space() to
find somewhere to put it in user space, instead. Or change your internal
On Wed, Jun 27, 2007 at 06:49:48PM +0100, David Woodhouse wrote:
Looks better. All I can find to complain about is the fact that you
return whatever copy_from_user() returns. Don't -- that's the number of
bytes left to copy. It should be if (copy_from_user(..)) return -EFAULT;
Ok, I'll fix
On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
> That sounds like you're scared of using goto. Don't be :)
But it's not wrong... should I change it or not?
> I don't see this timepps.h of which you speak. If it's a _userspace_
> file, it cannot include unless you actually add
On Tue, Jun 26, 2007 at 11:57:07AM +0100, David Woodhouse wrote:
>
> Your syscalls blindly dereference userspace pointers instead of using
> copy_{to,from} user.
I use access_ok() to test userspace addresses. It should be ok,
shouldn't it?
> Why did you split all your syscalls into two
--- /dev/null
+++ b/Documentation/pps.txt
@@ -0,0 +1,183 @@
+
+ PPS - Pulse Per Second
+ --
+
+(C) Copyright 2007 Rodolfo Giometti <[EMAIL PROTECTED]>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public L
--- /dev/null
+++ b/Documentation/pps.txt
@@ -0,0 +1,183 @@
+
+ PPS - Pulse Per Second
+ --
+
+(C) Copyright 2007 Rodolfo Giometti [EMAIL PROTECTED]
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License
On Tue, Jun 26, 2007 at 11:57:07AM +0100, David Woodhouse wrote:
Your syscalls blindly dereference userspace pointers instead of using
copy_{to,from} user.
I use access_ok() to test userspace addresses. It should be ok,
shouldn't it?
Why did you split all your syscalls into two functions?
On Tue, Jun 26, 2007 at 06:38:40PM +0100, David Woodhouse wrote:
That sounds like you're scared of using goto. Don't be :)
But it's not wrong... should I change it or not?
I don't see this timepps.h of which you speak. If it's a _userspace_
file, it cannot include linux/pps.h unless you
CKEN_CAMERA (1 << 24)
to:
#define CKEN_CAMERA (24)
so direct access to the CKEN register should be now in the form:
CKEN |= (1 << CKEN_CAMERA)
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
arch/arm/mach-pxa/pxa27x.c |5 +++--
sound/arm/pxa2xx-ac97.c
CKEN_CAMERA (1 24)
to:
#define CKEN_CAMERA (24)
so direct access to the CKEN register should be now in the form:
CKEN |= (1 CKEN_CAMERA)
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
arch/arm/mach-pxa/pxa27x.c |5 +++--
sound/arm/pxa2xx-ac97.c |2 +-
sound/soc
On Fri, Jun 22, 2007 at 10:55:49AM +0100, Ben Dooks wrote:
>
> This is already on linux-arm-kernel, the best place to find people
> who do Linux on ARM.
I see... but after looking at ARM changes I find nothing useful to
resolve the problem, that's why I decided to write here also.
Ciao,
I just updated my linux tree from 2.6.20-rc6 to 2.6.22-rc3 for my
custom PXA270 based board and I discovered that now sleep/wakeup
functionality doesn't work anymore! :'(
After several merges, compiling stages and tests I discovered that the
problem arises from 2.6.21 to 2.6.22-rc1 and that the
I just updated my linux tree from 2.6.20-rc6 to 2.6.22-rc3 for my
custom PXA270 based board and I discovered that now sleep/wakeup
functionality doesn't work anymore! :'(
After several merges, compiling stages and tests I discovered that the
problem arises from 2.6.21 to 2.6.22-rc1 and that the
On Fri, Jun 22, 2007 at 10:55:49AM +0100, Ben Dooks wrote:
This is already on linux-arm-kernel, the best place to find people
who do Linux on ARM.
I see... but after looking at ARM changes I find nothing useful to
resolve the problem, that's why I decided to write here also.
Ciao,
Rodolfo
On Tue, Jun 19, 2007 at 03:39:40PM +0200, Jean Delvare wrote:
> Hi Rodolfo,
>
> On Tue, 19 Jun 2007 14:10:20 +0200, Rodolfo Giometti wrote:
> > Add support for Taos TSL2550 ambient light sensors.
> > (http://www.taosinc.com/product_detail.asp?cateid=4=18).
> >
> >
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4=18).
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/tsl2550.c
On Tue, Jun 19, 2007 at 03:39:40PM +0200, Jean Delvare wrote:
> Hi Rodolfo,
>
> On Tue, 19 Jun 2007 14:10:20 +0200, Rodolfo Giometti wrote:
> > Add support for Taos TSL2550 ambient light sensors.
> > (http://www.taosinc.com/product_detail.asp?cateid=4=18).
> >
> >
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4=18).
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/tsl2550.c
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4=18).
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/tsl2550.c
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4proid=18).
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/tsl2550.c | 427
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4proid=18).
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/tsl2550.c | 449
On Tue, Jun 19, 2007 at 03:39:40PM +0200, Jean Delvare wrote:
Hi Rodolfo,
On Tue, 19 Jun 2007 14:10:20 +0200, Rodolfo Giometti wrote:
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4proid=18).
Signed-off-by: Rodolfo Giometti
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4proid=18).
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/tsl2550.c | 453
On Tue, Jun 19, 2007 at 03:39:40PM +0200, Jean Delvare wrote:
Hi Rodolfo,
On Tue, 19 Jun 2007 14:10:20 +0200, Rodolfo Giometti wrote:
Add support for Taos TSL2550 ambient light sensors.
(http://www.taosinc.com/product_detail.asp?cateid=4proid=18).
Signed-off-by: Rodolfo Giometti
Hello,
here my first proposal for LinuxPPS implemented with new specific
syscalls.
I'd like some comments before sending a "definitive" patch. :)
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Hello,
here my first proposal for LinuxPPS implemented with new specific
syscalls.
I'd like some comments before sending a definitive patch. :)
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
On Wed, Jun 06, 2007 at 11:24:16PM +0200, Rodolfo Giometti wrote:
> On Wed, Jun 06, 2007 at 01:29:34PM -0700, Andrew Morton wrote:
>
> > >asmlinkage long sys_time_pps_find(int cmd, int __user *source,
> > > char _
On Wed, Jun 06, 2007 at 11:24:16PM +0200, Rodolfo Giometti wrote:
On Wed, Jun 06, 2007 at 01:29:34PM -0700, Andrew Morton wrote:
asmlinkage long sys_time_pps_find(int cmd, int __user *source,
char __user *name, int namelen
On Wed, Jun 06, 2007 at 01:29:34PM -0700, Andrew Morton wrote:
> >asmlinkage long sys_time_pps_find(int cmd, int __user *source,
> > char __user *name, int namelen,
> > char __user *path, int pathlen);
Try to
On Wed, Jun 06, 2007 at 08:06:25PM +0200, Pierre Ossman wrote:
>
> I'm afraid I have little experience with PXA. Perhaps you can find
> someone on the linux arm kernel mailing list with more insight?
I already asked for.
> Sounds like a fairly common card. Cards so broken that they give an
>
On Wed, Jun 06, 2007 at 08:06:25PM +0200, Pierre Ossman wrote:
I'm afraid I have little experience with PXA. Perhaps you can find
someone on the linux arm kernel mailing list with more insight?
I already asked for.
Sounds like a fairly common card. Cards so broken that they give an
On Wed, Jun 06, 2007 at 01:29:34PM -0700, Andrew Morton wrote:
asmlinkage long sys_time_pps_find(int cmd, int __user *source,
char __user *name, int namelen,
char __user *path, int pathlen);
Try to find
Hello,
after a little studing on new generic netlink interface and some
letters with Andrew Morton I decided to drop using the netlink API at
all and start using new specific syscalls.
Looking at current LinuxPPS API and at RFC2783 I think we need the
following syscalls:
asmlinkage long
Hello,
after a little studing on new generic netlink interface and some
letters with Andrew Morton I decided to drop using the netlink API at
all and start using new specific syscalls.
Looking at current LinuxPPS API and at RFC2783 I think we need the
following syscalls:
asmlinkage long
On Sun, Jun 03, 2007 at 02:03:29PM +0200, Pierre Ossman wrote:
>
> To my knowledge, no such version exists. So either your card is broken or you
> have some transfer problem on your board. What's the name of this card and
> have
> you tried any others?
I suppose the same... but this is the only
On Sun, Jun 03, 2007 at 02:03:29PM +0200, Pierre Ossman wrote:
To my knowledge, no such version exists. So either your card is broken or you
have some transfer problem on your board. What's the name of this card and
have
you tried any others?
I suppose the same... but this is the only
Hello,
using MMC/SD support on my PXA270 based board I get this error:
mmc0: unrecognised SCR structure version 1
when I insert a MINISD card.
I tried to find on the net some specifications for the SCR structure
version 1 but I found nothing useful... someone has a similar problem
or can
Hello,
using MMC/SD support on my PXA270 based board I get this error:
mmc0: unrecognised SCR structure version 1
when I insert a MINISD card.
I tried to find on the net some specifications for the SCR structure
version 1 but I found nothing useful... someone has a similar problem
or can
pointy stick for failing to document
> their damned APIs.
This should vanish when new netlink layer will be used.
> - Generally: code looks OK and is probably useful. Please keep going ;)
Hope I forgot nothing!
Ciao,
Rodolfo
diff --git a/Documentation/pps.txt b/Documentation/pps.txt
n
/pps.txt b/Documentation/pps.txt
new file mode 100644
index 000..f07b098
--- /dev/null
+++ b/Documentation/pps.txt
@@ -0,0 +1,183 @@
+
+ PPS - Pulse Per Second
+ --
+
+(C) Copyright 2007 Rodolfo Giometti [EMAIL PROTECTED]
+
+This program is free software; you can redistribute
On Thu, May 10, 2007 at 04:01:52AM -0700, David Miller wrote:
>
> It's not OK, please use the generic netlink interface and as
> such you will not need to allocate any numbers at all.
>
> Documentation/networking/generic_netlink.txt gives a link
> to some infomration on this topic.
Where can I
On Thu, May 10, 2007 at 04:01:52AM -0700, David Miller wrote:
>
> It's not OK, please use the generic netlink interface and as
> such you will not need to allocate any numbers at all.
>
> Documentation/networking/generic_netlink.txt gives a link
> to some infomration on this topic.
If I well
On Thu, May 10, 2007 at 12:27:40AM -0700, Andrew Morton wrote:
>
> Please check with Dave Miller that this:
>
> #define NETLINK_PPSAPI 20
>
> reservation is OK.
Hello, as you can see here Andrew Morton asked to me to check with you
about NETLINK_PPSAPI reservation.
Please,
On Thu, May 10, 2007 at 12:27:40AM -0700, Andrew Morton wrote:
Please check with Dave Miller that this:
#define NETLINK_PPSAPI 20
reservation is OK.
Hello, as you can see here Andrew Morton asked to me to check with you
about NETLINK_PPSAPI reservation.
Please, let me
On Thu, May 10, 2007 at 04:01:52AM -0700, David Miller wrote:
It's not OK, please use the generic netlink interface and as
such you will not need to allocate any numbers at all.
Documentation/networking/generic_netlink.txt gives a link
to some infomration on this topic.
If I well
On Thu, May 10, 2007 at 04:01:52AM -0700, David Miller wrote:
It's not OK, please use the generic netlink interface and as
such you will not need to allocate any numbers at all.
Documentation/networking/generic_netlink.txt gives a link
to some infomration on this topic.
Where can I find
On Wed, May 02, 2007 at 02:06:53PM -0700, john stultz wrote:
>
> Please inline your patch, rather then attaching them. It makes it very
> difficult to discuss when it is attached.
Ok.
> > +++ b/drivers/pps/clients/ktimer.c
> > @@ -0,0 +1,106 @@
> > +/*
> > + * ktimer.c -- kernel timer test
On Wed, May 02, 2007 at 02:06:53PM -0700, john stultz wrote:
Please inline your patch, rather then attaching them. It makes it very
difficult to discuss when it is attached.
Ok.
+++ b/drivers/pps/clients/ktimer.c
@@ -0,0 +1,106 @@
+/*
+ * ktimer.c -- kernel timer test client
+ *
Pulse per Second (PPS) support for Linux.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---
Here my last release of PPS support for Linux.
The difference against my last patch is about all userland specific
code (timepps.h) which has been removed, I hope now you can consider
Pulse per Second (PPS) support for Linux.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---
Here my last release of PPS support for Linux.
The difference against my last patch is about all userland specific
code (timepps.h) which has been removed, I hope now you can consider
adding
On Wed, Mar 21, 2007 at 04:35:22PM -0600, Reg Clemens wrote:
> > On Wed, Mar 21, 2007 at 10:55:58AM -0600, Reg Clemens wrote:
> > >
> > > Just one point with your patch.
> > > A couple of years ago there was a long discussion on the Linux Kernel
> > > mailing
> > > list
> > > as to how USER
On Wed, Mar 21, 2007 at 04:35:22PM -0600, Reg Clemens wrote:
On Wed, Mar 21, 2007 at 10:55:58AM -0600, Reg Clemens wrote:
Just one point with your patch.
A couple of years ago there was a long discussion on the Linux Kernel
mailing
list
as to how USER codes were not supposed
Auto unlock sectors on resume for auto locking flash on power up.
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c
b/drivers/mtd/chips/cfi_cmdset_0001.c
index f69184a..8a4395e 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drive
Auto unlock sectors on resume for auto locking flash on power up.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c
b/drivers/mtd/chips/cfi_cmdset_0001.c
index f69184a..8a4395e 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++ b/drivers/mtd
On Wed, Mar 21, 2007 at 10:55:58AM -0600, Reg Clemens wrote:
>
> Just one point with your patch.
> A couple of years ago there was a long discussion on the Linux Kernel mailing
> list
> as to how USER codes were not supposed to use KERNEL include files. Now I
> still
> see __KERNEL__ all over
On Wed, Mar 21, 2007 at 09:05:34AM +0100, Jon K Hellan wrote:
> Have you received any comments on this from the NTP community? From
> Ulrich Windl?
Not yet... that's why I reposted my patch.
Thanks,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device
On Wed, Mar 21, 2007 at 09:05:34AM +0100, Jon K Hellan wrote:
Have you received any comments on this from the NTP community? From
Ulrich Windl?
Not yet... that's why I reposted my patch.
Thanks,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device
On Wed, Mar 21, 2007 at 10:55:58AM -0600, Reg Clemens wrote:
Just one point with your patch.
A couple of years ago there was a long discussion on the Linux Kernel mailing
list
as to how USER codes were not supposed to use KERNEL include files. Now I
still
see __KERNEL__ all over the
On Thu, Mar 15, 2007 at 11:18:55AM -0400, Lennart Sorensen wrote:
> How come none of the .patch files in
> http://ftp.enneenne.com/pub/misc/linuxpps/refclocks/nmea/ can be
> accessed? Does your web server not like serving up .patch files?
Sorry. I set wrong file permissions. :)
Try now.
Ciao,
On Wed, Mar 14, 2007 at 04:57:32PM -0400, Lennart Sorensen wrote:
>
> Well it does work for our GPS receiver at least. Of course I have to
> change the baud rate in the driver since our unit doens't use the NNEA
> standard 4800. And the configure script for ntp doesn't recognize the
> v2
On Wed, Mar 14, 2007 at 04:57:32PM -0400, Lennart Sorensen wrote:
Well it does work for our GPS receiver at least. Of course I have to
change the baud rate in the driver since our unit doens't use the NNEA
standard 4800. And the configure script for ntp doesn't recognize the
v2 PPSAPI, so
On Thu, Mar 15, 2007 at 11:18:55AM -0400, Lennart Sorensen wrote:
How come none of the .patch files in
http://ftp.enneenne.com/pub/misc/linuxpps/refclocks/nmea/ can be
accessed? Does your web server not like serving up .patch files?
Sorry. I set wrong file permissions. :)
Try now.
Ciao,
On Wed, Mar 14, 2007 at 11:37:05AM -0400, Lennart Sorensen wrote:
> Well here is my current version of the refclock_nmea.c.patch for
> LinuxPPS. It now uses /dev/gps# for the nmea messages and /dev/pps# for
> the PPS device (which in my case is of course the same device). I am
> running some
On Wed, Mar 14, 2007 at 10:42:51AM -0400, Lennart Sorensen wrote:
>
> Now you said to check the return value of time_pps_readlink. Well it
I refere to readlink(), not to time_pps_readlink(). I'm sorry for
mistake.
> If the call was to readlink directly it needs to be done, while your
>
On Wed, Mar 14, 2007 at 10:12:53AM -0400, Lennart Sorensen wrote:
>
> I looked at those, and they didn't sound important. I will grab it
> anyhow just for completeness.
Ok! Thanks.
> Well I think I may just write a small tool to do the ioctl to enable it
> so I don't need the full setserial
On Wed, Mar 14, 2007 at 09:19:34AM -0400, Lennart Sorensen wrote:
>
> I will grab the last couple of commits and try although they didn't
> sound like they really make much difference.
Some fixes up... see the git log for further info.
> I couldn't find any way to do that with setserial (at
On Tue, Mar 13, 2007 at 06:48:17PM -0400, Lennart Sorensen wrote:
>
> I have tried out 3.0.0-rc2 which seems to work pretty well so far (when
Thanks. I just posted to the linux kernel ML the last release
3.0.0. Maybe you can do a "git pull" and try it out. :)
> combined with the patches to the
On Tue, Mar 13, 2007 at 06:48:17PM -0400, Lennart Sorensen wrote:
I have tried out 3.0.0-rc2 which seems to work pretty well so far (when
Thanks. I just posted to the linux kernel ML the last release
3.0.0. Maybe you can do a git pull and try it out. :)
combined with the patches to the jsm
On Wed, Mar 14, 2007 at 09:19:34AM -0400, Lennart Sorensen wrote:
I will grab the last couple of commits and try although they didn't
sound like they really make much difference.
Some fixes up... see the git log for further info.
I couldn't find any way to do that with setserial (at least
On Wed, Mar 14, 2007 at 10:12:53AM -0400, Lennart Sorensen wrote:
I looked at those, and they didn't sound important. I will grab it
anyhow just for completeness.
Ok! Thanks.
Well I think I may just write a small tool to do the ioctl to enable it
so I don't need the full setserial around.
On Wed, Mar 14, 2007 at 10:42:51AM -0400, Lennart Sorensen wrote:
Now you said to check the return value of time_pps_readlink. Well it
I refere to readlink(), not to time_pps_readlink(). I'm sorry for
mistake.
If the call was to readlink directly it needs to be done, while your
On Wed, Mar 14, 2007 at 11:37:05AM -0400, Lennart Sorensen wrote:
Well here is my current version of the refclock_nmea.c.patch for
LinuxPPS. It now uses /dev/gps# for the nmea messages and /dev/pps# for
the PPS device (which in my case is of course the same device). I am
running some more
.dev= {
.platform_data = _kbd,
},
};
static struct platform_device *platform_devices[] __initdata = {
_audio_device,
_keyboard,
_lcd_bl_device,
_keyb_bl_device,
};
Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
---diff --git a/drivers/input/ke
= {
.platform_data = wwpc1100_kbd,
},
};
static struct platform_device *platform_devices[] __initdata = {
wwpc1100_audio_device,
wwpc1100_keyboard,
wwpc1100_lcd_bl_device,
wwpc1100_keyb_bl_device,
};
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
---diff --git
On Thu, Feb 22, 2007 at 12:33:35PM +0200, Paul Sokolovsky wrote:
>
> We in handhelds.org codebase have attached patch* to make corgi_bl
> more suitable for general use. This patch was submitted to Richard
> (so, more votes needed ;-) ). Otherwise, snippet I pasted is from real
> machine
On Wed, Feb 21, 2007 at 10:16:45AM +, Pavel Machek wrote:
> Hi!
>
> > @@ -0,0 +1,206 @@
> > +
> > + PPS - Pulse Per Second
> > + --
> > +
> > +(C) Copyright 2007 Rodolfo Giometti <[EMAIL PROTE
On Thu, Feb 22, 2007 at 09:27:09AM +, Richard Purdie wrote:
>
> Yes, my point is that you shouldn't need to touch pxafb if you use the
> backlight class. I know pxafb has backlight hooks but they are probably
> going to get removed at some point as they should no longer be needed.
I see.
>
On Thu, Feb 22, 2007 at 12:51:48AM +0100, Roman Zippel wrote:
> Hi,
>
> On Wednesday 21 February 2007 13:04, Rodolfo Giometti wrote:
>
> > RFC simply doesn't consider the fact that you can have a PPS source
> > __without__ a filedes connected with, and a single f
On Wed, Feb 21, 2007 at 08:14:14AM -0800, H. Peter Anvin wrote:
>
> If you have a kernel driver at all, then it makes perfect sense. If you
> don't have a kernel driver at all, then it's irrelevant to the
> linux-kernel discussion.
???
So you are told me that if my PPS source is connected
On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote:
k> Why? It's the same, except that it already exists, generic one (not
> limited to pxafb), and requires 1 function (too bad that C doesn't
> support lambda's):
Ah, ok.
> I sent a bit of criticism for that too ;-). YMMV, but
On Thu, Feb 22, 2007 at 12:59:06AM +, Richard Purdie wrote:
>
> Reading through the patch its:
>
> 1) Not against any mainline kernel
> 2) Not against a recent kernel
I'm sorry, but the patch applay against the latest kernel. Please, try
it.
> There were a number of backlight class changes
On Thu, Feb 22, 2007 at 12:59:06AM +, Richard Purdie wrote:
Reading through the patch its:
1) Not against any mainline kernel
2) Not against a recent kernel
I'm sorry, but the patch applay against the latest kernel. Please, try
it.
There were a number of backlight class changes just
On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote:
k Why? It's the same, except that it already exists, generic one (not
limited to pxafb), and requires 1 function (too bad that C doesn't
support lambda's):
Ah, ok.
I sent a bit of criticism for that too ;-). YMMV, but kernel
On Wed, Feb 21, 2007 at 08:14:14AM -0800, H. Peter Anvin wrote:
If you have a kernel driver at all, then it makes perfect sense. If you
don't have a kernel driver at all, then it's irrelevant to the
linux-kernel discussion.
???
So you are told me that if my PPS source is connected with a
On Thu, Feb 22, 2007 at 12:51:48AM +0100, Roman Zippel wrote:
Hi,
On Wednesday 21 February 2007 13:04, Rodolfo Giometti wrote:
RFC simply doesn't consider the fact that you can have a PPS source
__without__ a filedes connected with, and a single filedes is
considered __always__
On Thu, Feb 22, 2007 at 09:27:09AM +, Richard Purdie wrote:
Yes, my point is that you shouldn't need to touch pxafb if you use the
backlight class. I know pxafb has backlight hooks but they are probably
going to get removed at some point as they should no longer be needed.
I see.
What
301 - 400 of 440 matches
Mail list logo
