[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: drivers/mmc/sdhci.c | 40 drivers/mmc/tifm_sd.c | 11 --- drivers/mmc/wbsd.c|6 +- 3 files changed, 17 insertions(+), 40 deletions(-) Alex Dubov (1): tifm_sd: treat "status error" as normal command completion Pierre Ossman (4): mmc: wbsd: Remove driver version mmc: sdhci: Remove driver version mmc: sdhci: Stop asking for mail mmc: wbsd: Remove stray kunmap_atomic() -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > > I've tested both with and without CONFIG_SYSFS_DEPRECATED on, both fail > the same way. > hald reports that the device has no parent and decides to ignore it. > Works fine here. The device tree is: /sys/devices/pnp0/00:02/mmc0/mmc0:0001/block:mmcblk0/mmcblk0p1/ and hal correctly shows the same structure. > I've also tested both combinations against hal from ubuntu 6.06LTS and a > more recent version > > [EMAIL PROTECTED]:~$ hald --version > HAL package version: 0.5.8.1 > I'm using 0.5.9 here, but CONFIG_SYSFS_DEPRECATED should make it work with any ancient version of hal. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > > [EMAIL PROTECTED]:/$ find sys/devices | grep mmc > sys/devices/pci:00/:00:1e.0/:06:05.3/tifm_sd0:3/mmc_host:mmc0 > This is strange. You should be getting more entries below that. > /sys/block/mmcblk0/device Where does this point? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > It just occurred to me that my synopsis of the problem was utterly lame. > Here, the correct description: > When the card is pulled out, I mark the host as "ejected" (so it fast-fails > all the requests), > sleep a little for it to relax and then call mmc_remove_host. Otherwise, > nasty things happen. > Here's the example not involving mmc_block at all (command 3 failed, hardware > timeout was missed, > so software timeout picked it up; the sleep hack is disabled): > I believe your problem is line 915 of tifm_sd.c: > tifm_set_drvdata(sock, NULL); You call that before mmc_free_host() (which flushes the work queue), and I assume something still needs it. Put in some BUG_ON() here and there and you should be able to catch it. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > [EMAIL PROTECTED]:/sys/block/mmcblk0$ ls -laR > .: > total 0 > drwxr-xr-x 6 root root0 2007-02-11 23:29 . > drwxr-xr-x 13 root root0 2007-02-11 23:27 .. > -r--r--r-- 1 root root 4096 2007-02-11 23:28 dev > lrwxrwxrwx 1 root root0 2007-02-11 23:27 device -> > ../../class/mmc_host/mmc0/mmc0:b368 Is this with CONFIG_SYSFS_DEPRECATED off? It should be pointing to the ../../devices tree. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails,
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it.
> Only then, mmc_block
> remembers to finish its business. If I leave the sleep in place, mmc_block's
> stuff will get
> scheduled before the mmc_remove_host and everything will be all right.
> You may also notice that host is already powered off ("Setting ... power 0"
> message) and still
> mmc_block continues to make requests like nothing happened.
>
How did you do the "after remove" detection? Patch?
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: > I still consider this driver experimental, but without documentation this is > probably not going to change anytime soon. > The question is now what I should do with the driver? > Is it worth to be included in the kernel? If yes where and against what > kernelversion should I send the patch? > > That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. Patches should always be sent against the current version of the kernel (i.e. git HEAD). Usually the latest packaged release will also do. (Note that I haven't had time to review your latest version of the driver) 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 mmc: problem with highspeed SD card
Eugene Ilkov wrote: > I have I/O errors with Transcend SD highspeed card 2GB/150x when it's > mounted in r/w mode (cardreader on sharp sl-c1000) > It works well if I reverse mmcv4 patch commited to 2.6.19-git2 > (http://lkml.org/lkml/2006/10/4/27) That patch is not the same as you are referencing in the rest of your mail. > I'm not experienced in mmc, but I figured out that problem is > somewhere in mmc_read_switch_caps() and when i change cmd.arg value > from 0x80F1 to 0x00F1 it works fine too > What argument should have SD_SWITCH opcode? > The argument is correct, so I'm guessing that your controller might be a bit flaky and not handle the new timing. Can you enable MMC_DEBUG and send over the dmesg? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 mmc: problem with highspeed SD card
Eugene Ilkov wrote: > > I found another related patch > http://mailman.laptop.org/pipermail/commits-kernel/2007-January/000554.html > > so i guess i'm not alone > You'd better pray that's not the problem you have because that revert was because the hardware under development had problems. > > mmc debug output is too noisy > and i can give you only this: > That dump doesn't cover the problem, so I can't draw any conclusions from it. > i boot into root fs on SD, and it just hangs on remounting to rw, so > it's not easy to get full dmesg output with i/o error and mmc debug > info, but i'll try if it helps I'm afraid I can't help you without a dmesg dump. This problem is most likely crappy hardware at some point, and I need details to make any guess about what it doesn't like. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 mmc: problem with highspeed SD card
Eugene Ilkov wrote:
> PXAMCI: irq 0004 stat 2140
Hang on. PXAMCI is a MMC controller, right? Perhaps the MMC timings
aren't overlapping properly with the new stuff... I'm going to have to
recheck my diagrams.
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 mmc: problem with highspeed SD card
Pierre Ossman wrote: > Eugene Ilkov wrote: >> PXAMCI: irq 0004 stat 2140 > > Hang on. PXAMCI is a MMC controller, right? Perhaps the MMC timings > aren't overlapping properly with the new stuff... I'm going to have to > recheck my diagrams. Hmm... depending on where you look, you get different timing schematics. The MMCA 4.2 specification (which should be authoritative) does indicate that things are incompatible though. I'll put together a patch that you can try out. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > If we are already on the topic, I would like to report two additional issues > with mmc_block: > > 1. If, for some reason, device driver cannot return the requested data > amount, but does not sets > any error, mmc_block would retry indefinitely. Of course, its always a device > driver's fault, but > may be we can set some limit on retry count (this can help a lot with > debugging). Well, we could add a check that data requests get fully satisfied. > > And the more serious: > 2. There was a write corruption problem with tifm_sd caused by missing wait > cycle (card busy/card > not busy) after stop command. It should not had been a problem (the mmc layer > was spinning around > with CMD13 untill the card become not-busy), but for some reason it was. We > are currently testing > this. The intersting part, however, is behavior of mmc_block given this > situation: > > It appears that mmc_block's instance manages to get stuck because of this. > The symptoms: module > usage count is not decremented when low level driver is unloaded and > partition block devices do > not get created afterwards. The fun part: the main block device gets created > and deleted on card > insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet > partition detection does > not happens. To fix this, one have to reboot the machine or to wait about 30 > minutes for mmc_block > to regain its senses (then it becomes rmmod'able again). > > On the other hand, it may be some sort of generic block layer problem. > The block layer can get a bit fuzzy when you start yanking device out from under it. That said, the mmc block driver should be forgiving. So if you can figure out what it is up to (and more exactly how it is provoked), I'll try to fix it. -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] incorrect behavior on resume
Alex Dubov wrote: > And today: yet another problem with mmc. > It so happens that after resume mmc layer issues requests to the device > before mmc_resume_host is > called at all. Moreover, this prevents the machine from resuming, unless > worked around, because > software timer does not work at this stage of the resume and interrupts may > not be delivered (if > card was removed, for example). Now this sounds incredibly broken. A child device should never be resumed before its parent. Pavel, can you comment? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails,
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it.
> Only then, mmc_block
> remembers to finish its business. If I leave the sleep in place, mmc_block's
> stuff will get
> scheduled before the mmc_remove_host and everything will be all right.
> You may also notice that host is already powered off ("Setting ... power 0"
> message) and still
> mmc_block continues to make requests like nothing happened.
>
I don't actually think that is what happening. The block errors tend to trail a
bit behind, so the errors you are seeing are probably the result of the queue
being flushed out as you remove the card. I don't see any mmc debug messages
that indicate that is trying to send more mmc requests.
You could add a printk to the queue thread in mmc_queue.c. That will allow you
to see exactly when it exits (which should be before mmc_remove_host() returns).
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: >> I don't actually think that is what happening. The block errors tend to >> trail a >> bit behind, so the errors you are seeing are probably the result of the queue >> being flushed out as you remove the card. I don't see any mmc debug messages >> that indicate that is trying to send more mmc requests. > > Yes, indeed - it does not issue new requests after remove. However, > mmc_remove_host does not wait > for all issued requests to complete and it is a problem. I don't see how that is possible. mmc_block's remove routine waits for mmcqd to exit, so there can't be any code still alive that has a request going. (I am also completely unable to reproduce this problem here). Add more printk:s do verify how the code in mmc_block executes. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > This is hard to trigger problem, so I'll spare you the rather lengthy log. > It happens if card timeouts and mmc_remove_host is called while > mmc_register_card is still in > progress (the hint was in crash dump). If I sleep before remove, it gives the > mmc_register_card > chance to finish/mark card as dead and everything's fine. > The remove callback of mmc_block is apparently not executed in this case > (probably because device > has not finished registering). Let's see, you manage to call mmc_remove_host() when a detection is pending in the workqueue? That could indeed generate new request (up until mmc_free_host() is called), but as the card is removed the mmc layer shouldn't be able to detect anything, hence mmc_block should never get involved. > > My proposition: lets flush the workqueue first thing in the mmc_remove_host > (and make sure that > nothing gets scheduled into it after this). > This is fixed in -mm. Making sure that nothing gets scheduled is the driver's responsibility. I've added checks to catch broken drivers 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 linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of > requests (reads partition > table, fs superblocks and such - plenty of room for critical errors). Then, > driver's remove method > will not be called before driver's probe method had finished. So mmc_block is > quite involved, even > though it does not affect the problem's resolution. I agree that mmc_block's probe method will generate a whole bunch of requests. But I don't see how that can be called given the scenario you describe. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Sorry this took so long but I got occupied with other things and this
had to move down the pile a bit.
New patch which uses dedicated buffers for the currently active packet.
Also adds a new state RQ_ABANDONED which basically means "the caller no
longer cares about this request so the pointers are no longer valid". It
is used to determine if the global receive buffer should be copied to
the provided one upon completion.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 166fb223f9507431fb97820549e3e41980987445
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon Feb 19 11:34:43 2007 +0100
ncpfs: make sure server connection survives a kill
Use internal buffers instead of the ones supplied by the caller
so that a caller can be interrupted without having to abort the
entire ncp connection.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
diff --git a/fs/ncpfs/inode.c b/fs/ncpfs/inode.c
index 14939dd..7285c94 100644
--- a/fs/ncpfs/inode.c
+++ b/fs/ncpfs/inode.c
@@ -576,6 +576,12 @@ static int ncp_fill_super(struct super_block *sb, void *raw_data, int silent)
server->packet = vmalloc(NCP_PACKET_SIZE);
if (server->packet == NULL)
goto out_nls;
+ server->txbuf = vmalloc(NCP_PACKET_SIZE);
+ if (server->txbuf == NULL)
+ goto out_packet;
+ server->rxbuf = vmalloc(NCP_PACKET_SIZE);
+ if (server->rxbuf == NULL)
+ goto out_txbuf;
sock->sk->sk_data_ready = ncp_tcp_data_ready;
sock->sk->sk_error_report = ncp_tcp_error_report;
@@ -597,7 +603,7 @@ static int ncp_fill_super(struct super_block *sb, void *raw_data, int silent)
error = ncp_connect(server);
ncp_unlock_server(server);
if (error < 0)
- goto out_packet;
+ goto out_rxbuf;
DPRINTK("ncp_fill_super: NCP_SBP(sb) = %x\n", (int) NCP_SBP(sb));
error = -EMSGSIZE; /* -EREMOTESIDEINCOMPATIBLE */
@@ -666,8 +672,12 @@ out_disconnect:
ncp_lock_server(server);
ncp_disconnect(server);
ncp_unlock_server(server);
-out_packet:
+out_rxbuf:
ncp_stop_tasks(server);
+ vfree(server->rxbuf);
+out_txbuf:
+ vfree(server->txbuf);
+out_packet:
vfree(server->packet);
out_nls:
#ifdef CONFIG_NCPFS_NLS
@@ -723,6 +733,8 @@ static void ncp_put_super(struct super_block *sb)
kfree(server->priv.data);
kfree(server->auth.object_name);
+ vfree(server->rxbuf);
+ vfree(server->txbuf);
vfree(server->packet);
sb->s_fs_info = NULL;
kfree(server);
diff --git a/fs/ncpfs/sock.c b/fs/ncpfs/sock.c
index e496d8b..e37df8d 100644
--- a/fs/ncpfs/sock.c
+++ b/fs/ncpfs/sock.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -55,10 +56,11 @@ static int _send(struct socket *sock, const void *buff, int len)
struct ncp_request_reply {
struct list_head req;
wait_queue_head_t wq;
- struct ncp_reply_header* reply_buf;
+ atomic_t refs;
+ unsigned char* reply_buf;
size_t datalen;
int result;
- enum { RQ_DONE, RQ_INPROGRESS, RQ_QUEUED, RQ_IDLE } status;
+ enum { RQ_DONE, RQ_INPROGRESS, RQ_QUEUED, RQ_IDLE, RQ_ABANDONED } status;
struct kvec* tx_ciov;
size_t tx_totallen;
size_t tx_iovlen;
@@ -67,6 +69,32 @@ struct ncp_request_reply {
u_int32_t sign[6];
};
+static inline struct ncp_request_reply* ncp_alloc_req(void)
+{
+ struct ncp_request_reply *req;
+
+ req = kmalloc(sizeof(struct ncp_request_reply), GFP_KERNEL);
+ if (!req)
+ return NULL;
+
+ init_waitqueue_head(&req->wq);
+ atomic_set(&req->refs, (1));
+ req->status = RQ_IDLE;
+
+ return req;
+}
+
+static void ncp_req_get(struct ncp_request_reply *req)
+{
+ atomic_inc(&req->refs);
+}
+
+static void ncp_req_put(struct ncp_request_reply *req)
+{
+ if (atomic_dec_and_test(&req->refs))
+ kfree(req);
+}
+
void ncp_tcp_data_ready(struct sock *sk, int len)
{
struct ncp_server *server = sk->sk_user_data;
@@ -101,14 +129,17 @@ void ncpdgram_timeout_call(unsigned long v)
schedule_work(&server->timeout_tq);
}
-static inline void ncp_finish_request(struct ncp_request_reply *req, int result)
+static inline void ncp_finish_request(struct ncp_server *server, struct ncp_request_reply *req, int result)
{
req->result = result;
+ if (req->status != RQ_ABANDONED)
+ memcpy(req->reply_buf, server->rxbuf, req->datalen);
req->status = RQ_DONE;
wake_up_all(&req->wq);
+ ncp_req_put(req);
}
-static void __abort_ncp_connection(struct ncp_server *server, struct ncp_request_reply *aborted, int err)
+static void __abort_ncp_connection(struct ncp_server *server)
{
struct ncp_request_reply *req;
@@ -118,31 +149,19 @@ static void __abort_ncp_connection(struct ncp_server *server, struct ncp_request
req = list_entry(server->tx.requests.next, struct ncp_request_reply, req);
list_del_init(&
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > mmc_rescan > mmc_register_card > device_add > mmc_block_probe > mmc_block_alloc > -> queue thread starts running > add_disk > -> issues a lot of requests; card fails, my drivers calls > mmc_remove_host, which in > turn calls device_del, though we are still in device_add > Ahhh, now I see. Well that's an entirely different kettle of fish. Removing the device in this stack is not supported (we would have a whole bunch of nasty dead lock possibilities to consider). You need to delay the removal in some form, e.g. using the mmc workqueue. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Racy NLS behaviour in FAT (and possible other fs)
Hi, I'm experiencing a rather odd behaviour with the character set conversion. If I mount a vfat fs with utf8 and then create a file with invalid utf-8 sequences, the file will briefly exist with these invalid sequences, then quickly convert to a stripped version. I haven't found an easy way to catch the race, but if I have nautilus open it tends to catch it now and then (I get a file name with "" replacing each bad byte). The race also seems to corrupt the in-memory state of the fs now and then. I managed to create a file where "ls" shows "?" for most fields. Data seemed to have made it to disk ok though (fsck didn't complain and a remount showed everything as it should be). Third, there seems to be a problem with not all syscalls being subjected to the NLS transformation. Example: $ echo foo > baråäö.txt $ ls foo.txt $ echo foo > baråäö.txt bash: baråäö.txt: File exists 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Racy NLS behaviour in FAT (and possible other fs)
OGAWA Hirofumi wrote: >> I'm experiencing a rather odd behaviour with the character set >> conversion. If I mount a vfat fs with utf8 and then create a file >> with invalid utf-8 sequences, the file will briefly exist with these >> invalid sequences, then quickly convert to a stripped version. >> > > Yes. utf8 support is broken, and it will fail to convert letter case > on many case. And it's why that is not recommended. > > Is there any ongoing work to fix this? UTF-8 is standard on more or less every distribution these days. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Petr Vandrovec wrote: > > Hello, > it would be nice if these two copies (request->txbuf, and > rxbuf->reply) could be eliminated, but I see no easy way how to do > that... > At least we have the basic functionality now. One can start looking at optimising it after that. > > Acked-by: Petr Vandrovec <[EMAIL PROTECTED]> I'll send it on to Linus then. > > Looks like a typo? requres => request ? > Ooops. I'll fix that. :) 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Racy NLS behaviour in FAT (and possible other fs)
OGAWA Hirofumi wrote: > Yes. But sorry, I don't have any plan and time to fix it now. > I know the feeling. :) I just wanted to know where things stand as I have little insight into vfat development. > If you are using "iocharset=utf8" now, "codepage=cp???,iocharset=xxx,utf8" > might help a bit. > These tests was with the "utf8" option. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] drivers/mmc/Kconfig source drivers/mmc/card/Kconfig
Adrian Bunk wrote: > On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote: >> ... >> Changes since 2.6.20-mm1: >> ... >> git-mmc.patch >> ... >> git trees >> ... > > > The MMC_BLOCK option was accidentally lost. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Thanks. I wonder how that happened. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent and not-so problems with tifm_sd driver
Alex Dubov wrote: > > correction: my driver schedules (wakes kthread in 0.7) mmc_remove_host - > noticed it only now > Ok, good. Then things are as they should on your part. > > That's why I think that simply flushing the workqueue is enough. If workqueue > is empty we know for > sure that device_add has exited. > >From -mm: http://www.kernel.org/git/?p=linux/kernel/git/drzeus/mmc.git;a=commitdiff;h=e89bac488861ebadfca3a74321af19a262dcbd08 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ncpfs and TCP vs UDP
Hi Petr,
I was hoping you could give me some input on another concern I have.
Which of TCP and UDP is the preferred transport for NCP? The client for
Windows seems to use TCP, which would suggest that that is the most
tested dialect. I also did a quick test with bonnie++:
UDP:
Version 1.03 -Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
500M 1569 19 1714 10 826 9 1414 18 1569 9 65.2 3
--Sequential Create-- Random Create
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 460 14 897 16 556 15 491 15 1131 13 320 6
poseidon.drzeus.cx,500M,1569,19,1714,10,826,9,1414,18,1569,9,65.2,3,16,460,14,897,16,556,15,491,15,1131,13,320,6
TCP:
Version 1.03 -Sequential Output-- --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
500M 1653 19 3711 11 2312 9 1419 18 4489 6 91.5 1
--Sequential Create-- Random Create
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 483 14 912 15 587 14 483 14 1176 13 287 6
poseidon.drzeus.cx,500M,1653,19,3711,11,2312,9,1419,18,4489,6,91.5,1,16,483,14,912,15,587,14,483,14,1176,13,287,6
TCP has roughly twice the throughput of UDP. Note that this was done
against a vmware machine that wasn't exactly maxing out the network.
Input welcome.
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 4/5: Updates to SPI and mmc_spi: mmc_spi updated, kernel 2.6.19
Hans-Peter Nilsson wrote: > > Future improvements: > A rewrite. Not only for the new MMC framework (I haven't looked > at it so I don't know what's involved) but also because this > code seems a little too, um, experimental to fit my taste. > Functions go behind each other's back and look at and change > data; they seem to "fix up" the result of each others work. > It doesn't help maintenance. > Right, this isn't getting merged anywhere near its current state. It should be implemented as a host driver and we'll modify the mmc core where needed to cover the differences when doing spi. As for my "new framework", it's mostly reorganising the stuff already there. But any patches will have to be reworked after that change. So I'd suggest holding off on this for a while. > Support SDIO and SDHC. SDIO fails over already when mmc_spi > sees CMD5 and reports that it's invalid. This is mostly about > mapping commands and reply-types, but also support for the SDIO > interrupt line. Ok, I guess this can't be properly defined > before the SDIO and SDHC support at the MMC layer is clear. :) > The response type problem is exactly the kind of problem that should be solved by moving spi support into the mmc core. > Better API. The card-detect API should *at least optionally* be > like the get_ro function. I think this is so uncommon and involves so little code that it just adds complexity to abstract it up to the core. Most hw get interrupts for insertion/removal. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: au1xmmc: return errors for unknown response types
Manuel Lauss wrote:
> au1xmmc: return error when encountering unhandled/unknown response type.
>
> Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]>
>
Thanks, applied.
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: au1xmmc: implement proper ro switch detection
Manuel Lauss wrote:
> au1xmmc: implement proper R/O switch detection.
>
> Signed-off-by: Manuel Lauss <[EMAIL PROTECTED]>
>
Also applied.
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc2] Add a quirk to allow ENE PCI SD card readers to work again
Darren Salt wrote:
> Add a quirk to allow ENE PCI SD card readers to work again
>
Ok, I think we can consider testing over. I will apply this upstream
with the original host mask (as we didn't get any reports of it helping
on other ene controllers).
Thanks again for doing the legwork on this.
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ncpfs and TCP vs UDP
Jan Engelhardt wrote:
> Well, probably the same reason as NFS over UDP is discouraged. See nfs(5)
> section WARNINGS (in short: IP fragment ID can wrap quite fast on Gigabit)
>
>
I have no such warning in my nfs(5), but I am aware of this yes.
Somewhat amusing that both nfs and ncpfs tend to default to using udp
with this in mind. ;)
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff
Anderson Briglia wrote: > Hi Pierre, > > Sorry about the delay. > I changed a bit the code to align with your latest suggestions. > > Nice, but the locking is broken again. > I believe now the number of goto's is ok. > > Actually, the ones you have left are completely useless. So you can just remove the last bunch aswell. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to map high memory for block io
Russell King wrote: > Okay, I've hit this same problem (but in a slightly different way) with > mmci.c. The way I'm proposing to fix this for mmci is to introduce a > new capability which says "clustering is supported by this driver." > > I'm unconvinced that we can safely fiddle with the queue's flags once > the queue is in use, hence why I've gone for the init-time only solution. > Maybe Jens can comment on that? > > (The side effect of this patch is that everyone ends up with clustering > disabled until they explicitly update their driver to enable it - which > results in us defaulting to a safe operation mode.) > > Ok, time to warm up this old chestnut. I "solved" my immediate problem with wbsd, and this got forgotten. AFAICT, mmci.c and the rest of the lot are still broken in the sense that they use kmap but exceed page limits (which happens to work on non-highmem pages). I think the right solution is to let them use page_address() instead. Would that be correct? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm1
Andrew Morton wrote: > > A quick scan indicates that the following files might be buggy in this > regard: > > drivers/mmc/wbsd.c > drivers/mmc/sdhci.c This are probably even buggier than so. They really should be using page_address(), it seems that kmap_atomic() gives the same result when not using highmem (which they are carful to avoid). I'll put on the paper bag and whip up a patch. Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: NCPFS and brittle connections
ping! Pierre Ossman wrote: > Ok... how about this baby instead. I've replaced the stack allocated > request structure by one allocated with kmalloc() and reference counted > using an atomic_t. I couldn't see anything else that was associated to > the process, so I believe this should suffice. > > (This is just a RFC. Once I get an ok from you I'll put together a more > proper patch mail) > -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2 GB SD card problem vs. 2.6.20-rc7 (FAT: Filesystem panic (dev sdc1))
Kobajashi Zaghi wrote: > Hi Pierre! > > I have two 2GB capacity SD card (Kingston, noname). When i put either > of them to a card reader, kernel recognize, but "see" only 1GB > capacity, and when i try to access, FAT filesystem paniced. > Your device is not a MMC/SD bridge, so I'm the wrong person to contact for this. You should contact whoever is in charge of USB storage devices (which is what you've got). 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Sdhci-devel] [PATCH 2.6.20-rc2] Add a quirk to allow ENE PCI SD card readers to work again
Hi Darren,
It has come to my attention that the current routine for setting power
is not compliant with the specification. As such, I'd like you to try
the following and see if removes the need for your patch:
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index dc1b04a..13ac2fe 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -685,23 +690,21 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned short power)
if (power == (unsigned short)-1)
goto out;
- pwr = SDHCI_POWER_ON;
-
switch (power) {
case MMC_VDD_170:
case MMC_VDD_180:
case MMC_VDD_190:
- pwr |= SDHCI_POWER_180;
+ pwr = SDHCI_POWER_180;
break;
case MMC_VDD_290:
case MMC_VDD_300:
case MMC_VDD_310:
- pwr |= SDHCI_POWER_300;
+ pwr = SDHCI_POWER_300;
break;
case MMC_VDD_320:
case MMC_VDD_330:
case MMC_VDD_340:
- pwr |= SDHCI_POWER_330;
+ pwr = SDHCI_POWER_330;
break;
default:
BUG();
@@ -709,6 +712,10 @@ static void sdhci_set_power(struct sdhci_host
*host, unsigned short power)
writeb(pwr, host->ioaddr + SDHCI_POWER_CONTROL);
+ pwr |= SDHCI_POWER_ON;
+
+ writeb(pwr, host->ioaddr + SDHCI_POWER_CONTROL);
+
out:
host->power = power;
}
I'd appreciate if you could test this sooner rather than later as the
merge window is just around the corner.
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" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Sdhci-devel] [PATCH 2.6.20-rc2] Add a quirk to allow ENE PCI SD
Darren Salt wrote: > > Your patch was mangled by Thunderbird. IME, it always does this; you should > attach patches, not include them inline. > > Still, it was easy enough to apply the patch manually. > It's braindead, I was lazy and hoping it wouldn't crap things up too badly. (it usually works if the lines are short enough) >> I'd appreciate if you could test this sooner rather than later as the merge >> window is just around the corner. > > It doesn't work. > > After applying my patch and fixing up the rejects, it still doesn't work. I > need to disable the first of the writeb() calls mentioned in the last hunk of > your patch for it to work again. I have the impression that the hardware > doesn't like the power-on bit not being set :-| > Now this isn't good. It means that I have to controllers that require conflicting deviations from the standard. What a pain. > ... hmm, it looks like there's a small bug in my patch: the label "out" needs > to be before the last writeb() otherwise, if power is -1, no write will > happen regardless. I'm attaching a fixed version along with an adapted > version of your patch. > I already fixed up that before I committed it to my tree, so no sweat. ) > Pierre, if you're happy to sign off the modified version of your patch, feel > free to convert my not-yet-signed-off-by into a normal signed-off-by. > I'll rework that into a separate quirk to indicate it's because of broken hardware. It's only for unreleased hw so it's no rush. I just wanted to see if it was related to your problem. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH] Fix up needless kmap:s
Hi Alex,
I'd like you to test and comment on the following patch.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
>From c8467c6b0ea0443f948c0ece281e1ca8e92f6ea7 Mon Sep 17 00:00:00 2001
From: Pierre Ossman <[EMAIL PROTECTED]>
Date: Sat, 3 Feb 2007 13:36:41 +0100
Subject: [PATCH] mmc: tifm: replace kmap with page_address
Since we actively avoid highmem, calling kmap_atomic() instead
of page_address() is effectively only obfuscation.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
---
drivers/mmc/tifm_sd.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/tifm_sd.c b/drivers/mmc/tifm_sd.c
index 7e607b7..e65f8a0 100644
--- a/drivers/mmc/tifm_sd.c
+++ b/drivers/mmc/tifm_sd.c
@@ -107,14 +107,9 @@ struct tifm_sd {
};
-static char* tifm_sd_kmap_atomic(struct mmc_data *data)
+static char* tifm_sd_data_buffer(struct mmc_data *data)
{
- return kmap_atomic(data->sg->page, KM_BIO_SRC_IRQ) + data->sg->offset;
-}
-
-static void tifm_sd_kunmap_atomic(char *buffer, struct mmc_data *data)
-{
- kunmap_atomic(buffer - data->sg->offset, KM_BIO_SRC_IRQ);
+ return page_address(data->sg->page) + data->sg->offset;
}
static int tifm_sd_transfer_data(struct tifm_dev *sock, struct tifm_sd *host,
@@ -127,18 +122,17 @@ static int tifm_sd_transfer_data(struct tifm_dev *sock,
struct tifm_sd *host,
if (host_status & TIFM_MMCSD_BRS) {
/* in non-dma rx mode BRS fires when fifo is still not empty */
if (no_dma && (cmd->data->flags & MMC_DATA_READ)) {
- buffer = tifm_sd_kmap_atomic(host->req->data);
+ buffer = tifm_sd_data_buffer(host->req->data);
while (host->buffer_size > host->buffer_pos) {
t_val = readl(sock->addr + SOCK_MMCSD_DATA);
buffer[host->buffer_pos++] = t_val & 0xff;
buffer[host->buffer_pos++] =
(t_val >> 8) & 0xff;
}
- tifm_sd_kunmap_atomic(buffer, host->req->data);
}
return 1;
} else if (no_dma) {
- buffer = tifm_sd_kmap_atomic(host->req->data);
+ buffer = tifm_sd_data_buffer(host->req->data);
if ((cmd->data->flags & MMC_DATA_READ) &&
(host_status & TIFM_MMCSD_AF)) {
for (cnt = 0; cnt < TIFM_MMCSD_FIFO_SIZE; cnt++) {
@@ -163,7 +157,6 @@ static int tifm_sd_transfer_data(struct tifm_dev *sock,
struct tifm_sd *host,
}
}
}
- tifm_sd_kunmap_atomic(buffer, host->req->data);
}
return 0;
}
--
1.4.4.2
Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff
Anderson Briglia wrote: > Hi Pierre, > > How about now? Is better? > > Locking problem is still there. You need to unclaim the host even when claim fails. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Sdhci-devel] x60: mmc card reader problem
Pavel Machek wrote: > Hi! > > ...it wants me to report: > > > ...yes, I yanked the card when I seen "unknown partition table". > > (This is how it looks on debug console; it captured the dumps, too:) > Error 1 is timeout, which can be caused by many things. Have you tried with several cards? And is it repeatable? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_sysfs.diff
Anderson Briglia wrote: > Hi Pierre, > > ext Pierre Ossman wrote: >> Patch looks ok. But I never got an answer what the difference between >> "change" and "assign" is. > > You're right, the command is the same, but the difference is the > password's > length and password itself sent to the card. > According to MMC spec 4.1, when a password replacement is done, the > length value > (PWD_LEN) shall include both passwords, the old and the new one, and > the password > (PWD) shall include the old (currently) followed by the new password. So shouldn't this be something that userspace handles? -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_omap_dma.diff
Anderson Briglia wrote: > > This patch is needed only for lock/unlock commands. So, it's necessary to > make MMC omap works when using that feature. It's not a generic patch. > But I can take off this one from the series and send after (if) the > series > is integrated. > The patches are marked "[RFC]" which I interpret as that I shouldn't merge it. Is this incorrect? > > frame depends on data->blksz. When we were using data->blksz_bits > everything was > ok because we always had a multiple of 16 bits (2 bytes). Once a pwd > can has a size > not multiple of 2, the value must be rounded. > According to MMC OMAP Technical Reference Manual, because of each DMA > transfer is of > equal size, it is necessary to have the block size of the transfer be > a multiple of > the DMA write access size (which is 2 bytes). > This sounds very generic and not something that is specific to the password command. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_lock_unlock.diff
Anderson Briglia wrote: > ext Pierre Ossman wrote: >> >> This definition makes them look like bits, which is not how they are >> used. > > How can I improve this? Defining using integers directly? > Precisely. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MMC update
Linus Torvalds wrote: > On Fri, 1 Dec 2006, Pierre Ossman wrote: > >> git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git >> for-linus >> > > I get > > Already up-to-date. > > did you forget to push? Or is mirroring just really slow again? > > Seems mirroring is slow as hell. It's still not updated, but on master.kernel.org, head is 8b7feff881b7e9f065ddd718a6841121207c3c19. I don't suppose there's a status page somewhere that tells you what the mirroring is up to? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: fix au1xmmc build error
Yoichi Yuasa wrote:
> Hi,
>
> This patch has fixed the following build error abou au1xmmc.
>
Thanks. Applied.
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/5] [RFC] Add MMC Password Protection (lock/unlock) support V7: mmc_lock_unlock.diff
Anderson Briglia wrote: > > Actually they represent the bits regarding the modes and it is used > when we > have to send the LOCK/UNLOCK mode on the command data block, according > to the MMC Spec. > If you take a look at mmc_lock_unlock function, we use those modes to > set the right bit > when composing the command data block. > This definition makes the code more legible and simple. In that case you need to change the code to make sure it is clear that it is bits and not values. Also, your definition for MMC_LOCK_MODE_UNLOCK is wrong. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmc: pxamci compilation fix
Sascha Hauer wrote: > Hi Pierre and all, > > since commit fcaf71fd51f9cfc504455d3e19ec242e4b2073ed > struct mmc_host does not have a dev field. Retrieve the device with > mmc_dev() instead. > > Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]> > Bad Greg ;) Applied, thanks. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
to receive the following updates:
drivers/mmc/at91_mci.c | 346 +--
drivers/mmc/mmc_queue.c |4 -
drivers/mmc/sdhci.c |4 -
3 files changed, 190 insertions(+), 164 deletions(-)
Andrew Victor:
AT91 MMC 1: Pass host structure.
AT91 MMC 2 : Use platform resources
AT91 MMC 3 : Move global mci_clk variable
AT91 MMC 4 : Interrupt handler cleanup
AT91 MMC 5 : Minor cleanups
AT91 MMC update for 2.6.19
Pierre Ossman:
mmc: Change SDHCI iomem error to a warning
Vitaly Wool:
mmc: fix "prev->state: 2 != TASK_RUNNING??" problem on SD/MMC card
removal
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Add MMC Password Protection (lock/unlock) support V8
Anderson Briglia wrote: > Hi all, > > Someone has comments for these patches? > > I haven't forgotten about you, I just haven't had the time to look at the latest set yet. Perhaps tonight, but I cannot promise anything. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Add MMC Password Protection (lock/unlock) support V8: mmc_key_retention.diff
Anderson Briglia wrote: > The code was based on code presents at security/keys/user_defined.c. This is > the reason of why the MMC PWD code was > implemented using this returns types and others implementations. > That file (user_defined.c) implements generic functions to handle keys inside > the kernel, using the Kernel Key Retention > Service. Maybe you can take a look there, :). > That zap variable was used to expand the key payload when a new password > exceeded a previous configured size. But the > Kernel Key Retention Service has changed and that zap variable is not used on > key_instantiate function implemented at > user_defined.c, anymore. I'll update the MMC PWD code. > > Patches look ok, and I'll commit them once you send me this last fix. > Yes. I believe sizeof is a compiler operation and it does not access the data > pointed by that pointer, it access just > the type of the pointer. > > Yes, sizeof() is compile time and completely safe in this regard. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
to receive the following updates:
drivers/mmc/at91_mci.c | 11 +--
drivers/mmc/omap.c |6 +++---
2 files changed, 8 insertions(+), 9 deletions(-)
David Brownell (1):
MMC: at91 mmc linkage updates
Kyungmin Park (1):
ARM: OMAP: fix MMC workqueue changes
diff --git a/drivers/mmc/at91_mci.c b/drivers/mmc/at91_mci.c
index 08a33c3..aa152f3 100644
--- a/drivers/mmc/at91_mci.c
+++ b/drivers/mmc/at91_mci.c
@@ -768,7 +768,7 @@ static irqreturn_t at91_mmc_det_irq(int irq, void *_host)
return IRQ_HANDLED;
}
-int at91_mci_get_ro(struct mmc_host *mmc)
+static int at91_mci_get_ro(struct mmc_host *mmc)
{
int read_only = 0;
struct at91mci_host *host = mmc_priv(mmc);
@@ -794,7 +794,7 @@ static const struct mmc_host_ops at91_mci_ops = {
/*
* Probe for the device
*/
-static int at91_mci_probe(struct platform_device *pdev)
+static int __init at91_mci_probe(struct platform_device *pdev)
{
struct mmc_host *mmc;
struct at91mci_host *host;
@@ -910,7 +910,7 @@ static int at91_mci_probe(struct platform_device *pdev)
/*
* Remove a device
*/
-static int at91_mci_remove(struct platform_device *pdev)
+static int __exit at91_mci_remove(struct platform_device *pdev)
{
struct mmc_host *mmc = platform_get_drvdata(pdev);
struct at91mci_host *host;
@@ -972,8 +972,7 @@ static int at91_mci_resume(struct platform_device *pdev)
#endif
static struct platform_driver at91_mci_driver = {
- .probe = at91_mci_probe,
- .remove = at91_mci_remove,
+ .remove = __exit_p(at91_mci_remove),
.suspend= at91_mci_suspend,
.resume = at91_mci_resume,
.driver = {
@@ -984,7 +983,7 @@ static struct platform_driver at91_mci_driver = {
static int __init at91_mci_init(void)
{
- return platform_driver_register(&at91_mci_driver);
+ return platform_driver_probe(&at91_mci_driver, at91_mci_probe);
}
static void __exit at91_mci_exit(void)
diff --git a/drivers/mmc/omap.c b/drivers/mmc/omap.c
index 435d331..9488408 100644
--- a/drivers/mmc/omap.c
+++ b/drivers/mmc/omap.c
@@ -581,9 +581,9 @@ static void mmc_omap_switch_timer(unsigned long arg)
schedule_work(&host->switch_work);
}
-static void mmc_omap_switch_handler(void *data)
+static void mmc_omap_switch_handler(struct work_struct *work)
{
- struct mmc_omap_host *host = (struct mmc_omap_host *) data;
+ struct mmc_omap_host *host = container_of(work, struct mmc_omap_host,
switch_work);
struct mmc_card *card;
static int complained = 0;
int cards = 0, cover_open;
@@ -1116,7 +1116,7 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, host);
if (host->switch_pin >= 0) {
- INIT_WORK(&host->switch_work, mmc_omap_switch_handler, host);
+ INIT_WORK(&host->switch_work, mmc_omap_switch_handler);
init_timer(&host->switch_timer);
host->switch_timer.function = mmc_omap_switch_timer;
host->switch_timer.data = (unsigned long) host;
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Add support for SDHC cards (Take 4)
Philip Langdale wrote: > In the process of developing this patch, we realised that the R6 response > definition > was incorrect and that it should have been identical to R1 (and so should R7). > Correcting this mistake revealed problems in a couple of host controller > drivers that > relied on the response definitions to be unique. As we need a story for R7, > I've > also fixed up the R6 handling in the affected drivers but I have no idea if > it will > work in practice as I lack the hardware. > > Do this fix in a separate patch. And cc the relevant maintainers. > --- /usr/src/linux/drivers/mmc/imxmmc.c 2007-01-01 07:12:02.0 > -0800 > +++ linux-2.6.19-sdhc/drivers/mmc/imxmmc.c2007-01-04 05:50:41.0 > -0800 > @@ -351,9 +360,6 @@ > case MMC_RSP_R3: /* short */ > cmdat |= CMD_DAT_CONT_RESPONSE_FORMAT_R3; > break; > - case MMC_RSP_R6: /* short CRC */ > - cmdat |= CMD_DAT_CONT_RESPONSE_FORMAT_R6; > - break; > default: > break; > } > I think this chunk suffices. Until proven otherwise, regard R6 and R7 as information the hw does not need to know about. Same thing in tifm_sd. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Add support for SDHC cards (Take 5)
Philip Langdale wrote: > Thanks to the generous donation of an SDHC card by John Gilmore, and the > surprisingly enlightened decision by the SD Card Association to publish > useful specs, I've been able to bash out support for SDHC. The changes > are not too profound: > > Looks good. I'll queue up both patches for -mm. -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NCPFS and brittle connections
Petr Vandrovec wrote: > > Nobody is working on it (at least to my knowledge), and to me it is > feature - it always worked this way, like smbfs did back in the past - > if you send signal 9 to process using mount point, and there is some > transaction in progress, nobody can correctly finish that transaction > anymore. Fixing it would require non-trivial amount of code, and > given that NCP itself is more or less dead protocol I do not feel that > it is necessary. > Someone needs to tell our customers then so they'll stop using it. :) > If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling > in ncp_abort_request - it just aborts whole connection so it does not > have to provide temporary buffers and special handling for reply - as > buffers currently specified as reply buffers are owned by caller, so > after aborting request you cannot use them anymore. Do you have any pointers to how it was solved with smbfs? Relevant patches perhaps? Provided a similar solution can be applied here. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff
Anderson Briglia wrote: > Hi all, > > I believe this code is following the latest Russel's comments. > Afraid not. mmc_card_claim_host() is incredibly unintuitive in that it requires an unlock on error (the lock always succeeds, the card select might fail). I'll fix that up and commit the patch set. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff
I've queued it up for -mm, but there a few more comments I want resolved before this can move to Linus... You need to clean up mmc_lockable_store(). It had a few broken variable declarations that even prevented it from compiling, and after I fixed that I still get: drivers/mmc/mmc_sysfs.c: In function ‘mmc_lockable_store’: drivers/mmc/mmc_sysfs.c:160: warning: ignoring return value of ‘device_attach’, declared with attribute warn_unused_result drivers/mmc/mmc_sysfs.c:93: warning: ‘mmc_key’ may be used uninitialized in this function There's also no handling for an invalid string written to the sysfs node. And third, you're a bit excessive on the goto:s. E.g. out_unlocked is used in a single place, so it is completely unnecessary. Please do a general cleanup of the control flow. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.19] mmc: Fix handling of response types in imxmmc and tifm drivers
Pavel Pisa wrote: > I have tested your patch. > Kernel builds. I have not found much time for testing. > But I would not like to block changes and I am going > for next week to project meeting in Spain, so there is > my reply. > > I have 2.6.19 + realtime-patches rt14 on the hand. > I have been able to mount and use some cards, but it > I have observed some problems probably related to timing > when I have tried to change CPU frequency. > > >From what I gather, the imx driver/hw is a bit funky in several areas. My plan with this patch is -mm for this release, and merged during the next. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff
Anderson Briglia wrote: >> There's also no handling for an invalid string written to the sysfs node. >> > > Is this really needed? I thought the function just ignored other values sent > to itself that were not handled. > > Well, returning an error on invalid data is the right thing to do. And the warning about mmc_key is caused by this lack of error handling. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MMC updates
Ping! Pierre Ossman wrote: > Linus, please pull from > > git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus > > to receive the following updates: > > drivers/mmc/at91_mci.c | 11 +-- > drivers/mmc/omap.c |6 +++--- > 2 files changed, 8 insertions(+), 9 deletions(-) > > David Brownell (1): > MMC: at91 mmc linkage updates > > Kyungmin Park (1): > ARM: OMAP: fix MMC workqueue changes > -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: > Hi, > > Attached is a very experimental driver for a Ricoh SD Card reader that can be > found in some notebooks like the Samsung P35. > Impressive. Keep up the good work. :) 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New MMC driver model
(Please keep me as cc as I will almost always overlook you replies otherwise) pierre Tardy wrote: > Pierre Ossman drzeus.cx> writes: > >> Register functions >> == >> >> I also intend to write a couple of register functions (sdio_read[bwl]) >> so that card drivers doesn't have to deal with MMC requests more than >> necessary. > > Good idea. Another need may be a sdio_read[bwl]_sync, which will poll for the > end of the cmd52s, instead of waiting for the irq. This polling is faster than > wait_for_completion/irq/tasklet/complete mechanism, which involve several > context switches. > Hadn't thought of that. I will have to do some tests once I have something functional. >> Endianness can also be handled there (SDIO are always LE). > I dont remember sdio spec forcing HW registers to be LE. Function 0 registers > are (BLKSZ for ex), but Function 1-7 register may be BE if the designers found > an advantage to it.. > Hmm... It's been a while since I read the spec, but perhaps the LE requirement was only for the base registers. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] make mmc_sysfs.c:mmc_key_type static
Adrian Bunk wrote: > On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote: >> ... >> Changes since 2.6.20-rc3-mm1: >> ... >> git-mmc.patch >> ... >> git trees >> ... > > > This patch makes the needlessly global struct mmc_key_type static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Thanks, applied. Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: No more "device" symlinks for classes
Kay Sievers wrote: > > The plan is to have a single unified tree at /sys/devices, where all > device-directories live below their parents, and /sys/class contains > only symlinks pointing into this single tree, just like /sys/bus. > > People want to stack class-devices, but this leads to a /sys/devices > tree and several small trees spread around in /sys/class. These trees > need to be connected by "device"-links and the "class:"-links, which > just doesn't make much sense if you can have one single tree with the > same information. > > In the unified tree, the "device"-link will always just point to the > parent device, that's why there is a config option to disable these > links and test current software not to depend on it. > > I'm not sure I completely follow. Should an application look at the symlink (e.g. /sys/class/fooclass/foodev -> /sys/devices/...) and follow that one level up? If so, then this sounds a bit complicated. Especially from shell scripts. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/6] [RFC] Add MMC Password Protection (lock/unlock) support V6
Russell King wrote: > On Fri, Nov 17, 2006 at 09:01:11AM -0400, Anderson Briglia wrote: > >> #define MMC_CAP_BYTEBLOCK (1 << 2)/* Can do non-log2 block >> sizes */ >> +#define MMC_CAP_LOCK_UNLOCK (1 << 3)/* Host password support >> capability */ >> > > What's the point of this capability. If the host can do BYTEBLOCK transfers > it can send the password commands. > > This has been pointed out in the past. Anderson, please make sure you address all the previous concerns before sending out a new patch set. This just creates extra work for us. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial change for mmc/Kconfig: MMC_PXA does not mean only PXA255
Marcin Juszkiewicz wrote:
> PXA MMC driver supports not only PXA255 but also PXA250 and newer ones
>
> Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]>
>
Thanks. 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 "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/6] [RFC] Add MMC Password Protection (lock/unlock) support V6
David Brownell wrote: > I thought the MMC vendors expected to see the actual user-typed > password get SHA1-hashed into a value which would take up the whole > buffer? In general that's a good idea, since it promotes use of > longer passphrases (more information) over short ones (easy2crack). > This sounds like policy though, so it is something user space should concern itself with. We should just provide the infrastructure. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix "prev->state: 2 != TASK_RUNNING??" problem on SD/MMC card removal
Vitaly Wool wrote: > Hello Pierre, > > currently on SD/MMC card removal the system exhibits the following message > (the platform is ARM Versatile): > > prev->state: 2 != TASK_RUNNING?? > mmcqd/762[CPU#0]: BUG in __schedule at linux-2.6/kernel/sched.c:3826 > Hmm... I can't find any such requirement in HEAD, or 2.6.18. What kernel are you running? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix "prev->state: 2 != TASK_RUNNING??" problem on SD/MMC card removal
Vitaly Wool wrote: > On 11/26/06, Pierre Ossman <[EMAIL PROTECTED]> wrote: >> Hmm... I can't find any such requirement in HEAD, or 2.6.18. What kernel >> are you running? > > 2.6.18 + -rt patches by Ingo. > I guess the check is in the rt set somewhere then. Anyway, the mmc queue thread has undergone some changes so your patch needs a bit of a tweak. But I'll put it on my todo and make sure it gets in during the next merge window. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC update
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
to receive the following updates:
drivers/mmc/Kconfig |2
drivers/mmc/at91_mci.c |2
drivers/mmc/au1xmmc.c|2
drivers/mmc/imxmmc.c |2
drivers/mmc/mmc.c| 294 +++---
drivers/mmc/mmc_block.c | 15 +-
drivers/mmc/mmc_queue.c | 63 +
drivers/mmc/mmc_queue.h |3
drivers/mmc/mmci.c |2
drivers/mmc/omap.c | 272 ---
drivers/mmc/omap.h | 55
drivers/mmc/pxamci.c |2
drivers/mmc/sdhci.c | 17 ++
drivers/mmc/sdhci.h |2
drivers/mmc/wbsd.c |2
include/linux/mmc/card.h | 13 ++
include/linux/mmc/protocol.h | 74 ++-
17 files changed, 593 insertions(+), 229 deletions(-)
Christoph Hellwig:
mmc: remove kernel_thread()
David Brownell:
mmc: constify mmc_host_ops vectors
Juha Yrjola juha.yrjola:
Replace base with virt_base and phys_base
Change OMAP_MMC_{READ,WRITE} macros to use the host pointer
Move register definitions away from the header file
Platform device error handling cleanup
Make general code cleanups
Marcin Juszkiewicz:
trivial change for mmc/Kconfig: MMC_PXA does not mean only PXA255
Philip Langdale:
mmc: Add support for mmc v4 high speed mode
mmc: Add support for mmc v4 wide-bus modes
Pierre Ossman:
mmc: Fix mmc_delay() function
mmc: Support for high speed SD cards
mmc: sdhci high speed support
mmc: Flush block queue when removing card
mmc: correct request error handling
Tony Lindgren tony:
Add MMC_CAP_{MULTIWRITE,BYTEBLOCK} flags
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus
to receive the following updates:
drivers/mmc/core/sd.c | 15 +++
drivers/mmc/host/omap.c | 24 +++-
2 files changed, 18 insertions(+), 21 deletions(-)
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 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
mmc_set_bus_width(host, MMC_BUS_WIDTH_4);
}
+ /*
+* Check if read-only switch is active.
+*/
+ if (!oldcard) {
+ if (!host->ops->get_ro) {
+ printk(KERN_WARNING "%s: host does not "
+ "support reading read-only "
+ "switch. assuming write-enable.\n",
+ mmc_hostname(host));
+ } else {
+ if (host->ops->get_ro(host))
+ mmc_card_set_readonly(card);
+ }
+ }
+
if (!oldcard)
host->card = card;
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 1914e65..b0824a3 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -522,28 +522,10 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
if (status & OMAP_MMC_STAT_CARD_ERR) {
- if (host->cmd && host->cmd->opcode ==
MMC_STOP_TRANSMISSION) {
- u32 response = OMAP_MMC_READ(host, RSP6)
- | (OMAP_MMC_READ(host, RSP7) << 16);
- /* STOP sometimes sets must-ignore bits */
- if (!(response & (R1_CC_ERROR
- |
R1_ILLEGAL_COMMAND
- |
R1_COM_CRC_ERROR))) {
- end_command = 1;
- continue;
- }
- }
-
- dev_dbg(mmc_dev(host->mmc), "card status error
(CMD%d)\n",
+ dev_dbg(mmc_dev(host->mmc),
+ "ignoring card status error (CMD%d)\n",
host->cmd->opcode);
- if (host->cmd) {
- host->cmd->error = MMC_ERR_FAILED;
- end_command = 1;
- }
- if (host->data) {
- host->data->error = MMC_ERR_FAILED;
- transfer_error = 1;
- }
+ end_command = 1;
}
/*
--
-- 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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: platform_driver_register() ??
On Thu, 5 Jul 2007 14:51:35 +0530 "Midhun Agnihotram" <[EMAIL PROTECTED]> wrote: > > Is it necessary that the firmware (may be bootloader) notify about > the MMC host to Linux? The kernel documentation (platform.txt) says : > > "The firmware should notify the platform bus about devices before the > legacy drivers have had a chance to load." > >Have I interpreted the above sentence correctly? > I don't know what the meaning of that sentence was supposed to be, but platform devices are everything the kernel cannot probe in a "normal" way. Usually this covers devices that cannot be probed at all, but must be listed some other way (i.e. manually). Commonly the arch and machine specific code adds the devices. The machine code is usually specific to a certain hardware, so the code "knows" which devices are present, even though it can't probe them. So to answer your question; no, the firmware doesn't have to tell Linux about the devices. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: at91_mci: fix hanging and rework to match flowcharts
On Mon, 02 Jul 2007 15:32:00 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote: > Nicolas Ferre wrote: > > Fixes hanging using multi block operations (seen during CMD25). > > Follows closely the datasheet flowcharts. > > > > This piece of code handles better big file writing. I had to take > > care of the notbusy signal during write (at91_mci_handle_cmdrdy > > function) and to rearrange the AT91_MCI_ENDRX and AT91_MCI_RXBUFF > > flag usage. > > > > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > > --- > > Most of the patch looks ok. Do you want to wait for some more tests > or should I chuck this into the imminent merge window? > *ping* -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: at91_mci: fix hanging and rework to match flowcharts
On Mon, 09 Jul 2007 14:58:16 +0200 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > Fixes hanging using multi block operations (seen during CMD25). > Follows closely the datasheet flowcharts. > > This piece of code handles better big file writing. I had to take > care of the notbusy signal during write (at91_mci_handle_cmdrdy > function) and to rearrange the AT91_MCI_ENDRX and AT91_MCI_RXBUFF > flag usage. > > Signed-off-by: Nicolas Ferre <[EMAIL PROTECTED]> > --- Thanks, applied. Rgds Pierre signature.asc Description: PGP signature
Re: OMAP: Add TI TWL92330/Menelaus Power Management chip driver
On Tue, 10 Jul 2007 12:23:06 +0530 "Trilok Soni" <[EMAIL PROTECTED]> wrote: > > RTC part was reviewed and acked-by RTC maintainer. CCing to lkml and > MMC maintainer this time. > There's nothing that really touches any mmc code in there. So I have no comments about it. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: drivers/mmc/card/Kconfig| 18 +++ drivers/mmc/card/block.c|7 +- drivers/mmc/card/queue.c| 191 ++-- drivers/mmc/card/queue.h|7 + drivers/mmc/core/Makefile |3 +- drivers/mmc/core/bus.c | 253 +++ drivers/mmc/core/bus.h | 22 +++ drivers/mmc/core/core.c | 147 +++ drivers/mmc/core/core.h |8 +- drivers/mmc/core/host.c | 156 +++ drivers/mmc/core/host.h | 18 +++ drivers/mmc/core/mmc.c | 65 +++- drivers/mmc/core/sd.c | 63 +++- drivers/mmc/core/sysfs.c| 347 ++- drivers/mmc/core/sysfs.h| 19 +-- drivers/mmc/host/at91_mci.c | 217 +++- drivers/mmc/host/sdhci.c| 10 +- include/linux/pci_ids.h |1 + 18 files changed, 980 insertions(+), 572 deletions(-) Milko Krachounov (1): sdhci: add ene controller id Nicolas Ferre (2): mmc: at91_mci typo mmc: at91_mci: fix hanging and rework to match flowcharts Pierre Ossman (5): mmc: bounce requests for simple hosts mmc: refactor bus operations mmc: refactor host class handling mmc: move layer init and workqueue to core file mmc: fix silly copy-and-paste error Rolf Eike Beer (1): sdhci: Fix "Unexpected interrupt" handling 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make prepare_namespace() wait for devices
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? >> >> The loop-which-sleeps within a loop-which-sleeps seems poorly thought out? >> > > 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 -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make prepare_namespace() wait for devices
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 with the layout you suggested. It may be fewer lines, but I
still say my version was more readable.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 6354cb955ce1602b7b259f525edac7c8f585574b
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the
background, causing a race between them and prepare_namespace().
In order to be able to use these buses without an initrd, we now
wait for the device specified in root= 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]>
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 46fe407..4e5ef6a 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -25,6 +25,7 @@ int __initdata rd_doload; /* 1 = load RAM disk, 0 = don't load */
int root_mountflags = MS_RDONLY | MS_SILENT;
char * __initdata root_device_name;
static char __initdata saved_root_name[64];
+int __initdata root_wait;
dev_t ROOT_DEV;
@@ -216,6 +217,14 @@ static int __init root_dev_setup(char *line)
__setup("root=", root_dev_setup);
+static int __init rootwait_setup(char *line)
+{
+ root_wait = simple_strtol(line,NULL,0);
+ return 1;
+}
+
+__setup("rootwait=", rootwait_setup);
+
static char * __initdata root_mount_data;
static int __init root_data_setup(char *str)
{
@@ -438,11 +447,20 @@ void __init prepare_namespace(void)
root_device_name += 5;
}
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
-
if (initrd_load())
goto out;
+ /* wait for any asynchronous scanning to complete */
+ if ((ROOT_DEV == 0) && root_wait) {
+ printk(KERN_INFO "Waiting for root device %s...\n",
+ saved_root_name);
+ while (driver_probe_done() != 0 ||
+ (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
+ msleep(100);
+ }
+
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+
if (is_floppy && rd_doload && rd_load_disk(0))
ROOT_DEV = Root_RAM0;
Re: [PATCH] Make prepare_namespace() wait for devices
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://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 1e5e9315f431f54d2a2ee90ed11279271a346764
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the
background, causing a race between them and prepare_namespace().
In order to be able to use these buses without an initrd, we now
wait for the device specified in root= 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]>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index aae2282..685b748 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1538,6 +1538,10 @@ and is between 256 and 4096 characters. It is defined in the file
rootfstype= [KNL] Set root filesystem type
+ rootwait [KNL] Wait (indefinitely) for root device to show up.
+ Useful for devices that are detected asynchronously
+ (e.g. USB and MMC devices).
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 46fe407..187dcb5 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -25,6 +25,7 @@ int __initdata rd_doload; /* 1 = load RAM disk, 0 = don't load */
int root_mountflags = MS_RDONLY | MS_SILENT;
char * __initdata root_device_name;
static char __initdata saved_root_name[64];
+int __initdata root_wait;
dev_t ROOT_DEV;
@@ -216,6 +217,16 @@ static int __init root_dev_setup(char *line)
__setup("root=", root_dev_setup);
+static int __init rootwait_setup(char *str)
+{
+ if (*str)
+ return 0;
+ root_wait = 1;
+ return 1;
+}
+
+__setup("rootwait", rootwait_setup);
+
static char * __initdata root_mount_data;
static int __init root_data_setup(char *str)
{
@@ -438,11 +449,20 @@ void __init prepare_namespace(void)
root_device_name += 5;
}
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
-
if (initrd_load())
goto out;
+ /* wait for any asynchronous scanning to complete */
+ if ((ROOT_DEV == 0) && root_wait) {
+ printk(KERN_INFO "Waiting for root device %s...\n",
+ saved_root_name);
+ while (driver_probe_done() != 0 ||
+ (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
+ msleep(100);
+ }
+
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+
if (is_floppy && rd_doload && rd_load_disk(0))
ROOT_DEV = Root_RAM0;
Re: [RFC] Orphaning MMC host drivers
On Fri, 13 Jul 2007 13:35:35 +0200 Nicolas Ferre <[EMAIL PROTECTED]> wrote: > > Hi Pierre, > > I come back on this request... better late than never ;-) > > As I have patched the AT91 MCI driver these days, with the kind help > of a few people, I think I can now add myself as maintainer for this > driver. Here is the entry below. > Wonderful. And good luck ;) 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/mmc/core/: make 4 functions static
On Fri, 13 Jul 2007 01:56:02 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > This patch makes the following needlessly global functions static: > - sd_ops.c: mmc_wait_for_app_cmd() > - core.c: mmc_start_request() I am a bit torn about these two. Even though we don't cater to out-of-tree stuff, having these as exported symbols shows that they are part of the API. Removing them might risk people going about doing something silly because they don't know the functionality exists, and we might not spot it at patch review time. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMC/SD Root filesystem suspend/resume problems
On Thu, 19 Jul 2007 16:53:39 +0100 Richard Purdie <[EMAIL PROTECTED]> wrote: > Hi Pierre, > > Lots of Linux handhelds use MMC/SD devices as the root file system. > This has worked quite reliably for many kernel versions. In 2.6.22, > it seems that if you suspend such a system then resume it, the device > locks up. Trying to execute anything on the filesystem results in a > "Permission Denied" message. I did see a message from the MMC > subsystem saying it had redetected the card. There are also messages > on the console like "MMC: killing requests for dead queue" each time > you suspend/resume. > The card is removed when you suspend and readded when you resume. That's the only safe thing we can do until we get suspend support in the filesystems. If you really want to shoot yourself in the foot, there is a Kconfig option that keeps the card around across the suspend. 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
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 take responsibility for something that easily breaks because we use a kernel subsystem for something it wasn't meant for. That said, if there is a precedent for achieving this function a certain way, I might be convinced to let it in. I'll have a look at that scsi example. > > I don't know about USB, but root=/dev/mmcblk0p1 used to work before > 2.6.20 and it doesn't work anymore. Doesn't that make this a regression? > Yes and no. It depends on if it was an official function, or just an effect of how things currently were implemented. As far as I can see, it's the latter. The MMC layer goes through several steps that could very well get delayed or happen in parallel. So the fact that it happened to work the way you wanted it to was sheer luck. Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] MMC updates
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: In function 'pxamci_cmd_done': >> > drivers/mmc/host/pxamci.c:236: error: 'MMC_ALL_SEND_CID' undeclared (first >> > use in this function) >> > drivers/mmc/host/pxamci.c:236: error: (Each undeclared identifier is >> > reported only once >> > drivers/mmc/host/pxamci.c:236: error: for each function it appears in.) >> > drivers/mmc/host/pxamci.c:237: error: 'MMC_SEND_CSD' undeclared (first use >> > in this function) >> > drivers/mmc/host/pxamci.c:238: error: 'MMC_SEND_CID' undeclared (first use >> > in this function) >> > >> > >> > > What are opcode defines doing in the driver? Pierre Ossman wrote: > Russell King wrote: > >> See the comments immediately above and below its use. >> >> Welcome to buggy hardware. >> >> >> > > I've read through the erratum, and to me it seems like the bug affects > all long replies, not just these codes. So I think the code should be > fixed to look at the response flag, not the opcode. > > Do you have hardware so that you can test such a change? > > I guess the same question goes to you. :) 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
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 quite. mmc_remove_host() doesn't care if a detect has been executed or not, it only cares about whether or not one is executing right now. So in order for your patch to work, there must be no way that mmc_finish_detect() is called before the detect is scheduled. > > I wouldn't call it luck. The way mmc_rescan() is implemented, any scans > that are started before late_initcall time are completed before > mmc_finish_detect() returns. The steps are all done synchronously in > the workqueue function. > Indeed. But it is not by design that they are scheduled before late_initcall(). Also, flushing the workqueue is also not a by-design way of completing a scan, it just happens to be that way right now. > And I never realized that using a block device as a parameter to the > root= parameter could possibly be "unofficial" functionality...? Then you've learned something new. ;) Only some devices work that way (generally only those with "simple" interfaces). And most things are these days behind more advanced buses, more akin to a network. Generally, not waiting for a lot of hardware is a good thing as it speeds up boot times. In my mind, the proper way is having a script in an initrd that waits for just the parts of the hardware that this particular system needs. Everything else can be brought up in the background. Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
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 scan. If > multiple host controllers are present, they will all schedule their > scans before all module_init()s have been called. Am I missing > something? > You're assuming two things: 1. The bus the host controller reside on is synchronous both in adding devices and drivers. This is true for most buses, but not all. As we can see, the MMC bus is an example of one that isn't. 2. The bus the host controller reside on is scanned before any sync function we add. The second probably isn't much of a stretch, but the first is more likely to break. E.g. an usb based controller would not satisfy 1 as usb is scanned asynchronously. Platform devices are case by case (e.g. some device might be delayed since it needs time to power up). >> Indeed. But it is not by design that they are scheduled before >> late_initcall(). >> Also, flushing the workqueue is also not a by-design way of completing a >> scan, >> it just happens to be that way right now. > > So how is it supposed to work "by design"? > It isn't. The MMC bus is a pesky bugger in that it is slow and involves a lot of sleeping and asynchronous callbacks. As such, synchronisation needs to be very explicit using for example completions. >>> And I never realized that using a block device as a parameter to the >>> root= parameter could possibly be "unofficial" functionality...? >> Then you've learned something new. ;) > > Guess so. It seems like the prepare_namespace stuff is getting less > useful every day. > Probably. But I'd like to hope we're gaining more than we lose. There are some horror stories from the scsi camp where synchronous scanning means it takes an hour to boot a machine. >> Only some devices work that way (generally only those with "simple" >> interfaces). >> And most things are these days behind more advanced buses, more akin to a >> network. > > It's funny that NFS root does not have these kinds of problems then... > I'm not familiar with that code, but I would guess it has a whole bunch of prerequisite conditions. And the nfs root installations I've seen all use initrd, so I would assume there are some restrictions to letting the kernel handle it. >> Generally, not waiting for a lot of hardware is a good thing as it speeds up >> boot times. In my mind, the proper way is having a script in an initrd that >> waits for just the parts of the hardware that this particular system needs. >> Everything else can be brought up in the background. > > Yeah, but I suspect most users will rather have a system that actually > boots than a system that would have booted very quickly if it had booted > at all. > I think most people can live with having an initrd, so I wouldn't paint quite such a bleak picture. > Btw, how can I wait for the scanning to complete from early userspace? > Monitor /proc/partitions or /sys until the device you need for rootfs shows up. The big problem from my point of view is that I do not want to start promising people a feature we might not be able to support in the future, and perhaps not even now with some hardware. Is there some reason you cannot use an initrd or is it just the inconvenience? Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] MMC updates
Nicolas Pitre wrote: > Actually, I'm not the author of this workaround. And looking at it > closer, the current workaround is utterly buggy as it completely inhibit > CRC error reporting for everything but the listed commands when the MSB > of the response is a zero. > > Your name popped up on the commit for this, but as that was during the bk days the information was severely lacking. > Please apply the following patch. It is compile tested only as I don't > have PXA27x hardware with MMC at the moment, but it just cannot be worse > than 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://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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SDHCI issues on Ricoh in 2.6.20, 21 and 21-rc7-mm2
Tobias Bengtsson wrote: > Hi, > > Inserting a SD card after bootup does not work. > Please cc any response to me personally as I'm not on the list. > Very odd. And unfortunately I do not know what the problem might be. >From your testing we can conclude two things: - The controller has no problem detecting the device (the difference in the "Present" register shows that). - Interrupts work just fine, as it can properly communicate with the card. And since the problem is normally one of those two, I have no idea what the hell is going on here. Ricoh is also 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, 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
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 show up in the future. My point was that we know of scenarios that will break this, so it won't be a universal solution (even though it might work right now). > > I see. The flush_workqueue approach might end up waiting for other > things than just scanning, is that the problem? Would it be better to > add a per-host "inital scan complete" completion that we could wait on > instead? > That would be a cleaner solution yes. That way we don't exploit any current behaviour that might change in the future. > > I'm not sure how many embedded people actually know how to build an > initrd for a custom board. > All the ones I have on my desk right now use initrd. ;) > > But if you don't want this issue fixed (i.e. you don't think of it as > an issue) I guess I have to either start working on yet another initrd > setup or just apply the patch to our vendor kernel and be done with it. > The latter certainly is the most tempting, but I suppose the former is > more like how things are supposed to be done in the future. > Of course I see it as an issue. My concern is if we gain more than we lose. I had a chat with David Woodhouse and Segher Boessenkool and I think we have another approach. Basically, we move the waiting which would normally go into the initrd and move it into the kernel. So you get something like: "Waiting for root device /dev/mmcblk0p1..." The only problem here is if the device never shows up, but if that was the case you would previously get a panic, so it should not be any worse. 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" usb aswell). Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
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" usb aswell). > > Yes, that would definitely work. > I'll commence the kernel whipping. Will you be available for testing once I have something working? Rgds Pierre signature.asc Description: OpenPGP digital signature
Re: [PATCH] fix PXA27x MMC workaround for bad CRC with 136 bit response
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 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pxamci.c fails to compile
Russell King wrote: > On Mon, May 14, 2007 at 11:22:04AM +0300, Mike Rapoport wrote: >> The PXA MMC controller does not compile for PXA27x after MMC >> reorganization, because it uses protocol defines to implement HW erratum >> workaround (lines 232 - 247 of drivers/mmc/host/pxamci.c ). >> The following patch fixes it > > It's been discussed over the last few days, and the conclusion that has > been reached is that the work-around is in fact itself buggy. The real > fix should be merged soon. > Indeed. I have the fix ready to go. I was hoping 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.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sdhci: Add quirk to support polling for card presence
Philip Langdale wrote:
> @@ -806,11 +819,18 @@ static void sdhci_tasklet_card(unsigned long param)
> host->mrq->cmd->error = MMC_ERR_FAILED;
> tasklet_schedule(&host->finish_tasklet);
> }
> - }
>
> - spin_unlock_irqrestore(&host->lock, flags);
> + spin_unlock_irqrestore(&host->lock, flags);
> +
>
Where's the unlock for the other branch?
> + host->present = present;
>
>
And this should be protected by the lock :)
> + mmc_detect_change(host->mmc, msecs_to_jiffies(500));
> + }
>
Perhaps we should have a different delay here. After all, we're no
longer delaying against an interrupt.
> - mmc_detect_change(host->mmc, msecs_to_jiffies(500));
> + if (host->chip->quirks & SDHCI_QUIRK_NO_CARD_DETECT_INT) {
> + host->detect_timer.expires = jiffies + 3 * HZ;
> + add_timer(&host->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
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 to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] Make prepare_namespace() wait for devices
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: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the
background, causing a race between them and prepare_namespace().
In order to be able to use these buses without an initrd, we now
wait for the device specified in root= to actually show up.
If the device never shows up than we will hang in an infinite loop.
Previously we panic:ed instead, so this behaviour should be no
worse.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 46fe407..192b2d6 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -438,11 +438,24 @@ void __init prepare_namespace(void)
root_device_name += 5;
}
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
-
if (initrd_load())
goto out;
+ /* wait for any asynchronous scanning to complete */
+ if (ROOT_DEV == 0) {
+ printk("Waiting for root device %s...\n", saved_root_name);
+ do {
+ while (driver_probe_done() != 0)
+msleep(100);
+ ROOT_DEV = name_to_dev_t(saved_root_name);
+ if (ROOT_DEV == 0)
+msleep(100);
+ } while (ROOT_DEV == 0);
+ }
+
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+
+
if (is_floppy && rd_doload && rd_load_disk(0))
ROOT_DEV = Root_RAM0;
Re: [RFC][PATCH] Make prepare_namespace() wait for devices
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. > As for the patch, an infinite loop is *much* worse than a panic. > When one is installing a new kernel on remote box, having it > booted with reboot on panic and loader falling back to old > kernel on the next boot is a bloody good idea - gives you extra > safety. With your patch it will get the box stuck. > Ok. So a timeout or having the entire thing Kconfig optional? 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" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] Make prepare_namespace() wait for devices (v2)
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 <[EMAIL PROTECTED]>
Date: Mon May 14 14:15:46 2007 +0200
init: wait for asynchronously scanned block devices
Some buses (e.g. USB and MMC) do their scanning of devices in the
background, causing a race between them and prepare_namespace().
In order to be able to use these buses without an initrd, we now
wait for the device specified in root= 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]>
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 46fe407..efc134c 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -25,6 +25,7 @@ int __initdata rd_doload; /* 1 = load RAM disk, 0 = don't load */
int root_mountflags = MS_RDONLY | MS_SILENT;
char * __initdata root_device_name;
static char __initdata saved_root_name[64];
+int __initdata root_wait;
dev_t ROOT_DEV;
@@ -216,6 +217,14 @@ static int __init root_dev_setup(char *line)
__setup("root=", root_dev_setup);
+static int __init rootwait_setup(char *line)
+{
+ root_wait = simple_strtol(line,NULL,0);
+ return 1;
+}
+
+__setup("rootwait=", rootwait_setup);
+
static char * __initdata root_mount_data;
static int __init root_data_setup(char *str)
{
@@ -438,11 +447,24 @@ void __init prepare_namespace(void)
root_device_name += 5;
}
- is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
-
if (initrd_load())
goto out;
+ /* wait for any asynchronous scanning to complete */
+ if ((ROOT_DEV == 0) && root_wait) {
+ printk(KERN_INFO "Waiting for root device %s...\n",
+ saved_root_name);
+ do {
+ while (driver_probe_done() != 0)
+msleep(100);
+ ROOT_DEV = name_to_dev_t(saved_root_name);
+ if (ROOT_DEV == 0)
+msleep(100);
+ } while (ROOT_DEV == 0);
+ }
+
+ is_floppy = MAJOR(ROOT_DEV) == FLOPPY_MAJOR;
+
if (is_floppy && rd_doload && rd_load_disk(0))
ROOT_DEV = Root_RAM0;
[GIT PULL] MMC updates
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus to receive the following updates: drivers/mmc/card/block.c | 17 - drivers/mmc/host/au1xmmc.c | 35 ++- drivers/mmc/host/pxamci.c | 18 ++ 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 boundary interrupts mmc: use assigned major for block device Yoichi Yuasa (1): mmc: au1xmmc command types check from data flags -- -- 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Orphaning MMC host drivers
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 up to the plate.
There's a rather long list of cc here, but I've included everyone 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 maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 11c3d5e4b871fc69d72f67811d4eb6bfd7084c43
Author: Pierre Ossman <[EMAIL PROTECTED]>
Date: Mon May 14 21:25:26 2007 +0200
mmc: mark unmaintained drivers
Most of the host controller drivers in the MMC layer lacks an
official maintainer. Make sure this is mentioned in MAINTAINERS
in case someone wants to pick up the ball.
Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>
diff --git a/MAINTAINERS b/MAINTAINERS
index 68a56ad..8f1b60c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -346,6 +346,9 @@ P: Ivan Kokshaysky
M: [EMAIL PROTECTED]
S: Maintained for 2.4; PCI support for 2.6.
+AMD AU1XX0 MMC DRIVER
+S: Orphan
+
AMD GEODE PROCESSOR/CHIPSET SUPPORT
P: Jordan Crouse
M: [EMAIL PROTECTED]
@@ -418,6 +421,9 @@ P: Ian Molton
M: [EMAIL PROTECTED]
S: Maintained
+ARM PRIMECELL MMCI PL180/1 DRIVER
+S: Orphan
+
ARM/ADI ROADRUNNER MACHINE SUPPORT
P: Lennert Buytenhek
M: [EMAIL PROTECTED]
@@ -649,6 +655,9 @@ L: [EMAIL PROTECTED] (subscribers-only)
W: http://linux-atm.sourceforge.net
S: Maintained
+ATMEL AT91 MCI DRIVER
+S: Orphan
+
ATMEL MACB ETHERNET DRIVER
P: Haavard Skinnemoen
M: [EMAIL PROTECTED]
@@ -2382,6 +2391,9 @@ M: [EMAIL PROTECTED]
W: http://popies.net/meye/
S: Maintained
+MOTOROLA I.MX MMCI DRIVER
+S: Orphan
+
MOUSE AND MISC DEVICES [GENERAL]
P: Alessandro Rubini
M: [EMAIL PROTECTED]
@@ -2902,6 +2914,9 @@ M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED] (subscribers-only)
S: Maintained
+PXA MMCI DRIVER
+S: Orphan
+
QLOGIC QLA2XXX FC-SCSI DRIVER
P: Andrew Vasquez
M: [EMAIL PROTECTED]
@@ -3417,6 +3432,9 @@ P: Alex Dubov
M: [EMAIL PROTECTED]
S: Maintained
+TI OMAP MMC INTERFACE DRIVER
+S: Orphan
+
TI OMAP RANDOM NUMBER GENERATOR SUPPORT
P: Deepak Saxena
M: [EMAIL PROTECTED]
Re: [RFC] Orphaning MMC host drivers
Pavel Pisa wrote: > > as I have already stated, I would take responsibility > for I.MX SDHC driver. It is not perfect, but I am trying > to keep and fix it and I would be happy to receive > feedback or help from others. > Great. > > Do you include change or should I send my own patch > for review? 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 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Orphaning MMC host drivers
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 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 to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
