On Tue, Oct 23, 2007 at 04:17:50PM -0400, Dave Jones wrote:
> On Tue, Oct 23, 2007 at 08:04:18PM +0200, Rodolfo Giometti wrote:
>
> Hi Rodolfo,
Hi! :)
> > here my last patch for PPS support.
> >
> > Please, let me know if I have something to do for kernel inclus
On Tue, Oct 23, 2007 at 04:17:50PM -0400, Dave Jones wrote:
On Tue, Oct 23, 2007 at 08:04:18PM +0200, Rodolfo Giometti wrote:
Hi Rodolfo,
Hi! :)
here my last patch for PPS support.
Please, let me know if I have something to do for kernel inclusion.
Thanks for trying to get
On Sat, Oct 20, 2007 at 09:06:41PM -0700, Greg KH wrote:
>
> Please use a 'struct class' instead of a 'struct class_device'. We have
Ok, fixed. I'll repost my patch ASAP.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
On Sat, Oct 20, 2007 at 09:06:41PM -0700, Greg KH wrote:
Please use a 'struct class' instead of a 'struct class_device'. We have
Ok, fixed. I'll repost my patch ASAP.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
Hello,
here my last patch of LinuxPPS.
Main differences from old versions is that now (finally) each PPS
source is a dedicated char device!
This thanks to an agreement with NTP people who suggested to me how to
interpret RFC 2783 in such a way even a dedicated char device is now
RFC complain.
Hello,
here my last patch of LinuxPPS.
Main differences from old versions is that now (finally) each PPS
source is a dedicated char device!
This thanks to an agreement with NTP people who suggested to me how to
interpret RFC 2783 in such a way even a dedicated char device is now
RFC complain.
Hello,
someone is working on this device?
http://www.oxsemi.com/products/usb/OXU210HP.html
Thanks in advance,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems
Hello,
someone is working on this device?
http://www.oxsemi.com/products/usb/OXU210HP.html
Thanks in advance,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems
On Mon, Sep 24, 2007 at 12:34:08PM +0200, Haavard Skinnemoen wrote:
>
> I have a similar panel in the sense that it needs a bunch of SPI
> commands to get started. I implemented a LCD driver
> (drivers/video/backlight) for it so that it is automatically turned
> on/off at bootup/shutdown, and can
On Mon, Sep 24, 2007 at 12:34:08PM +0200, Haavard Skinnemoen wrote:
I have a similar panel in the sense that it needs a bunch of SPI
commands to get started. I implemented a LCD driver
(drivers/video/backlight) for it so that it is automatically turned
on/off at bootup/shutdown, and can be
Hello,
I have an LCD panel on a custom PXA27x based board and it must be turned
on/off by some special commands via a GPIO throught a I2C chip.
I'd like some suggestion about I can easily manage this situation.
Maybe can I add a special I2C function to get i2c_client pointer and then
using it
Hello,
I have an LCD panel on a custom PXA27x based board and it must be turned
on/off by some special commands via a GPIO throught a I2C chip.
I'd like some suggestion about I can easily manage this situation.
Maybe can I add a special I2C function to get i2c_client pointer and then
using it
Hello,
I'd like to have some suggestions from you about how I can implement
the "dynamic boot logo" feature in Linux reading the logo image from
the flash memory.
In my custom board, using u-boot I read a compressed BMP from the
flash memory and then I use it to display the logo, so users just
Hello,
I'd like to have some suggestions from you about how I can implement
the dynamic boot logo feature in Linux reading the logo image from
the flash memory.
In my custom board, using u-boot I read a compressed BMP from the
flash memory and then I use it to display the logo, so users just
On Wed, Aug 01, 2007 at 12:19:48AM +0530, Satyam Sharma wrote:
> That's just absolute bullshit.
...
> I'm sorry to say this, Rodolfo, but _all_ your arguments above are
> *totally* nonsensical and factually incorrect -- and I have had enough of
> trying to talk sense to you, it's been ~15 mails
On Tue, Jul 31, 2007 at 03:31:22AM +0530, Satyam Sharma wrote:
> Hi Rodolfo,
Hi :)
> Yup, this would avoid races, but then we will lose events. Why is that
> acceptable, when better alternative (above) exists?
Because is better lossign events then recording them delayed. In the
past we
On Tue, Jul 31, 2007 at 03:31:22AM +0530, Satyam Sharma wrote:
Hi Rodolfo,
Hi :)
Yup, this would avoid races, but then we will lose events. Why is that
acceptable, when better alternative (above) exists?
Because is better lossign events then recording them delayed. In the
past we (LinuxPPS
On Wed, Aug 01, 2007 at 12:19:48AM +0530, Satyam Sharma wrote:
That's just absolute bullshit.
...
I'm sorry to say this, Rodolfo, but _all_ your arguments above are
*totally* nonsensical and factually incorrect -- and I have had enough of
trying to talk sense to you, it's been ~15 mails in
On Mon, Jul 30, 2007 at 02:37:26PM +0530, Satyam Sharma wrote:
> On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
> >
> > In pps_event() is not useful using spin_lock_irqsave/restore() since
> > the only difference between spin_lock_irqsave() and spin_lock() is
> > th
On Mon, Jul 30, 2007 at 10:39:38AM +0530, Satyam Sharma wrote:
>
> Nopes, this isn't quite correct/safe. I suggest you should read:
>
> http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
I read it but still I don't see why my solution isn't correct/safe. :)
Can you please
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
>
> Fair enough, but I think the code could become a trifle simpler/easier
> after the conversion, so probably greater chances of getting merged :-)
I see. I'll start thinging about it.
> But that's alright -- see, as I said, you're
On Mon, Jul 30, 2007 at 09:49:20AM +0530, Satyam Sharma wrote:
>
> Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
> in pps_event() around the access to pps_source.
In pps_event() is not useful using spin_lock_irqsave/restore() since
the only difference between
On Mon, Jul 30, 2007 at 09:49:20AM +0530, Satyam Sharma wrote:
Hmm? I still don't see why you can't introduce spin_lock_irqsave/restore()
in pps_event() around the access to pps_source.
In pps_event() is not useful using spin_lock_irqsave/restore() since
the only difference between
On Mon, Jul 30, 2007 at 10:33:35AM +0530, Satyam Sharma wrote:
Fair enough, but I think the code could become a trifle simpler/easier
after the conversion, so probably greater chances of getting merged :-)
I see. I'll start thinging about it.
But that's alright -- see, as I said, you're
On Mon, Jul 30, 2007 at 10:39:38AM +0530, Satyam Sharma wrote:
Nopes, this isn't quite correct/safe. I suggest you should read:
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/
I read it but still I don't see why my solution isn't correct/safe. :)
Can you please propose
On Mon, Jul 30, 2007 at 02:37:26PM +0530, Satyam Sharma wrote:
On Mon, 30 Jul 2007, Rodolfo Giometti wrote:
In pps_event() is not useful using spin_lock_irqsave/restore() since
the only difference between spin_lock_irqsave() and spin_lock() is
that the former will turn off interrupts
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
> Take the race between the time_pps_setparams() syscall and a concurrent
> pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> the parameters for an existing source are not modified / set atomically,
> which
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> Ok, I've looked through (most of) the RFC and code now, and am only
> commenting on a design-level for now. Anyway, I didn't like the way
> you've significantly drifted from the RFC in several ways:
Please, read documentation
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> Take the race between the time_pps_setparams() syscall and a concurrent
> pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> the parameters for an existing source are not modified / set atomically,
> which
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
>
> I only glanced through the code, so could be wrong, but I noticed that
> the only global / shared data you have in there is a global "pps_source"
> array of pps_s structs. That's accessed / modified from the various
> syscalls
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
I only glanced through the code, so could be wrong, but I noticed that
the only global / shared data you have in there is a global pps_source
array of pps_s structs. That's accessed / modified from the various
syscalls introduced
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Take the race between the time_pps_setparams() syscall and a concurrent
pps_event() from an interrupt for instance. From sys_time_pps_setparams,
the parameters for an existing source are not modified / set atomically,
which means
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Ok, I've looked through (most of) the RFC and code now, and am only
commenting on a design-level for now. Anyway, I didn't like the way
you've significantly drifted from the RFC in several ways:
Please, read documentation file
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
Take the race between the time_pps_setparams() syscall and a concurrent
pps_event() from an interrupt for instance. From sys_time_pps_setparams,
the parameters for an existing source are not modified / set atomically,
which means
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
>
> My point is that the lock should be used to protect specific data. Thus, it
> would be more correct to say, "spinlock foo is taken because
> pps_register_source() accesses variable bar".
>
> That way, if someone else wants to
On Fri, Jul 27, 2007 at 01:08:58PM -0600, Chris Friesen wrote:
> Rodolfo Giometti wrote:
>
>> The pps_event() is now protected by a spinlock against
>> pps_register_source() and pps_unregister_source()...
>
> Locks protect data, not code. It may make more sense to ident
On Fri, Jul 27, 2007 at 01:40:14PM -0600, Chris Friesen wrote:
My point is that the lock should be used to protect specific data. Thus, it
would be more correct to say, spinlock foo is taken because
pps_register_source() accesses variable bar.
That way, if someone else wants to access bar,
On Fri, Jul 27, 2007 at 01:08:58PM -0600, Chris Friesen wrote:
Rodolfo Giometti wrote:
The pps_event() is now protected by a spinlock against
pps_register_source() and pps_unregister_source()...
Locks protect data, not code. It may make more sense to identify the
specific data being
On Tue, Jul 24, 2007 at 03:45:19PM +0100, David Woodhouse wrote:
> On Tue, 2007-07-24 at 16:31 +0200, Rodolfo Giometti wrote:
> > drivers/built-in.o: In function `sys_time_pps_fetch':
> > (.text+0x5f05e): undefined reference to `__udivdi3'
>
> Hm, not sure. Maybe pu
On Tue, Jul 24, 2007 at 02:49:02PM +0100, David Woodhouse wrote:
>
> I think you still haven't quite got the 32-bit vs. 64-bit compatibility
> right. Remember that on i386, the alignment of a uint64_t is only 4
> bytes, while on most other architectures it's 8 bytes. On i386, there
> will be no
On Tue, Jul 24, 2007 at 02:49:02PM +0100, David Woodhouse wrote:
> Also 's/unknow /unknown /' (2 instances)
?? I didn't find them:
$ grep 'unknow ' Documentation/pps/pps.txt
> Am I right in thinking that the only place it matters is within
> pps_event()? In that case, at the very least you
On Tue, Jul 24, 2007 at 02:49:02PM +0100, David Woodhouse wrote:
Also 's/unknow /unknown /' (2 instances)
?? I didn't find them:
$ grep 'unknow ' Documentation/pps/pps.txt
Am I right in thinking that the only place it matters is within
pps_event()? In that case, at the very least you
On Tue, Jul 24, 2007 at 02:49:02PM +0100, David Woodhouse wrote:
I think you still haven't quite got the 32-bit vs. 64-bit compatibility
right. Remember that on i386, the alignment of a uint64_t is only 4
bytes, while on most other architectures it's 8 bytes. On i386, there
will be no
On Tue, Jul 24, 2007 at 03:45:19PM +0100, David Woodhouse wrote:
On Tue, 2007-07-24 at 16:31 +0200, Rodolfo Giometti wrote:
drivers/built-in.o: In function `sys_time_pps_fetch':
(.text+0x5f05e): undefined reference to `__udivdi3'
Hm, not sure. Maybe put it back to uint32_t and then add
On Mon, Jul 23, 2007 at 02:35:16PM +0100, David Woodhouse wrote:
>
> s/Documentaion/Documentation/ in the last line of Documentation/pps/pps.txt
Fixed.
> Please feed it to scripts/checkpatch.pl -- you can ignore all the
> warnings about lines greater than 80 characters, and the complete crap
>
On Mon, Jul 23, 2007 at 02:35:16PM +0100, David Woodhouse wrote:
s/Documentaion/Documentation/ in the last line of Documentation/pps/pps.txt
Fixed.
Please feed it to scripts/checkpatch.pl -- you can ignore all the
warnings about lines greater than 80 characters, and the complete crap
about
On Sat, Jul 21, 2007 at 02:47:22PM -0700, David Brownell wrote:
> On Saturday 21 July 2007, Rodolfo Giometti wrote:
> > I reworked the driver according to latest suggestions from you.
>
> ... except for the most important one, which is to remove the
> requirement to
On Sat, Jul 21, 2007 at 02:47:22PM -0700, David Brownell wrote:
On Saturday 21 July 2007, Rodolfo Giometti wrote:
I reworked the driver according to latest suggestions from you.
... except for the most important one, which is to remove the
requirement to change every part of the gadget
Hello,
as promised I just published my version of the driver for PXA27x USB
device controller.
You can find all references om my wiki at:
http://wiki.enneenne.com/index.php/PXA27x_UDC
I reworked the driver according to latest suggestions from you. It's
far from perfection but it's still
Hello,
as promised I just published my version of the driver for PXA27x USB
device controller.
You can find all references om my wiki at:
http://wiki.enneenne.com/index.php/PXA27x_UDC
I reworked the driver according to latest suggestions from you. It's
far from perfection but it's still
On Wed, Jul 11, 2007 at 11:24:55AM -0400, Lennart Sorensen wrote:
> For some reason I thought this was for passing the current time of a
> stamp.
And you was right. :)
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
On Wed, Jul 11, 2007 at 11:22:38AM -0400, Lennart Sorensen wrote:
> On Wed, Jul 11, 2007 at 10:06:34AM +0200, Rodolfo Giometti wrote:
> > My question is: how can I fit a 64 bits number of seconds into
> > timespec structure which, for 32 bits architetures, has a 32 bits bits
> &
On Wed, Jul 11, 2007 at 10:17:47AM +0100, David Woodhouse wrote:
> On Tue, 2007-07-10 at 18:38 +0200, Rodolfo Giometti wrote:
> > On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
> > >
> > > I'm sure the version with 'volatile' will also be broken then.
On Tue, Jul 10, 2007 at 06:03:10PM -0400, Lennart Sorensen wrote:
>
> 32bit platforms can still work with 64bit values, they may just not be
> quite as efficient about it.
>
> After all we support files with more than 2^32 bytes in them, so the
> file access structures must have more than 32bit
On Tue, Jul 10, 2007 at 06:03:10PM -0400, Lennart Sorensen wrote:
32bit platforms can still work with 64bit values, they may just not be
quite as efficient about it.
After all we support files with more than 2^32 bytes in them, so the
file access structures must have more than 32bit values
On Wed, Jul 11, 2007 at 10:17:47AM +0100, David Woodhouse wrote:
On Tue, 2007-07-10 at 18:38 +0200, Rodolfo Giometti wrote:
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
I'm sure the version with 'volatile' will also be broken then. Sounds
like the right answer
On Wed, Jul 11, 2007 at 11:22:38AM -0400, Lennart Sorensen wrote:
On Wed, Jul 11, 2007 at 10:06:34AM +0200, Rodolfo Giometti wrote:
My question is: how can I fit a 64 bits number of seconds into
timespec structure which, for 32 bits architetures, has a 32 bits bits
number of seconds?
I
On Wed, Jul 11, 2007 at 11:24:55AM -0400, Lennart Sorensen wrote:
For some reason I thought this was for passing the current time of a
stamp.
And you was right. :)
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
On Tue, Jul 10, 2007 at 05:36:16PM +0100, David Woodhouse wrote:
>
> Why would there be problems?
I'm just asking since I don't know well 64 bits architectures. :)
However, how can I fix 64 bits seconds into struct timespec?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
>
> I'm sure the version with 'volatile' will also be broken then. Sounds
> like the right answer is to fix the locking.
But wish avoiding locking at all since this may delay the time stamp
recording. We (the LinuxPPS guys) niticed
On Tue, Jul 10, 2007 at 12:01:51PM -0400, Lennart Sorensen wrote:
> On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
> > struct pps_timedata_s {
> >__32 sec;
> >__32 nsec;
> > }
> >
> > Ok? I think 32 bits are eno
On Thu, Jun 28, 2007 at 02:29:49PM -0700, Andrew Morton wrote:
> >
> > +
> > +static int
> > +write_packet(volatile u32 * uddr, struct pxa27x_request *req, unsigned max)
>
> Please review Documentation/volatile-considered-harmful.txt
The attibute volatile here is necessary in order to avoid
On Thu, Jun 28, 2007 at 02:29:49PM -0700, Andrew Morton wrote:
+
+static int
+write_packet(volatile u32 * uddr, struct pxa27x_request *req, unsigned max)
Please review Documentation/volatile-considered-harmful.txt
The attibute volatile here is necessary in order to avoid getting the
On Tue, Jul 10, 2007 at 12:01:51PM -0400, Lennart Sorensen wrote:
On Sun, Jul 01, 2007 at 09:24:41PM +0200, Rodolfo Giometti wrote:
struct pps_timedata_s {
__32 sec;
__32 nsec;
}
Ok? I think 32 bits are enought for keeping seconds... :)
You want to purposely
On Tue, Jul 10, 2007 at 05:05:47PM +0100, David Woodhouse wrote:
I'm sure the version with 'volatile' will also be broken then. Sounds
like the right answer is to fix the locking.
But wish avoiding locking at all since this may delay the time stamp
recording. We (the LinuxPPS guys) niticed
On Tue, Jul 10, 2007 at 05:36:16PM +0100, David Woodhouse wrote:
Why would there be problems?
I'm just asking since I don't know well 64 bits architectures. :)
However, how can I fix 64 bits seconds into struct timespec?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:
On Sat, Jun 30, 2007 at 06:46:14AM -0700, David Brownell wrote:
>
> Has someone actually signed up to develop and maintain such a
> controller driver? If so, that would be a Fine Thing, but not
> one I've heard rumored before. I've assumed that the best we'd
> have is someone (Rodolfo?!)
a27x_keyboard.c
> @@ -140,7 +140,7 @@ static int pxakbd_resume(struct platform_device *pdev)
> KPREC = pdata->reg_kprec;
>
> /* Enable unit clock */
> - pxa_set_cken(CKEN19_KEYPAD, 1);
> + pxa_set_cken(CKEN_KEYPAD, 1);
> }
&g
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
>
> Looks relatively sane at first glance; busy this week so haven't looked
> very hard yet. Two thing though... you're mixing proper C types
> (uint32_t) and the Linux-specific legacy crap types (__u32). Pick one. I
> won't
On Mon, Jul 09, 2007 at 12:56:11PM +0200, Oleg Verych wrote:
> On Mon, Jul 09, 2007 at 11:16:43AM +0200, Rodolfo Giometti wrote:
> > On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
> > > * Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
> > > * Org
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
> * Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
> * Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
>
> > +.PHONY : all depend dep
> > +
> > +all : .depend $(TARGETS)
&g
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers, Embedded Systems and Courses
+.PHONY : all depend dep
+
+all : .depend $(TARGETS)
+
+.depend depend dep :
+ $(CC) $(CFLAGS
On Mon, Jul 09, 2007 at 12:56:11PM +0200, Oleg Verych wrote:
On Mon, Jul 09, 2007 at 11:16:43AM +0200, Rodolfo Giometti wrote:
On Sun, Jul 08, 2007 at 11:05:32AM +0200, Oleg Verych wrote:
* Rodolfo Giometti (Thu, 28 Jun 2007 18:14:50 +0200)
* Organization: GNU/Linux Device Drivers
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
Looks relatively sane at first glance; busy this week so haven't looked
very hard yet. Two thing though... you're mixing proper C types
(uint32_t) and the Linux-specific legacy crap types (__u32). Pick one. I
won't recommend
platform_device *pdev)
KPREC = pdata-reg_kprec;
/* Enable unit clock */
- pxa_set_cken(CKEN19_KEYPAD, 1);
+ pxa_set_cken(CKEN_KEYPAD, 1);
}
mutex_unlock(input_dev-mutex);
Acked-by: Rodolfo Giometti [EMAIL PROTECTED
On Sat, Jun 30, 2007 at 06:46:14AM -0700, David Brownell wrote:
Has someone actually signed up to develop and maintain such a
controller driver? If so, that would be a Fine Thing, but not
one I've heard rumored before. I've assumed that the best we'd
have is someone (Rodolfo?!) finally
Hello,
I'm looking for CAN project on Linux but I found only simple (old)
drivers for specific chips or projects like Socket-CAN still out of
the main kernel tree.
Did someone take a look at this topic? Does someone know a project for
introducing CAN support into Linux?
Thanks in advance,
Hello,
I'm looking for CAN project on Linux but I found only simple (old)
drivers for specific chips or projects like Socket-CAN still out of
the main kernel tree.
Did someone take a look at this topic? Does someone know a project for
introducing CAN support into Linux?
Thanks in advance,
Hello,
Looking at other rtc drivers I noticed that during the release()
method we should disable IRQs as follow:
static void ds1307_release(struct device *dev)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
if (ds1307->irq >= 0) {
ds1307->irqen = 0;
Hello,
Looking at other rtc drivers I noticed that during the release()
method we should disable IRQs as follow:
static void ds1307_release(struct device *dev)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
if (ds1307-irq = 0) {
ds1307-irqen = 0;
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
> On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote:
> > On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
> > >
> > > Seems reasonable enough in principle -- but whatever yo
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
>
> Seems reasonable enough in principle -- but whatever you do, don't use
> "long" for it. That would definitely need different behaviour for 32-bit
> vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Here the
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would definitely need different behaviour for 32-bit
vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Here the patch
On Tue, Jul 03, 2007 at 09:09:50AM -0400, David Woodhouse wrote:
On Tue, 2007-07-03 at 11:48 +0200, Rodolfo Giometti wrote:
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
>
> Seems reasonable enough in principle -- but whatever you do, don't use
> "long" for it. That would definitely need different behaviour for 32-bit
> vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Which is
On Sun, Jul 01, 2007 at 05:13:25PM +1000, Stephen Rothwell wrote:
> On Sat, 30 Jun 2007 19:13:40 +0200 Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> >
> > Maybe I can define a special struct for exchanging time data as:
> >
> >struct pps_timedata_s {
> &
On Sun, Jul 01, 2007 at 05:13:25PM +1000, Stephen Rothwell wrote:
On Sat, 30 Jun 2007 19:13:40 +0200 Rodolfo Giometti [EMAIL PROTECTED] wrote:
Maybe I can define a special struct for exchanging time data as:
struct pps_timedata_s {
long sec;
long nsec
On Sun, Jul 01, 2007 at 01:03:11PM +0100, David Woodhouse wrote:
Seems reasonable enough in principle -- but whatever you do, don't use
long for it. That would definitely need different behaviour for 32-bit
vs. 64-bit. Use explicitly sized types such as uint32_t or uint64_t.
Which is the
On Fri, Jun 29, 2007 at 05:40:52PM +0100, David Woodhouse wrote:
>
> Remember you have to support _both_ 32-bit and 64-bit system calls. You
> need to define struct compat_pps_info and struct compat_pps_params, and
> you'll have to provide a compat wrapper for sys_time_pps_getparams() and
>
On Sat, Jun 30, 2007 at 09:38:27AM +0100, Christoph Hellwig wrote:
>
> Sorry for coming in that late, but using syscalls for something as
> periphal sounds like a very bad idea to me, and the syscalls aren't
> defined nicely either (e.g. you have an ioctl lookalike). I'd say
> back to the
On Sat, Jun 30, 2007 at 09:38:27AM +0100, Christoph Hellwig wrote:
Sorry for coming in that late, but using syscalls for something as
periphal sounds like a very bad idea to me, and the syscalls aren't
defined nicely either (e.g. you have an ioctl lookalike). I'd say
back to the
On Fri, Jun 29, 2007 at 05:40:52PM +0100, David Woodhouse wrote:
Remember you have to support _both_ 32-bit and 64-bit system calls. You
need to define struct compat_pps_info and struct compat_pps_params, and
you'll have to provide a compat wrapper for sys_time_pps_getparams() and
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
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
On Fri, Jun 29, 2007 at 04:41:33PM +0100, David Woodhouse wrote:
>
> includes , for some reason.
> doesn't.
>
> You shouldn't rely on being pulled in like that -- you
> either need a forward declaration of struct timespec, or to include
> for yourself from
Can you please check if this
On Fri, Jun 29, 2007 at 04:25:16PM +0100, David Woodhouse wrote:
> On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
> > On Fri, Jun 29, 2007 at 12:38:02PM +0100, David Woodhouse wrote:
> > >
> > > It doesn't apply to the current git tree, which has alread
On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote:
>
> Let's start with *JUST* a driver, not trying to update everything
> else in the USB Gadget stack so that it looks like it's designed
> specifically to handle all of Intel's design botches related to
> endpoint config ... and work
On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote:
Let's start with *JUST* a driver, not trying to update everything
else in the USB Gadget stack so that it looks like it's designed
specifically to handle all of Intel's design botches related to
endpoint config ... and work
On Fri, Jun 29, 2007 at 04:25:16PM +0100, David Woodhouse wrote:
On Fri, 2007-06-29 at 17:08 +0200, Rodolfo Giometti wrote:
On Fri, Jun 29, 2007 at 12:38:02PM +0100, David Woodhouse wrote:
It doesn't apply to the current git tree, which has already had some new
system calls added
On Fri, Jun 29, 2007 at 04:41:33PM +0100, David Woodhouse wrote:
asm-i386/signal.h includes linux/time.h, for some reason.
asm-powerpc/signal.h doesn't.
You shouldn't rely on linux/time.h being pulled in like that -- you
either need a forward declaration of struct timespec, or to include
201 - 300 of 440 matches
Mail list logo
