---
include/linux/pci_ids.h |1 +
4 files changed, 61 insertions(+), 10 deletions(-)
Nicolas Pitre (1):
mmc: remove unused 'mode' from the mmc_host structure
Pierre Ossman (4):
sdhci: describe quirks
sdhci: don't warn about sdhci 2.0 controllers
sdhci: use PIO when DMA can't
---
include/linux/pci_ids.h |1 +
4 files changed, 61 insertions(+), 10 deletions(-)
Nicolas Pitre (1):
mmc: remove unused 'mode' from the mmc_host structure
Pierre Ossman (4):
sdhci: describe quirks
sdhci: don't warn about sdhci 2.0 controllers
sdhci: use PIO when DMA can't
On Mon, 10 Dec 2007 19:11:12 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 09, 2007 at 06:08:18PM +0100, Pierre Ossman wrote:
> >
> > This still requires a bit of maintenance to set up a kerneltypes.h for
> > every arch.
>
> Better doing this wor
On Mon, 10 Dec 2007 19:11:12 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Sun, Dec 09, 2007 at 06:08:18PM +0100, Pierre Ossman wrote:
This still requires a bit of maintenance to set up a kerneltypes.h for
every arch.
Better doing this work once than fixing similar issues again
On Sat, 8 Dec 2007 22:58:11 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote:
> > So, just insert two bits of padding in sdio_device_id and insert a comment
> > saying "/* Explicit padding: works even if we're cross-compiling */".
>
>
On Sun, 2 Dec 2007 12:22:31 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> I gave it a try:
> - Remove existing alignment attributes from some device_id types
> - Introduce kernel_* types with proper size and alignment for
> cross-compilation (sample for m68k included)
>
On Thu, 06 Dec 2007 23:12:46 -0500 (EST)
Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> This field and corresponding defines are simply never used anywhere
> in the code. But its mere presence is enough to confuse some host
> driver authors who attempt to rely on it. Let's eliminate the
>
On Sun, 2 Dec 2007 12:22:31 +0100 (CET)
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
I gave it a try:
- Remove existing alignment attributes from some device_id types
- Introduce kernel_* types with proper size and alignment for
cross-compilation (sample asm/kerneltypes.h for m68k
On Sat, 8 Dec 2007 22:58:11 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Mon, Dec 03, 2007 at 09:02:19PM +1100, Rusty Russell wrote:
So, just insert two bits of padding in sdio_device_id and insert a comment
saying /* Explicit padding: works even if we're cross-compiling */.
We had one
On Thu, 06 Dec 2007 23:12:46 -0500 (EST)
Nicolas Pitre [EMAIL PROTECTED] wrote:
This field and corresponding defines are simply never used anywhere
in the code. But its mere presence is enough to confuse some host
driver authors who attempt to rely on it. Let's eliminate the
possibility
On Thu, 29 Nov 2007 16:40:37 -0700
Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
>
> The corresponding PCI code in pci_device_suspend() does not do
> any generic device disable or resource release. I don't know
> why PNP disables the device on suspend. I glanced through the
> ACPI spec but didn't
On Wed, 28 Nov 2007 13:34:02 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007, Pierre Ossman wrote:
> >
> > Is there no directive we can stick in there that forces a reasonable
> > alignment (e.g. alignment == sizeof(type)) independently
On Sat, 01 Dec 2007 00:27:06 -0800
Vitaly Luban <[EMAIL PROTECTED]> wrote:
> Kernel "pci_ids.h" file has data for that card missing.
>
> Also, Ellen needs some control bits flipped before it functions properly
> as SDIO controller by the spec.
> Should apply clenly to Linus and Drzeus trees.
ou get to keep a down-rev
> virtual machine to do it right :-(
>
Nah. The previous gcc package is the one shipped with Fedora 8. So I could just
grab that one (plus cpp and libgomp) and downgrade.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.o
On Sat, 1 Dec 2007 15:42:23 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> The latest GCC in Fedora rawhide contains some serious bug (or provokes a
> latent one in the kernel) that makes every kernel built unbootable. It just
> locks up halfway through the init. Kernels
: No Plug & Play device found
Any ideas on how I can work around this? I'm rather unproductive when I can't
build working kernels.. :/
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdes
: No Plug Play device found
Any ideas on how I can work around this? I'm rather unproductive when I can't
build working kernels.. :/
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core
On Sat, 1 Dec 2007 15:42:23 +0100
Pierre Ossman [EMAIL PROTECTED] wrote:
The latest GCC in Fedora rawhide contains some serious bug (or provokes a
latent one in the kernel) that makes every kernel built unbootable. It just
locks up halfway through the init. Kernels that previously worked
virtual machine to do it right :-(
Nah. The previous gcc package is the one shipped with Fedora 8. So I could just
grab that one (plus cpp and libgomp) and downgrade.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http
On Sat, 01 Dec 2007 00:27:06 -0800
Vitaly Luban [EMAIL PROTECTED] wrote:
Kernel pci_ids.h file has data for that card missing.
Also, Ellen needs some control bits flipped before it functions properly
as SDIO controller by the spec.
Should apply clenly to Linus and Drzeus trees. Please
On Wed, 28 Nov 2007 13:34:02 +0100 (CET)
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Wed, 28 Nov 2007, Pierre Ossman wrote:
Is there no directive we can stick in there that forces a reasonable
alignment (e.g. alignment == sizeof(type)) independently of arch?
We could use something
On Thu, 29 Nov 2007 16:40:37 -0700
Bjorn Helgaas [EMAIL PROTECTED] wrote:
The corresponding PCI code in pci_device_suspend() does not do
any generic device disable or resource release. I don't know
why PNP disables the device on suspend. I glanced through the
ACPI spec but didn't see a
, UART_IER, port->ier);
}
-static void sdio_uart_receive_chars(struct sdio_uart_port *port, int *status)
+static void sdio_uart_receive_chars(struct sdio_uart_port *port, unsigned int
*status)
{
struct tty_struct *tty = port->tty;
unsigned int ch, flag;
--
--
, UART_IER, port-ier);
}
-static void sdio_uart_receive_chars(struct sdio_uart_port *port, int *status)
+static void sdio_uart_receive_chars(struct sdio_uart_port *port, unsigned int
*status)
{
struct tty_struct *tty = port-tty;
unsigned int ch, flag;
--
-- Pierre Ossman
On Wed, 28 Nov 2007 09:28:56 +
Al Viro <[EMAIL PROTECTED]> wrote:
>
> Eh... m68k has 16bit alignment for unsigned long.
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@
On Wed, 28 Nov 2007 10:27:18 +0100 (CET)
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>
> So the problem is in scripts/mod/file2alias.c, which gives a different
> sizeof(struct sdio_device_id) on the cross-compile host:
> - sizeof(struct sdio_device_id) = 12 on ia32
> - sizeof(struct
On Tue, 27 Nov 2007 22:07:23 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Current Linus tree give me this, with m68k allmodconfig:
>
> FATAL: drivers/bluetooth/btsdio: sizeof(struct sdio_device_id)=12 is not a
> modulo of the size of section __mod_sdio_device_table=30.
> Fix definition
On Tue, 27 Nov 2007 22:07:23 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Current Linus tree give me this, with m68k allmodconfig:
FATAL: drivers/bluetooth/btsdio: sizeof(struct sdio_device_id)=12 is not a
modulo of the size of section __mod_sdio_device_table=30.
Fix definition of struct
On Wed, 28 Nov 2007 10:27:18 +0100 (CET)
Geert Uytterhoeven [EMAIL PROTECTED] wrote:
So the problem is in scripts/mod/file2alias.c, which gives a different
sizeof(struct sdio_device_id) on the cross-compile host:
- sizeof(struct sdio_device_id) = 12 on ia32
- sizeof(struct
On Wed, 28 Nov 2007 09:28:56 +
Al Viro [EMAIL PROTECTED] wrote:
Eh... m68k has 16bit alignment for unsigned long.
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -343,7
cept this particular bug looks like a post-2.6.23 regression, so I can cc
> the Rafael which never forgets, so it will then get tracked all the way into
> Linus's tree)
>
Jens said he applied it, so I figured the issue was handled. Jens, what
happened to it?
Rgds
--
-- Pierre Ossma
now most drivers will handle all of these things as they see
fit. Haven't seen a single bug report about it yet so...
Just change the voltage in whatever way makes sense for your controller.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudi
. Haven't seen a single bug report about it yet so...
Just change the voltage in whatever way makes sense for your controller.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core
a post-2.6.23 regression, so I can cc
the Rafael which never forgets, so it will then get tracked all the way into
Linus's tree)
Jens said he applied it, so I figured the issue was handled. Jens, what
happened to it?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> > It most certainly does not. gcc will assume that an int* has int alignment.
> > memcpy() is a builtin, which gcc can translate to
dev_dbg(>class_dev, "data FIFO error\n");
> + data->error = -EIO;
> + }
> + dev_dbg(>class_dev, "bytes xfered: %u\n",
> + data->bytes_xfered);
> +
The debug output here is already provided
char* or void* to something else, you better be damn sure the alignment is
correct because gcc will assume it is.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
: Andre Haupt <[EMAIL PROTECTED]>
> Signed-off-by: Andre Haupt <[EMAIL PROTECTED]>
Nicolas, does this seem correct to you? I'm not familiar with the serial stuff.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core deve
alignment, gcc can't really do anything creative.)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: se
creative.)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
]
Signed-off-by: Andre Haupt [EMAIL PROTECTED]
Nicolas, does this seem correct to you? I'm not familiar with the serial stuff.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core
the alignment is
correct because gcc will assume it is.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list
);
+ cancel_delayed_work(host-mmc-detect);
Not for driver poking. Hands off! :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha [EMAIL PROTECTED] wrote:
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
It most certainly does not. gcc will assume that an int* has int alignment.
memcpy() is a builtin, which gcc can translate to pretty much anything
I'll just readd my reply again. :)
On Fri, 23 Nov 2007 16:13:18 +0100
Nicolas Ferre <[EMAIL PROTECTED]> wrote:
> I take advantage of this thread to ask a question about the SDIO cards
> you are using to test the stack.
>
> I look at the page on the MMC wiki :
> http://mmc.drzeus.cx/wiki/SDIO
>
I'll just readd my reply again. :)
On Fri, 23 Nov 2007 16:13:18 +0100
Nicolas Ferre [EMAIL PROTECTED] wrote:
I take advantage of this thread to ask a question about the SDIO cards
you are using to test the stack.
I look at the page on the MMC wiki :
http://mmc.drzeus.cx/wiki/SDIO
but
ken, but I do not think
sdio_io_rw_ext_helper() is. I'll be doing a fix eventually, but it probably
won't get that high on my todo list as it will only be useful together with
some new API. Since your card was content with byte transfers, it shouldn't be
that much need for a rush.
Rgds
a more low-level API. The big problem with
such a call would be that it can fail requests because the host or card cannot
satisfy them. So a function driver using such an API would have to use a much
more defensive programming (which can incur a performance hit).
Rgds
--
-- Pierre Ossman
(which can incur a performance hit).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line
eventually, but it probably
won't get that high on my todo list as it will only be useful together with
some new API. Since your card was content with byte transfers, it shouldn't be
that much need for a rush.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
deletions(-)
Alex Dubov (1):
tifm_sd: handle non-power-of-2 block sizes
David Woodhouse (1):
mmc: Avoid re-using minor numbers before the original device is closed.
Pierre Ossman (1):
mmc_block: check card state after write
--
-- Pierre Ossman
Linux kernel, MMC maintainer
There are no drivers using "increase address" yet. The ones so far have all
used a single byte FIFO port.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
you have any evidence that any card drivers will use
sdio_io_rw_ext_helper() in a manner that needs the START ADDRESS to be
changed by the core driver ?
There are no drivers using increase address yet. The ones so far have all
used a single byte FIFO port.
Rgds
--
-- Pierre Ossman
deletions(-)
Alex Dubov (1):
tifm_sd: handle non-power-of-2 block sizes
David Woodhouse (1):
mmc: Avoid re-using minor numbers before the original device is closed.
Pierre Ossman (1):
mmc_block: check card state after write
--
-- Pierre Ossman
Linux kernel, MMC maintainer
trying to bypass every system in the
kernel. ;)
(Not to mention you'll have a lot more work on your hands.)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www
look in
drivers/core/sdio_io.c if you don't want to build the full document.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
On Mon, 19 Nov 2007 11:44:54 +
Dean Jenkins <[EMAIL PROTECTED]> wrote:
> This E-mail is for the attention of Pierre Ossman (MMC sub-system
> maintainer)
A cc helps if you want my attention. ;)
>
> Hi Pierre,
>
> I've being trying to get SDIO block-mode with increm
On Mon, 19 Nov 2007 11:44:54 +
Dean Jenkins [EMAIL PROTECTED] wrote:
This E-mail is for the attention of Pierre Ossman (MMC sub-system
maintainer)
A cc helps if you want my attention. ;)
Hi Pierre,
I've being trying to get SDIO block-mode with incrementing address to
work
to put that pain and what compromises to make.
BTW. Is the API for the exported SDIO core functions documented
anywhere ?
Yes, as kerneldoc tags for the relevant functions. Have a look in
drivers/core/sdio_io.c if you don't want to build the full document.
Rgds
--
-- Pierre Ossman
. ;)
(Not to mention you'll have a lot more work on your hands.)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from
ring "waiting for helper to boot..." in that case.
Have you tried with the firmware that's supposed to be used with this board?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop,
with this board?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
f the firmware. Odd, as the loading loop first
queries the card if it is ready for more data.
You could try adding a delay to the helper firmware loading loop
(if_sdio_prog_helper() in if_sdio.c). Add an msleep(100); in there and see if
that gets things further. Loading will be slow as hell thou
try adding a delay to the helper firmware loading loop
(if_sdio_prog_helper() in if_sdio.c). Add an msleep(100); in there and see if
that gets things further. Loading will be slow as hell though.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
also support the general sentiment)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubsc
_QUIRK_BROKEN_DMA) &&
(host->flags & SDHCI_USE_DMA)) {
- DBG("Disabling DMA as it is marked broken");
+ DBG("Disabling DMA as it is marked broken\n");
host->flags &= ~SDHCI_USE_DMA;
}
--
-
n't the previous fix solve your problems?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send
s though. :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe li
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
, and the immediately issued subsequent
commands also fail since the card state was never checked before
sending these commands.
(There was a discussion about these cards at the thread: MMC:
CRC Errors with 2GB cards)
I'm confused. Didn't the previous fix solve your problems?
Rgds
--
-- Pierre
)
(host-flags SDHCI_USE_DMA)) {
- DBG(Disabling DMA as it is marked broken);
+ DBG(Disabling DMA as it is marked broken\n);
host-flags = ~SDHCI_USE_DMA;
}
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
sentiment)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
gt;
> Cc: Jens Axboe <[EMAIL PROTECTED]>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
Ouch! Well that was obviously a bug. I wonder how the hell it only explodes for
Romano. I've been shuffling loads of data using -rc1 without an incident.
Rgds
--
-- Pierre Ossman
Linux
the hell it only explodes for
Romano. I've been shuffling loads of data using -rc1 without an incident.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
On Tue, 6 Nov 2007 22:15:37 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 2 Nov 2007 06:23:48 -0700 (PDT) Alex Dubov <[EMAIL PROTECTED]>
> > wrote:
> >
> > I also wonder, where do I send the patches if nobody currently maintains
> > this thing?
> >
>
> Me, Pierre, lkml?
I'm not
On Tue, 6 Nov 2007 22:15:37 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 2 Nov 2007 06:23:48 -0700 (PDT) Alex Dubov [EMAIL PROTECTED]
wrote:
I also wonder, where do I send the patches if nobody currently maintains
this thing?
Me, Pierre, lkml?
I'm not sure sending it
On Mon, 05 Nov 2007 14:46:33 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
> > Did you partition and format this card in the camera or in Linux?
>
> In the camera. It happened both with a Kodak and a Pa
On Mon, 05 Nov 2007 14:51:45 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
> > On Mon, 05 Nov 2007 11:51:26 +0100
> > Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> Ah, I forgot: I have a dump
280 MB).
Did you partition and format this card in the camera or in Linux?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To un
in the camera or in Linux?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line unsubscribe linux
On Mon, 05 Nov 2007 14:51:45 +0100
Romano Giannetti [EMAIL PROTECTED] wrote:
On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
On Mon, 05 Nov 2007 11:51:26 +0100
Romano Giannetti [EMAIL PROTECTED] wrote:
Ah, I forgot: I have a dump of the card (made with dd). If you'd happen
On Mon, 05 Nov 2007 14:46:33 +0100
Romano Giannetti [EMAIL PROTECTED] wrote:
On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote:
Did you partition and format this card in the camera or in Linux?
In the camera. It happened both with a Kodak and a Panasonic Lumix.
Does it work
related.
>
Since there was no error from the mmc level there, I wouldn't be so sure. Could
you try a complete fsck of the card to check that the camera is constructing a
proper FAT?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core de
supported by ath5k yet, and the choice is
> between ndiswrapper or Vista.). Should I enable some debugging option
> for the MMC layer?
Not at this point no. The debugging tends to be quite noise so it easily drowns
out any temporary problems.
Rgds
--
-- Pierre Ossman
Linux kernel
ndiswrapper or Vista.). Should I enable some debugging option
for the MMC layer?
Not at this point no. The debugging tends to be quite noise so it easily drowns
out any temporary problems.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio
from the mmc level there, I wouldn't be so sure. Could
you try a complete fsck of the card to check that the camera is constructing a
proper FAT?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
's no guarantee against bugs.
(But since my code is bug free, that shouldn't be an issue. ;))
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://w
pointer
(the oops in the first dmesg).
Can you reproduce this? To help you I need to see the errors given by the MMC
layer. You should also try reproducing it without a tainted kernel (i.e. don't
load ndiswrapper).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerht
this? To help you I need to see the errors given by the MMC
layer. You should also try reproducing it without a tainted kernel (i.e. don't
load ndiswrapper).
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http
bugs.
(But since my code is bug free, that shouldn't be an issue. ;))
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
I have a whole bunch of transcend cards, and I've never gotten this
problem. Perhaps yours are rather recent?
> I have tried the fix, and it works fine. Thanks.
>
Great. I'll queue it up for -mm for some more testing, after which it will get
merged.
Rgds
--
-- Pierre Ossman
L
cards, and I've never gotten this
problem. Perhaps yours are rather recent?
I have tried the fix, and it works fine. Thanks.
Great. I'll queue it up for -mm for some more testing, after which it will get
merged.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
should go through you, not directly through Linus...
>
Indeed. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscr
| 52 +++
4 files changed, 57 insertions(+), 25 deletions(-)
David Brownell (1):
mmc_spi: Fix mmc-over-spi regression
Pierre Ossman (3):
at91_mci: Fix bad reference
mmc: fix cid and csd byte order
mmc: use common byte swap macros
On Wed, 24 Oct 2007 15:37:10 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 22 October 2007, Pierre Ossman wrote:
> >
> > I've been testing a bit more here, and I can't get this particular bug.
>
> It's not just a bug, it's a regression ... a new bug whi
for cards that mishandle the state field, and if the card
jumps to
some odd state for some reason.
>
> I am just wondering if I have set of broken cards. Any pointers
> in this regard?
>
You do. But don't be too alarmed, that is unfortunately the norm. :/
Rgds
--
for some reason.
I am just wondering if I have set of broken cards. Any pointers
in this regard?
You do. But don't be too alarmed, that is unfortunately the norm. :/
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
On Wed, 24 Oct 2007 15:37:10 -0700
David Brownell [EMAIL PROTECTED] wrote:
On Monday 22 October 2007, Pierre Ossman wrote:
I've been testing a bit more here, and I can't get this particular bug.
It's not just a bug, it's a regression ... a new bug which
was introduced by some patch
| 52 +++
4 files changed, 57 insertions(+), 25 deletions(-)
David Brownell (1):
mmc_spi: Fix mmc-over-spi regression
Pierre Ossman (3):
at91_mci: Fix bad reference
mmc: fix cid and csd byte order
mmc: use common byte swap macros
through Linus...
Indeed. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line
101 - 200 of 964 matches
Mail list logo
