- 27 2月, 2010 2 次提交
-
-
由 Maxim Levitsky 提交于
This prevents a memory leak Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Maxim Levitsky 提交于
* Add locking where it was missing. * Don't do a get_mtd_device in blktrans_open because it would lead to a deadlock; instead do that in add_mtd_blktrans_dev. * Only free the mtd_blktrans_dev structure when the last user exits. * Flush request queue on device removal. * Track users, and call tr->release in del_mtd_blktrans_dev Due to that ->open and release aren't called more that once. Now it is safe to call del_mtd_blktrans_dev while the device is still in use. Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 25 2月, 2010 1 次提交
-
-
由 Ben Hutchings 提交于
Since we allocate struct mtd_blktrans_dev for each block device, we can add our own structure members to the end. Therefore embed struct mtd_blktrans_dev in struct mtdblk_dev and remove the static array of struct mtdblk_dev. Also remove the redundant pointer to struct mtd_info. This is preparation for removing the static limit on the number of MTD devices. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 16 9月, 2009 1 次提交
-
-
由 Nicolas Pitre 提交于
Due to problems at cam.org, my nico@cam.org email address is no longer valid. FRom now on, nico@fluxnic.net should be used instead. Signed-off-by: NNicolas Pitre <nico@fluxnic.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 9月, 2009 1 次提交
-
-
由 Matthias Kaehlcke 提交于
mtdblock erase_write(): fix typo in comment Signed-off-by: NMatthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 03 8月, 2009 1 次提交
-
-
由 Matthias Kaehlcke 提交于
The mtdblks array and its content are prone to race conditions. Introduce the mutex mtdblks_lock in order to solve this. [Amended by Artem Bityutskiy] Signed-off-by: NMatthias Kaehlcke <matthias@kaehlcke.net> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 05 6月, 2008 1 次提交
-
-
由 Adrian Bunk 提交于
Once upon a time, the MTD repository was using CVS. This patch therefore removes all usages of the no longer updated CVS keywords from the MTD code. This also includes code that printed them to the user. Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 29 11月, 2006 2 次提交
-
-
由 Burman Yan 提交于
Signed-off-by: NYan Burman <yan_952@hotmail.com> Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
由 Richard Purdie 提交于
Currently, mtd_blkdevs enforces a block size of 512, even if the drivers can seemingly request a different size. This patch fixes mtd_blkdevs so block sizes other than 512 work correctly. Signed-off-by: NRichard Purdie <rpurdie@openedhand.com> Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 30 5月, 2006 1 次提交
-
-
由 Joern Engel 提交于
Ram devices get the extra capability of MTD_NO_ERASE - not requiring an explicit erase before writing to it. Currently only mtdblock uses this capability. Rest of the patch is a simple text replacement. Signed-off-by: NJoern Engel <joern@wh.fh-wedel.de>
-
- 29 5月, 2006 1 次提交
-
-
由 Thomas Gleixner 提交于
Most of those macros are unused and the used ones just obfuscate the code. Remove them and fixup all users. Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 17 4月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
mtdblock is the only user of aggregate capabilities in mtd. This is clearly bogus and should be changed. In particular, it tries to determine whether the device in question is a piece of RAM. For every single driver that fits the current criteria, an easier test would be to check for the type being MTD_RAM. Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 01 4月, 2006 1 次提交
-
-
由 Ingo Molnar 提交于
Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: NDavid Woodhouse <dwmw2@infradead.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 11月, 2005 2 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Thomas Gleixner 提交于
While we are at it, reorder the includes and remove the silly /* TASK */ comment Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 31 10月, 2005 1 次提交
-
-
由 Tim Schmielau 提交于
I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-