I see these warnings on 32 bit ARM systems:
CC kernel/time.o
kernel/time.c: In function 'msecs_to_jiffies':
kernel/time.c:472: warning: integer constant is too large for 'long' type
kernel/time.c: In function 'usecs_to_jiffies':
kernel/time.c:487: warning: integer constant is too large for
On Tuesday 26 February 2008, Peter Zijlstra wrote:
>
> On Mon, 2008-02-25 at 14:33 -0800, David Brownell wrote:
>
> > > +#ifdef CONFIG_LOCKDEP
> > > +
> > > +/* tell lockdep that this IRQ's locks and its parent's locks are in
> > > + * differ
On Tuesday 26 February 2008, Haavard Skinnemoen wrote:
> > Another way to address that rm9200 issue would be to just rate
> > the TC clockevent source lower than the one based on the system
> > timer, so it's set up but never enabled ... and remember "t2_clk",
> > calling clk_enable() only when
On Tuesday 26 February 2008, Haavard Skinnemoen wrote:
> Ok. Let's drop the clock references...
>
> > > and it will always need a pointer through which to access the
> > > registers, so the mid-layer might as well do those things.
> >
> > True about doing the ioremap.
>
> ...and keep the
On Tuesday 26 February 2008, David Newall wrote:
>
> Hardware can be inserted and removed while we're in a suspend state; and
> there's nothing that we can do about it until we resume. Is it fair to
> say, then, that having started suspend, we could reasonably ignore any
> device insertion and
On Tuesday 26 February 2008, David Newall wrote:
Hardware can be inserted and removed while we're in a suspend state; and
there's nothing that we can do about it until we resume. Is it fair to
say, then, that having started suspend, we could reasonably ignore any
device insertion and
On Tuesday 26 February 2008, Haavard Skinnemoen wrote:
Ok. Let's drop the clock references...
and it will always need a pointer through which to access the
registers, so the mid-layer might as well do those things.
True about doing the ioremap.
...and keep the regs pointer,
On Tuesday 26 February 2008, Haavard Skinnemoen wrote:
Another way to address that rm9200 issue would be to just rate
the TC clockevent source lower than the one based on the system
timer, so it's set up but never enabled ... and remember t2_clk,
calling clk_enable() only when that
On Tuesday 26 February 2008, Peter Zijlstra wrote:
On Mon, 2008-02-25 at 14:33 -0800, David Brownell wrote:
+#ifdef CONFIG_LOCKDEP
+
+/* tell lockdep that this IRQ's locks and its parent's locks are in
+ * different categories, so that it won't detect false recursion
I see these warnings on 32 bit ARM systems:
CC kernel/time.o
kernel/time.c: In function 'msecs_to_jiffies':
kernel/time.c:472: warning: integer constant is too large for 'long' type
kernel/time.c: In function 'usecs_to_jiffies':
kernel/time.c:487: warning: integer constant is too large for
This "flaw" isn't a new thing, of course. I remember pointing out the rather
annoying proclivity of the PM framework to deadlock when suspend() tried to
remove USB devices ... back around 2.6.10 or so. Things have shuffled around
a bit, and gotten better in some cases, but not fundamentally
> So I'm think that the reason this only _changes_ the false
> recursion notification ...
Whoops, it's because of the following typo:
> --- a/arch/arm/plat-omap/gpio.c 2008-02-24 19:02:32.0 -0800
> +++ b/arch/arm/plat-omap/gpio.c 2008-02-25 10:54:29.0 -0800
> @@
> > I thought the way to use the *_nested() calls was "consistently"!
>
> Very much depends on your view of consistent :-)
>
> > That is, if one instance of a lock access uses it, they all should,
> > since that's the only way lockdep learns about equivalence classes.
> > Also, locks shouldn't
> > > Which reminds me...you were talking about a patch that adds oneshot
> > > support for the count/compare clocksource and more cleanups, but I
> > > don't think I've seen it...?
> >
> > I avoid sending non-working patches, and hadn't made time to
> > work on that issue recently.
>
> I was
> > > > +static cycle_t tc_get_cycles(void)
> > > > +{
> > > > + unsigned long flags;
> > > > + u32 lower, upper;
> > > > +
> > > > + raw_local_irq_save(flags);
> > >
> > > Why do you need to use the raw version?
> >
> > This is part of the system timer code, and
> > > > > ==> LOCKDEP feature is evidently missing:
> > > > > spin_lock_irq_nested(lock_ptr, lock_class)
> > > >
> > > > This rant is more lines than adding the API :-/ the reason for it not
> > > > being there is simple, it wasn't needed up until now.
> > >
> > > I suspected
On Thursday 21 February 2008, Alan Stern wrote:
> > = CUT HERE
> > Modify EHCI irq handling on the theory that at least some of the
> > "lost" IRQs are caused by goofage between multiple lowlevel IRQ
> > acking mechanisms: try rescanning before we exit the handler, in
> > case the
On Thursday 21 February 2008, Alan Stern wrote:
= CUT HERE
Modify EHCI irq handling on the theory that at least some of the
lost IRQs are caused by goofage between multiple lowlevel IRQ
acking mechanisms: try rescanning before we exit the handler, in
case the EHCI-internal ack
== LOCKDEP feature is evidently missing:
spin_lock_irq_nested(lock_ptr, lock_class)
This rant is more lines than adding the API :-/ the reason for it not
being there is simple, it wasn't needed up until now.
I suspected that was the case, but for all I
+static cycle_t tc_get_cycles(void)
+{
+ unsigned long flags;
+ u32 lower, upper;
+
+ raw_local_irq_save(flags);
Why do you need to use the raw version?
This is part of the system timer code, and it should never be a
preemption
Which reminds me...you were talking about a patch that adds oneshot
support for the count/compare clocksource and more cleanups, but I
don't think I've seen it...?
I avoid sending non-working patches, and hadn't made time to
work on that issue recently.
I was thinking that I
I thought the way to use the *_nested() calls was consistently!
Very much depends on your view of consistent :-)
That is, if one instance of a lock access uses it, they all should,
since that's the only way lockdep learns about equivalence classes.
Also, locks shouldn't move between
So I'm think that the reason this only _changes_ the false
recursion notification ...
Whoops, it's because of the following typo:
--- a/arch/arm/plat-omap/gpio.c 2008-02-24 19:02:32.0 -0800
+++ b/arch/arm/plat-omap/gpio.c 2008-02-25 10:54:29.0 -0800
@@ -1332,6
This flaw isn't a new thing, of course. I remember pointing out the rather
annoying proclivity of the PM framework to deadlock when suspend() tried to
remove USB devices ... back around 2.6.10 or so. Things have shuffled around
a bit, and gotten better in some cases, but not fundamentally
lockdep can work with the
code which uses spin_*_irq() calls that don't save/restore flags.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Against 2.6.25-rc3
include/linux/spinlock.h |6 ++
include/linux/spinlock_api_smp.h |2 ++
kernel/spinlock.c
> > > > Note that this won't be usable until the AT91 and AT32 platforms
> > > > incorporate patches to configure the relevant platform devices.
> > > > Those changes are probably 2.6.26 material.
> >
> > More specifically (and all those patches are available now):
> >
> > - AT91 needs
lers.)
> On Fri, 22 Feb 2008 17:28:37 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > +static cycle_t tc_get_cycles(void)
> > +{
> > + unsigned long flags;
> > + u32 lower, upper;
> > +
> > + raw_local_irq_save(
On Sun, 24 Feb 2008 18:45:54 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> On Fri, 22 Feb 2008 17:23:23 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Create based on and the
> > at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32
On Sun, 24 Feb 2008 18:45:54 +0100
Haavard Skinnemoen [EMAIL PROTECTED] wrote:
On Fri, 22 Feb 2008 17:23:23 -0800
David Brownell [EMAIL PROTECTED] wrote:
Create linux/atmel_tc.h based on asm-arm/arch-at91/at91-tc.h and the
at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32 SOCs
on AT91 seems to make the
DBGU lose characters sometimes ... that one-byte fifo makes trouble
whenever there's the slightest delay in IRQ handling, and NO_HZ can
easily add such delays as part of ensuring that jiffies is current
before invoking handlers.)
On Fri, 22 Feb 2008 17:28:37 -0800
David
Note that this won't be usable until the AT91 and AT32 platforms
incorporate patches to configure the relevant platform devices.
Those changes are probably 2.6.26 material.
More specifically (and all those patches are available now):
- AT91 needs clocksource/clockevent
that don't save/restore flags.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Against 2.6.25-rc3
include/linux/spinlock.h |6 ++
include/linux/spinlock_api_smp.h |2 ++
kernel/spinlock.c| 21 +++--
3 files changed, 27 insertions(+), 2
On Saturday 23 February 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 17:08:53 + Liam Girdwood <[EMAIL PROTECTED]> wrote:
> > +#define mV_to_uV(mV) (mV * 1000)
> > +#define uV_to_mV(uV) (uV / 1000)
> > +#define V_to_uV(V) (mV_to_uV(V * 1000))
> > +#define uV_to_V(uV)
On Saturday 23 February 2008, Andrew Morton wrote:
On Wed, 20 Feb 2008 17:08:53 + Liam Girdwood [EMAIL PROTECTED] wrote:
+#define mV_to_uV(mV) (mV * 1000)
+#define uV_to_mV(uV) (uV / 1000)
+#define V_to_uV(V) (mV_to_uV(V * 1000))
+#define uV_to_V(uV)(uV_to_mV(uV) /
> > > David, do you think writing 0 bytes is a valid use of this API?
> >
> > Just a zero byte transfer ... no, though it depends what you mean
> > by "valid". (I'm not sure I'd expect all controller drivers to
> > reject such requests.) That has no effect on bits-on-the-wire,
> > and would
On Friday 22 February 2008, Ned Forrester wrote:
>
> So, what I think you said is that it would be better for pxa2xx_spi to
> silently ignore a zero-length message, passing it back with the rest of
> the message when all is complete, than to reject the message.
Yes. Remember that the reason to
patches for
tclib support (always) and clockevents (or else this will only look
like a higher precision clocksource). It's an updated and modularized
version of an AT91-only patch that has circulated for some time now.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
As with the preceding
as somewhat quirky sixteen-bit timers.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Note that this won't be usable until the AT91 and AT32 platforms
incorporate patches to configure the relevant platform devices.
Those changes are probably 2.6.26 material.
drivers/misc/K
. One example of such a
driver is NAND driver for various FreeScale chips. On platforms update
with GPIO support, they can be used instead of a worst-case delay to
verify that the BUSY signal is off.
(Also includes a couple minor unrelated doc updates.)
Signed-off-by: David Brownell <[EMAIL PROTEC
On Friday 22 February 2008, Anton Vorontsov wrote:
> > +static inline int gpio_request(unsigned gpio, const char *label)
> > +{
> > + return -EINVAL;
>
> Could we return -ENOSYS instead, so drivers will able to distinguish
> between "something really failed" and "there is no gpio support,
>
> > For those PMIC that covers additional features, like
> > - usb vbus detection (or pull-up/pull-down)
> > - audio codec
> > - touch screen
> > - battery monitor/ fuel gauge
> > - battery charger
> > - possible many others
Certainly many others ... like MMC transceivers, high speed
> > If the driver could not handle zero length transfer, then the driver
> > should reject it (just like unsupported transfer mode). Then the
> > behavior will be 'assert chip select and wait some time' or 'rejected
> > by the driver'.
>
> This would be OK. It would not be hard to fix
> >> David, do you think writing 0 bytes is a valid use of this API?
> >
> > Just a zero byte transfer ... no, though it depends what you mean
> > by "valid". (I'm not sure I'd expect all controller drivers to
> > reject such requests.) That has no effect on bits-on-the-wire,
> > and would make
Quoth Atsushi Nemoto on Fri, 22 Feb 2008:
> On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat <[EMAIL PROTECTED]> wrote:
> > > > David, do you think writing 0 bytes is a valid use of this API?
> > >
> > > Just a zero byte transfer ... no, though it depends what you mean
> > > by "valid". (I'm not
Quoth Atsushi Nemoto on Fri, 22 Feb 2008:
On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat [EMAIL PROTECTED] wrote:
David, do you think writing 0 bytes is a valid use of this API?
Just a zero byte transfer ... no, though it depends what you mean
by valid. (I'm not sure I'd expect
David, do you think writing 0 bytes is a valid use of this API?
Just a zero byte transfer ... no, though it depends what you mean
by valid. (I'm not sure I'd expect all controller drivers to
reject such requests.) That has no effect on bits-on-the-wire,
and would make trouble for
If the driver could not handle zero length transfer, then the driver
should reject it (just like unsupported transfer mode). Then the
behavior will be 'assert chip select and wait some time' or 'rejected
by the driver'.
This would be OK. It would not be hard to fix pxa2xx_spi, for
For those PMIC that covers additional features, like
- usb vbus detection (or pull-up/pull-down)
- audio codec
- touch screen
- battery monitor/ fuel gauge
- battery charger
- possible many others
Certainly many others ... like MMC transceivers, high speed USB
On Friday 22 February 2008, Anton Vorontsov wrote:
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+ return -EINVAL;
Could we return -ENOSYS instead, so drivers will able to distinguish
between something really failed and there is no gpio support,
fallback to
require them. One example of such a
driver is NAND driver for various FreeScale chips. On platforms update
with GPIO support, they can be used instead of a worst-case delay to
verify that the BUSY signal is off.
(Also includes a couple minor unrelated doc updates.)
Signed-off-by: David Brownell
interfacing (such as PWM and
measurement), or used as somewhat quirky sixteen-bit timers.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Note that this won't be usable until the AT91 and AT32 platforms
incorporate patches to configure the relevant platform devices.
Those changes are probably 2.6.26
patches for
tclib support (always) and clockevents (or else this will only look
like a higher precision clocksource). It's an updated and modularized
version of an AT91-only patch that has circulated for some time now.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
As with the preceding patch
On Friday 22 February 2008, Ned Forrester wrote:
So, what I think you said is that it would be better for pxa2xx_spi to
silently ignore a zero-length message, passing it back with the rest of
the message when all is complete, than to reject the message.
Yes. Remember that the reason to
David, do you think writing 0 bytes is a valid use of this API?
Just a zero byte transfer ... no, though it depends what you mean
by valid. (I'm not sure I'd expect all controller drivers to
reject such requests.) That has no effect on bits-on-the-wire,
and would make trouble for
> libata uses it under the assumption that "other parts" of the system are
> aware of this variable.
>
> May I assume that the API has changed such that this is no longer necessary?
Yes. The original motivation for dev->power.power_state was to let
the writes to /sys/devices/.../power/state
> David, do you think writing 0 bytes is a valid use of this API?
Just a zero byte transfer ... no, though it depends what you mean
by "valid". (I'm not sure I'd expect all controller drivers to
reject such requests.) That has no effect on bits-on-the-wire,
and would make trouble for various
David, do you think writing 0 bytes is a valid use of this API?
Just a zero byte transfer ... no, though it depends what you mean
by valid. (I'm not sure I'd expect all controller drivers to
reject such requests.) That has no effect on bits-on-the-wire,
and would make trouble for various DMA
libata uses it under the assumption that other parts of the system are
aware of this variable.
May I assume that the API has changed such that this is no longer necessary?
Yes. The original motivation for dev-power.power_state was to let
the writes to /sys/devices/.../power/state support a
On Wednesday 20 February 2008, Haavard Skinnemoen wrote:
> >
> > Unfortunately it did not work. The clock state did not change by
> > writing MR register.
>
> Ok, thanks for testing.
>
> In that case, I think the best fix is to let NPCS0 stay selected
> permanently in MR and overwrite CSR0
On Wednesday 20 February 2008, Atsushi Nemoto wrote:
> > David, do you want me to pass on the patch with my signoff or just ask
> > Andrew to add my Acked-by to the patch already in mm?
>
> The patch in mm also lacks my Signed-off line. I had thought Andrew
> never take a patch without
On Wednesday 20 February 2008, Andre Tomt wrote:
> David Brownell wrote:
> > On Wednesday 20 February 2008, Andre Tomt wrote:
> >> It has not crashed yet with the patch though.
> >
> > It seems that one of the tweks in this patch made the watchdog
> > act b
On Wednesday 20 February 2008, Alan Stern wrote:
> On Wed, 20 Feb 2008, David Brownell wrote:
>
> > On Wednesday 20 February 2008, Alan Stern wrote:
> > > > ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> > >
> > > lines in t
On Wednesday 20 February 2008, Alan Stern wrote:
> > ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
>
> lines in the log brings up some ideas that have been percolating in my
> mind for a while. They have to do with the possibility of a race
> between the watchdog routine
On Wednesday 20 February 2008, Andre Tomt wrote:
> ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
> ehci_hcd :00:1d.7: IAA
On Wednesday 20 February 2008, Andre Tomt wrote:
ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
ehci_hcd :00:1d.7: IAA watchdog,
On Wednesday 20 February 2008, Alan Stern wrote:
ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
lines in the log brings up some ideas that have been percolating in my
mind for a while. They have to do with the possibility of a race
between the watchdog routine and
On Wednesday 20 February 2008, Alan Stern wrote:
On Wed, 20 Feb 2008, David Brownell wrote:
On Wednesday 20 February 2008, Alan Stern wrote:
ehci_hcd :00:1d.7: IAA watchdog, lost IAA: status 8029 cmd 10021
lines in the log brings up some ideas that have been percolating in my
On Wednesday 20 February 2008, Andre Tomt wrote:
David Brownell wrote:
On Wednesday 20 February 2008, Andre Tomt wrote:
It has not crashed yet with the patch though.
It seems that one of the tweks in this patch made the watchdog
act better than before. So unless I hear from you
On Wednesday 20 February 2008, Haavard Skinnemoen wrote:
Unfortunately it did not work. The clock state did not change by
writing MR register.
Ok, thanks for testing.
In that case, I think the best fix is to let NPCS0 stay selected
permanently in MR and overwrite CSR0 with to the
On Wednesday 20 February 2008, Atsushi Nemoto wrote:
David, do you want me to pass on the patch with my signoff or just ask
Andrew to add my Acked-by to the patch already in mm?
The patch in mm also lacks my Signed-off line. I had thought Andrew
never take a patch without Signed-off line
On Tuesday 19 February 2008, Andre Tomt wrote:
>
> > Can you try this diagnostic patch, to see if it reports any messages
> > about IAA and/or IAAD oddities? There's surely a quick workaround
> > for this, but I'd rather understand the root cause before patching.
>
> Doesn't seem to have
On Tuesday 19 February 2008, David Miller wrote:
> From: Andre Tomt <[EMAIL PROTECTED]>
> Date: Tue, 19 Feb 2008 16:19:08 +0100
>
> > Got this on a serial console today, using 2.6.25-rc2-git1. Machine was
> > not doing anything interesting at the time, but has its / and kernel on
> > a
On Tuesday 19 February 2008, Ingo Molnar wrote:
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > > Thing is, this will catch not just regressions ... but cases where
> > > STR never worked in the first place. Video problems, etc. Also
> > > various system startup races, as in the PCMCIA and
On Tuesday 19 February 2008, Andre Tomt wrote:
> Got this on a serial console today, using 2.6.25-rc2-git1. Machine was
> not doing anything interesting at the time, but has its / and kernel on
> a usb-storage device (usb pen drive).
Can you try this diagnostic patch, to see if it reports any
On Tuesday 19 February 2008, Andre Tomt wrote:
Got this on a serial console today, using 2.6.25-rc2-git1. Machine was
not doing anything interesting at the time, but has its / and kernel on
a usb-storage device (usb pen drive).
Can you try this diagnostic patch, to see if it reports any
On Tuesday 19 February 2008, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Thing is, this will catch not just regressions ... but cases where
STR never worked in the first place. Video problems, etc. Also
various system startup races, as in the PCMCIA and MMC/SD/SDIO
On Tuesday 19 February 2008, Andre Tomt wrote:
Can you try this diagnostic patch, to see if it reports any messages
about IAA and/or IAAD oddities? There's surely a quick workaround
for this, but I'd rather understand the root cause before patching.
Doesn't seem to have triggered
On Tuesday 19 February 2008, David Miller wrote:
From: Andre Tomt [EMAIL PROTECTED]
Date: Tue, 19 Feb 2008 16:19:08 +0100
Got this on a serial console today, using 2.6.25-rc2-git1. Machine was
not doing anything interesting at the time, but has its / and kernel on
a usb-storage device
hines
> dislike this behavior...).
>
> Signed-off-by: Benedikt Spranger <[EMAIL PROTECTED]>
> Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
> drivers/usb/gadget/ether.c |1 +
> 1 file changed, 1 insertion(
one.
>
> (Makefile changes are in a separate patch for all of Documentation/.)
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
> Documentation/spi/spidev | 168 ---
> Documentatio
On Monday 18 February 2008, Ingo Molnar wrote:
>
> * David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > > - Includes a command line parameter, which needs work yet ... it
> > > > currently turns this test off, but it should also let the target
> &g
On Monday 18 February 2008, Atsushi Nemoto wrote:
>IIRC the clock state follows
> CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the patch from Haavard is likely
the right change.
> Like this (previous
On Monday 18 February 2008, Pavel Machek wrote:
> > How to fix ... how about: instead of just warning folk
> > off such legacy RTC drivers [1] we just wrap them with
> > an "if RTC_LIB != n" so this mistake won't be possible.
>
> Yes, disabling bad configs in Kconfig seems like way to go.
> > - Includes a command line parameter, which needs work yet ... it
> > currently turns this test off, but it should also let the target
> > state be specified (and maybe even default to "no test").
I think "no test" should be the default; STR working sanely on
x86 is unfortunately too
- Includes a command line parameter, which needs work yet ... it
currently turns this test off, but it should also let the target
state be specified (and maybe even default to no test).
I think no test should be the default; STR working sanely on
x86 is unfortunately too much a
On Monday 18 February 2008, Pavel Machek wrote:
How to fix ... how about: instead of just warning folk
off such legacy RTC drivers [1] we just wrap them with
an if RTC_LIB != n so this mistake won't be possible.
Yes, disabling bad configs in Kconfig seems like way to go.
Problem is ...
On Monday 18 February 2008, Atsushi Nemoto wrote:
IIRC the clock state follows
CSRn.CPOL just before the real transfer.
No ... clock state should be valid *before* chipselect goes
active. So I'm thinking the patch from Haavard is likely
the right change.
Like this (previous transfer
On Monday 18 February 2008, Ingo Molnar wrote:
* David Brownell [EMAIL PROTECTED] wrote:
- Includes a command line parameter, which needs work yet ... it
currently turns this test off, but it should also let the target
state be specified (and maybe even default
patch for all of Documentation/.)
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
Documentation/spi/spidev | 168 ---
Documentation/spi/spidev_fdx.c | 158 +
2 files changed, 160
...).
Signed-off-by: Benedikt Spranger [EMAIL PROTECTED]
Signed-off-by: Jan Altenberg [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
drivers/usb/gadget/ether.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.24/drivers/usb/gadget/ether.c
On Saturday 16 February 2008, Atsushi Nemoto wrote:
> Hi. Is it legal to use zero for 'len' field of struct spi_transfer?
> I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
Yes that should work ... it's uncommon, but not illegal. Some
controller drivers may even handle that right!
If the
On Saturday 16 February 2008, Atsushi Nemoto wrote:
Hi. Is it legal to use zero for 'len' field of struct spi_transfer?
I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
Yes that should work ... it's uncommon, but not illegal. Some
controller drivers may even handle that right!
If the delay
On Thursday 14 February 2008, David Newall wrote:
> RS232 is (normally) so much slower than USB that, on an extended
> transmission, the buffer internal to the local hardware can fill well
> before the remote device has demanded that transmission stop. In fact,
> now that you've mentioned it, I
On Thursday 14 February 2008, Uwe Kleine-König wrote:
> If you have GPIO_LIB gpio_cansleep oopses on an invalid
> gpio. So better gpio_request your pin first.
>
> Signed-off-by: Uwe Kleine-König <[EMAIL PROTECTED]>
> Cc: David Brownell <[EMAIL PROTECTED]>
Acked
On Thursday 14 February 2008, Uwe Kleine-König wrote:
If you have GPIO_LIB gpio_cansleep oopses on an invalid
gpio. So better gpio_request your pin first.
Signed-off-by: Uwe Kleine-König [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED
On Thursday 14 February 2008, David Newall wrote:
RS232 is (normally) so much slower than USB that, on an extended
transmission, the buffer internal to the local hardware can fill well
before the remote device has demanded that transmission stop. In fact,
now that you've mentioned it, I can't
e glue otherwise.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
include/linux/gpio.h | 93 +++
1 file changed, 93 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/include/linux/gpio.h2008-02-13 17:40:06.000
On Wednesday 13 February 2008, Andrew Morton wrote:
> Someone please fix.
This is what I was using purely for test builds ... most x86 hardware
actually has no GPIOs, and I sure don't have any of the "unusual" x86
platforms here, so I'd not want to see this version merge. Someone
more clued in
On Wednesday 13 February 2008, Felipe Balbi wrote:
> On Tue, Feb 12, 2008 at 12:32:34PM -0800, David Brownell wrote:
> >
> > Your proposal is to strike the "is_b_host" check. In terms of the
> > OTG (1.3) state machine, that removes a b_host --> b_peripheral
>
On Wednesday 13 February 2008, Felipe Balbi wrote:
On Tue, Feb 12, 2008 at 12:32:34PM -0800, David Brownell wrote:
Your proposal is to strike the is_b_host check. In terms of the
OTG (1.3) state machine, that removes a b_host -- b_peripheral
state transition.
Not at all, we're just
1 - 100 of 1706 matches
Mail list logo
