- 22 5月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 20 5月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 18 5月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 14 5月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
We used to calculate the number of chips to be zero, allocate an array of that size, then nasty things would happen when we attempt to access the first object in that zero-sized array. Now, if the number of _full_ chips that would fit into the map is zero, we allocate an array of one anyway, and then artificially reduce the total size of the resulting MTD device to fit in the map. Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 09 5月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 07 11月, 2005 2 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Nicolas Pitre 提交于
This updates the Primary Vendor-Specific Extended Query parsing to version 1.4 in order to get the information about the Configurable Programming Mode regions implemented in the Sibley flash, as well as selecting the appropriate write command code. This flash does not behave like traditional NOR flash when writing data. While mtdblock should just work, further changes are needed for JFFS2 use. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 23 5月, 2005 1 次提交
-
-
由 Russell King 提交于
Try larger numbers of chips before smaller numbers of chips across the bus width. This means we'll avoid misdetecting a 2 x16 array as 1 x32 if the high 16-bits happen to read as zeros in the QRY area. Signed-off-by: NRussell King <linux@arm.linux.org.uk> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 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!
-