either have some revealing output in dmesg or
your device nodes must be wrong somehow.
If it succeeds, then there is some problem reading the filesystem off the card.
Have you tried mounting the card in some other system?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
Midhun Agnihotram wrote:
So are the device nodes wrong? When i say `cat /proc/devices` it says :
So is the major number 254 is correct for MMC ??
This all looks correct. How about /proc/partitions? And what's in /sys/block?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC
Midhun Agnihotram wrote:
This all looks correct. How about /proc/partitions? And what's in
/sys/block?
Both of them show no sign of MMC.
Then you cannot mount them. What output did you see in dmesg when you inserted
the card?
--
-- Pierre Ossman
Linux kernel, MMC maintainer
in /proc/devices reveals the current allocation.
--
-- 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
kernel.org).
Not likely. It's probably a no-op when you don't have devfs.
You should enable CONFIG_MMC_DEBUG to see what is going wrong.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop
modifications. So I would suggest contacting them or
trying to get a vanilla kernel running.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
use busybox I
assume the system is too lightweight to run udev.
--
-- 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 thi
the system is too lightweight to run udev.
--
-- 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
(-)
Pierre Ossman (1):
mmc: get back read-only switch function
Ragner Magalhaes (1):
mmc-omap: fix sd response type 6 vs. 1
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 41bfb5d..918477c 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -427,6 +427,21
(-)
Pierre Ossman (1):
mmc: get back read-only switch function
Ragner Magalhaes (1):
mmc-omap: fix sd response type 6 vs. 1
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 41bfb5d..918477c 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -427,6 +427,21
changed, 24 insertions(+), 10 deletions(-)
Marc Pignat (1):
mmc-atmel: remove linux/mmc/protocol.h dependencies
Pierre Ossman (2):
mmc: fix broken if clause
mmc: don't call switch on old cards
Robert P. J. Day (1):
au1xmmc: Replace C code with call to ARRAY_SIZE() macro
changed, 24 insertions(+), 10 deletions(-)
Marc Pignat (1):
mmc-atmel: remove linux/mmc/protocol.h dependencies
Pierre Ossman (2):
mmc: fix broken if clause
mmc: don't call switch on old cards
Robert P. J. Day (1):
au1xmmc: Replace C code with call to ARRAY_SIZE() macro
tion:
> - core.h: mmc_schedule_work()
> - proper prototypes for three functions from core.c in core.h
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
Thanks, applied.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core d
have any other
linux based platforms to test the card in?
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 thi
platforms to test the card in?
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
: mmc_schedule_work()
- proper prototypes for three functions from core.c in core.h
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Thanks, applied.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop
version 1 but I found nothing useful... someone has a similar problem
> or can suggest to me where I can find such specifications?
>
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 t
... someone has a similar problem
or can suggest to me where I can find such specifications?
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?
--
-- Pierre Ossman
Andrew Morton wrote:
> Could we have an update for Documentation/kernel-parameters.txt, please?
>
Sorry, of course.
New patch included. "rootwait" is also just a boolean, so make sure it
is treated as such.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC mainta
Andrew Morton wrote:
Could we have an update for Documentation/kernel-parameters.txt, please?
Sorry, of course.
New patch included. rootwait is also just a boolean, so make sure it
is treated as such.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
Andrew Morton wrote:
> On Thu, 31 May 2007 13:20:48 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>> What was the verdict here? Were you satisfied with this or do you need a
>> change?
>>
>
>
> I was kinda hoing to see version #2 with that funny l
What was the verdict here? Were you satisfied with this or do you need a change?
Pierre Ossman wrote:
> Andrew Morton wrote:
>> Whatever. I think you can work it out ;)
>>
>>
>
> Bare with me, I just woke up ;)
>
>> while (driver_probe_done() ||
What was the verdict here? Were you satisfied with this or do you need a change?
Pierre Ossman wrote:
Andrew Morton wrote:
Whatever. I think you can work it out ;)
Bare with me, I just woke up ;)
while (driver_probe_done() || (ROOT_DEV = name_to_dev_t(...)) == 0)
perhaps
Andrew Morton wrote:
On Thu, 31 May 2007 13:20:48 +0200 Pierre Ossman [EMAIL PROTECTED] wrote:
What was the verdict here? Were you satisfied with this or do you need a
change?
I was kinda hoing to see version #2 with that funny loop cleaned up a bit?
New patch
?
>
I'd say a matter of taste. I'm not a big fan och cramming things into
the while() clause.
The idea with the double loops was to keep this thread asleep when we
could detect meaningful work elsewhere in the kernel. You could just
remove the inner-most loop if it offends you. :)
Rgds
--
Andrew Morton wrote:
> On Thu, 24 May 2007 14:21:35 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>
>> +/* wait for any asynchronous scanning to complete */
>> +if ((ROOT_DEV == 0) && root_wait) {
>> +print
Olaf Hering wrote:
> On Thu, May 24, Pierre Ossman wrote:
>
>
>> init: wait for asynchronously scanned block devices
>>
>
> init/do_mounts.c:242:__setup("rootdelay=", root_delay_setup);
>
> Why does that not work for you and how does your patch
= to actually show up.
If the device never shows up than we will hang in an infinite loop.
In order to not mess with setups that reboot on panic, the feature
must be turned on via the command line option "rootwait".
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
--
-- Pierre Ossman
= to actually show up.
If the device never shows up than we will hang in an infinite loop.
In order to not mess with setups that reboot on panic, the feature
must be turned on via the command line option rootwait.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
--
-- Pierre Ossman
Linux kernel, MMC
Olaf Hering wrote:
On Thu, May 24, Pierre Ossman wrote:
init: wait for asynchronously scanned block devices
init/do_mounts.c:242:__setup(rootdelay=, root_delay_setup);
Why does that not work for you and how does your patch fix it?
The problem isn't really mine, I just got
Andrew Morton wrote:
On Thu, 24 May 2007 14:21:35 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
+/* wait for any asynchronous scanning to complete */
+if ((ROOT_DEV == 0) root_wait) {
+printk(KERN_INFO Waiting for root device %s...\n
not a big fan och cramming things into
the while() clause.
The idea with the double loops was to keep this thread asleep when we
could detect meaningful work elsewhere in the kernel. You could just
remove the inner-most loop if it offends you. :)
Rgds
--
-- Pierre Ossman
Linux kernel
---
drivers/mmc/card/queue.h |8
4 files changed, 37 insertions(+), 53 deletions(-)
Pavel Pisa (1):
mmc: add maintainer for iMX MMC interface
Pierre Ossman (2):
mmc: clean up unused parts of block driver
mmc: mark unmaintained drivers
Russell
---
drivers/mmc/card/queue.h |8
4 files changed, 37 insertions(+), 53 deletions(-)
Pavel Pisa (1):
mmc: add maintainer for iMX MMC interface
Pierre Ossman (2):
mmc: clean up unused parts of block driver
mmc: mark unmaintained drivers
Russell
ay, groups are what you want and need, please use them and then you
> don't have to worry about triggering an event later after you have
> created your files on your own.
>
I take it I can supply an array of groups somewhere?
--
-- Pierre Ossman
Linux kernel, MMC maintainer
ray of device
attributes (i.e. I want wrappers).
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
, please use them and then you
don't have to worry about triggering an event later after you have
created your files on your own.
I take it I can supply an array of groups somewhere?
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core
--
-- 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
having dynamic names). I do want to have the ability to add attributes
in different parts of the code though since it allows me to group the
sysfs stuff closer to the function it accesses.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio,
Dmitry Torokhov wrote:
> 1. dev->uevent_suppress = 1;
> 2. device_register(dev);
> 3. device_create_file(dev, ...);
> 4. dev->uevent_suppress = 0;
> 5. kobject_uevent(>kobj, KOBJ_ADD);
>
>
Simple enough. Thanks :)
--
-- Pierre Ossman
Linux kern
Dmitry Torokhov wrote:
1. dev-uevent_suppress = 1;
2. device_register(dev);
3. device_create_file(dev, ...);
4. dev-uevent_suppress = 0;
5. kobject_uevent(dev-kobj, KOBJ_ADD);
Simple enough. Thanks :)
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
names). I do want to have the ability to add attributes
in different parts of the code though since it allows me to group the
sysfs stuff closer to the function it accesses.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
Russell King wrote:
> On Mon, May 14, 2007 at 09:38:49PM +0200, Pierre Ossman wrote:
>> I've reached the point where I've grown tired of trying to figure out
>> who has hardware for what. I intend to commit the following in a few
>> days so if you care about the quality of
this would, from my point of view,
be the sane method:
1. Add hidden object.
2. Add attributes.
3. Show object.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
this would, from my point of view,
be the sane method:
1. Add hidden object.
2. Add attributes.
3. Show object.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
Russell King wrote:
On Mon, May 14, 2007 at 09:38:49PM +0200, Pierre Ossman wrote:
I've reached the point where I've grown tired of trying to figure out
who has hardware for what. I intend to commit the following in a few
days so if you care about the quality of the drivers it's time to step
the second version? Is that sufficient or is a timeout a
must in your book?
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
? Is that sufficient or is a timeout a
must in your book?
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
) I did some
> testing locally by masking out the interrupt events and 3
> seconds seems usable enough to me.
>
> Signed-off-by: Philip Langdale <[EMAIL PROTECTED]>
>
>
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, cor
seconds seems usable enough to me.
Signed-off-by: Philip Langdale [EMAIL PROTECTED]
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http
Syed Mohammed, Khasim wrote:
> Hi Pierre,
>
> Carlos Aguiar and Anderson Briglia are interested in making sure the driver
> works for existing boards as they have access to them, and I can make it work
> for new omaps (2430, 3430).
>
Great. I'll update my info.
--
ck a MOTOROLA
in the front.
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
? Would you suggest change in driver name
to MOTOROLA I.MX MMCI DRIVER ?
I'll included it in my end.
As for the name, I think it's easier for people to find stuff if the vendor name
is included. I'll take your name (which is more detailed) and stick a MOTOROLA
in the front.
Rgds
--
-- Pierre
Syed Mohammed, Khasim wrote:
Hi Pierre,
Carlos Aguiar and Anderson Briglia are interested in making sure the driver
works for existing boards as they have access to them, and I can make it work
for new omaps (2430, 3430).
Great. I'll update my info.
--
-- Pierre Ossman
Linux
that has been
involved in the drivers in one way or another in case one or two maintainers can
actually be found.
Even if you don't feel like maintaining this, feel free to suggest mailing lists
that should be added to the entries.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer
++
drivers/mmc/host/sdhci.c |9 +
include/linux/major.h |2 ++
5 files changed, 35 insertions(+), 46 deletions(-)
Nicolas Pitre (1):
pxamci: fix PXA27x MMC workaround for bad CRC with 136 bit response
Pierre Ossman (2):
sdhci: handle dma
New suggestion.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit bb8c44ee8b4d584295add58a4ea2f03b9938fc3c
Author: Pierre Ossman
Al Viro wrote:
> On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
>
> First of all, please do not put patches in attachments.
>
>
My mailer tends to fsck them up if I just paste them. And it's attached
without any base64 silliness, so most people can usually r
Testing and/or comments welcome.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 7c542a5a027caa95bb00f8a8223c7e4aef88c931
Author
I_QUIRK_NO_CARD_DETECT_INT) {
> + host->detect_timer.expires = jiffies + 3 * HZ;
> + add_timer(>detect_timer);
> + }
> }
>
> static void sdhci_tasklet_finish(unsigned long param)
>
I wonder if three seconds is a bit much. You might give up and yank the
card
oping I could get some fix for at91
aswell, but that doesn't seem to be happening so I'll push in a bit.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rd
to be happening so I'll push in a bit.
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
-detect_timer);
+ }
}
static void sdhci_tasklet_finish(unsigned long param)
I wonder if three seconds is a bit much. You might give up and yank the
card in that time.
Keep up the good work. :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
Testing and/or comments welcome.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 7c542a5a027caa95bb00f8a8223c7e4aef88c931
Author
Al Viro wrote:
On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
First of all, please do not put patches in attachments.
My mailer tends to fsck them up if I just paste them. And it's attached
without any base64 silliness, so most people can usually read it directly
New suggestion.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit bb8c44ee8b4d584295add58a4ea2f03b9938fc3c
Author: Pierre Ossman
++
drivers/mmc/host/sdhci.c |9 +
include/linux/major.h |2 ++
5 files changed, 35 insertions(+), 46 deletions(-)
Nicolas Pitre (1):
pxamci: fix PXA27x MMC workaround for bad CRC with 136 bit response
Pierre Ossman (2):
sdhci: handle dma
that has been
involved in the drivers in one way or another in case one or two maintainers can
actually be found.
Even if you don't feel like maintaining this, feel free to suggest mailing lists
that should be added to the entries.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer
Nicolas Pitre wrote:
> ... and make it depend on the response flag instead of the command type.
>
> Signed-off-by: Nicolas Pitre <[EMAIL PROTECTED]>
> ---
>
Fantastic. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.o
Haavard Skinnemoen wrote:
> On Sun, 13 May 2007 15:34:51 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
>> Does that sound like something that would work for you? From my point of view
>> it's a much cleaner solution that has the benefit of not being tied into
Haavard Skinnemoen wrote:
>
> You're right about my assumptions. Are there any existing drivers that
> break them? Are there even any usb-based controllers around? I though
> most usb-mmc controllers used the USB Mass Storage class and thus
> don't use the mmc subsystem at all.
>
Yes, but they
one of the Linux-unfriendly vendors so no hope
of getting them to cough up some info.
We could do some silly polling hack. It isn't clean, but it might get things
somewhat working at least.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio,
so no hope
of getting them to cough up some info.
We could do some silly polling hack. It isn't clean, but it might get things
somewhat working at least.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http
Haavard Skinnemoen wrote:
You're right about my assumptions. Are there any existing drivers that
break them? Are there even any usb-based controllers around? I though
most usb-mmc controllers used the USB Mass Storage class and thus
don't use the mmc subsystem at all.
Yes, but they might
Haavard Skinnemoen wrote:
On Sun, 13 May 2007 15:34:51 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
Does that sound like something that would work for you? From my point of view
it's a much cleaner solution that has the benefit of not being tied into a
certain subsystem (i.e. this would fix
Nicolas Pitre wrote:
... and make it depend on the response flag instead of the command type.
Signed-off-by: Nicolas Pitre [EMAIL PROTECTED]
---
Fantastic. Applied.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
the current code even when it was compiling.
>
>
I would think that it would be better to look at just MMC_RSP_136 and
MMC_RSP_CRC in case we get future variations.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http:
.
I would think that it would be better to look at just MMC_RSP_136 and
MMC_RSP_CRC in case we get future variations.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
Haavard Skinnemoen wrote:
> On Thu, 10 May 2007 17:58:27 +0200
> Pierre Ossman <[EMAIL PROTECTED]> wrote:
>
> Is there any way this can happen? Host controller drivers register
> themselves from module_init(), their probe() function gets called,
> which calls mmc_add
Haavard Skinnemoen wrote:
>
> Ok, is there any better way to achieve the same this? As far as I
> can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
> same purpose -- it ensures that scans that have already been started
> will have completed before the function continues.
>
Not
Hi Nicolas,
You seem to be the source of this workaround, and also the maintainer of
PXA. So I guess this falls into your lap either way. Highlights from my
discussion with Russell:
Pierre Ossman wrote:
> Russell King wrote:
>
>> > Dug out from the ARM kautobuild...
>> &g
Haavard Skinnemoen wrote:
>
> What exactly makes this unreliable? This is done almost exactly the
> same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
>
I am not against the function of waiting for an initial scan, what I oppose is
using side effects to achieve that function. I do not want
Haavard Skinnemoen wrote:
> At some point before 2.6.20, the mmc subsystem moved the card
> detection code to its own workqueue. One consequence of this change
> is that when using an mmc card as a root device, the card may get
> detected after the init task attempts to mount the root filesystem,
Haavard Skinnemoen wrote:
At some point before 2.6.20, the mmc subsystem moved the card
detection code to its own workqueue. One consequence of this change
is that when using an mmc card as a root device, the card may get
detected after the init task attempts to mount the root filesystem,
Haavard Skinnemoen wrote:
What exactly makes this unreliable? This is done almost exactly the
same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
I am not against the function of waiting for an initial scan, what I oppose is
using side effects to achieve that function. I do not want to
Hi Nicolas,
You seem to be the source of this workaround, and also the maintainer of
PXA. So I guess this falls into your lap either way. Highlights from my
discussion with Russell:
Pierre Ossman wrote:
Russell King wrote:
Dug out from the ARM kautobuild...
drivers/mmc/host/pxamci.c
Haavard Skinnemoen wrote:
Ok, is there any better way to achieve the same this? As far as I
can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
same purpose -- it ensures that scans that have already been started
will have completed before the function continues.
Not
Haavard Skinnemoen wrote:
On Thu, 10 May 2007 17:58:27 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
Is there any way this can happen? Host controller drivers register
themselves from module_init(), their probe() function gets called,
which calls mmc_add_host(), which schedules the initial
e response flag, not the opcode.
Do you have hardware so that you can test such a change?
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To u
in
> this function)
>
>
What are opcode defines doing in the driver?
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To
an
atomic_t with a barrier would be sufficient. But barriers are mostly
voodoo that few people understand ;)
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer
s begun. At
this point it is invalid to call mmc_detect_change() (the place this
patch fixes). So the spinlocks are mostly there so that things are
properly ordered when we go SMP. Some creative barriers would probably
work as well, but I find spinlocks more "normal" and hence more reada
any race when it comes to modifying
host->removed. We had some problems where controllers reported card
insertion events even after they'd signaled to be removed, causing all
kind of odd problems. This check was added to easier spot it should it
arise again.
Rgds
--
-- Pierre Ossman
Linux k
Pierre Ossman wrote:
> Linus, please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
>
fsck! I pushed the wrong branch :/
This fix should have been in the last commit.
Sorry,
--
-- Pierre Ossman
Linux kernel, MMC maintainer
Pierre Ossman wrote:
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
fsck! I pushed the wrong branch :/
This fix should have been in the last commit.
Sorry,
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp
events even after they'd signaled to be removed, causing all
kind of odd problems. This check was added to easier spot it should it
arise again.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
mmc_detect_change() (the place this
patch fixes). So the spinlocks are mostly there so that things are
properly ordered when we go SMP. Some creative barriers would probably
work as well, but I find spinlocks more normal and hence more readable.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC
with a barrier would be sufficient. But barriers are mostly
voodoo that few people understand ;)
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
defines doing in the driver?
--
-- 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
, not the opcode.
Do you have hardware so that you can test such a change?
--
-- 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
401 - 500 of 964 matches
Mail list logo
