- 14 May, 2006 4 commits
-
-
David Woodhouse authored
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
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: David Woodhouse <dwmw2@infradead.org>
-
Jesper Juhl authored
There's a mem leak in drivers/mtd/devices/block2mtd.c::block2mtd_setup() We can leak 'name' allocated with kmalloc in 'parse_name' if leave via the 'parse_err' macro since it contains a return but doesn't do any freeing. Spotted by coverity checker as bug 615. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
The _board_ driver needs to be mtd->owner, and it in turn pins the nand.ko module. Fix them all to actually do that, and fix nand.ko not to overwrite it -- and also to check that the caller sets it, if the caller is a module. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 13 May, 2006 5 commits
-
-
Jesper Juhl authored
There are two code paths in drivers/mtd/devices/phram.c::phram_setup() that will leak memory. Memory is allocated to the variable 'name' with kmalloc() by the parse_name() function, but if we leave by way of the parse_err() macro, then that memory is never kfree()'d, nor is it ever used with register_device() so it won't be freed later either - leak. Found by the Coverity checker as #593 - simple fix below. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
It was just too painful to deal with. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
We were scanning for 0xFF through the entire chip -- which takes a while when it's a 512MiB device as I have on my current toy. The specs only say we need to check certain bytes -- so do only that. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
- Implement HW ECC support, - Provide read_buf() and write_buf() routines using memcpy - Use on-flash bad block table - Fix module refcounting - Avoid read/modify/write in hwcontrol() - Minor cosmetic fixes Partly based on code and ideas from Tom Sylla <tom.sylla@amd.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
These new chips have 128KiB blocks. Don't try to kmalloc that. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 12 May, 2006 13 commits
-
-
Egry Gábor authored
Signed-off-by: Egry Gábor <gaboregry@t-online.hu> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
Kyungmin Park authored
We need to check block cmd only instead with comparing with cmd Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
-
Kyungmin Park authored
One Block of the NAND Flash Array memory is reserved as a One-Time Programmable Block memory area. Also, 1st Block of NAND Flash Array can be used as OTP. The OTP block can be read, programmed and locked using the same operations as any other NAND Flash Array memory block. OTP block cannot be erased. OTP block is fully-guaranteed to be a valid block. Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
-
Kyungmin Park authored
There's erase bug in DDP. We need to add DDP select in erase Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
-
Kyungmin Park authored
There's some problem with write oob in serveral platform. So we write oob with oobsize aligned (16bytes) instead of 3 bytes (from {2, 3}) Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
-
Kyungmin Park authored
Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com>
-
Jarkko Lavinen authored
Some free byte positions at onenand_oob_64 were wrong. This was also reported by Christian Lehne. 3 byte slots are at 2+16*i and 2 byte slots at 14+16*i. Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com>
-
Kyungmin Park authored
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
-
Kyungmin Park authored
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
-
Jesper Juhl authored
Reduce the nr. of pointer dereferences in fs/jffs2/summary.c Benefits: - micro speed optimization due to fewer pointer derefs - generated code is slightly smaller - better readability (The first two sound like a compiler problem but I'll go with the third. dwmw2). Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
Jean-Luc Leger authored
Default values for boolean and tristate options can only be 'y', 'm' or 'n'. This patch removes wrong default for MTD_PCMCIA_ANONYMOUS. Signed-off-by: Jean-Luc Leger <jean-luc.leger@dspnet.fr.eu.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
Domen Puncer authored
This file hasn't actually been used since the very early days of JFFS2 when Arjan was playing with compression methods. It can go now. Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
Oops. Stupid StudlyCaps. Again. This driver is doubly-deprecated because is was subsumed into doc2000.c and _also_ we want people to start using the new NAND wrapper for these devices anyway. But ISTR there was still one person using it because something didn't work for them. Must chase that up and then I can kill this. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 11 May, 2006 1 commit
-
-
David Woodhouse authored
This lacks hardware ECC support and a few optimisations we're going to want fairly soon, but it works well enough to mount and use JFFS2. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 10 May, 2006 1 commit
-
-
David Woodhouse authored
Stupid StudlyCaps. Who did that? Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 08 May, 2006 5 commits
-
-
David Woodhouse authored
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
This was already a bad plan when I argued against adding it in the first place. Good riddance. Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
David Woodhouse authored
Finally putting it back how it was before Keith got at it -- yay :) Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 07 May, 2006 1 commit
-
-
Lennert Buytenhek authored
After dwmw2 let me know it ought to be done, I rewrote the physmap map driver to be a platform driver. I know zilch about the driver model, so I probably botched it in some way, but I've done some tests on an ixp23xx board which uses physmap, and it all seems to work. In order to not break existing physmap users, I've added some compat code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN is defined and != 0. Also, I've changed the default value for CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently compile in physmap (or new, platform-style, users of physmap) don't get burned. This works pretty well -- the new physmap driver is a drop-in replacement for the old one, and works on said ixp23xx board without any code changes needed. (This should hold as long as users don't touch 'physmap_map' directly.) Once all physmap users have been converted to instantiate their own platform devices, the compat code can go. (Or we decide that we can change all the in-tree users at the same time, and never merge the compat code.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 05 May, 2006 1 commit
-
-
Dmitry Bazhenov authored
It seems like there is a potential race in the function jffs2_do_setattr() in the case when attributes of a symlink are updated. The symlink metadata is read without having f->sem locked. The following patch should fix the race. Signed-off-by: Dmitry Bazhenov <atrey@emcraft.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
- 03 May, 2006 3 commits
-
-
David Woodhouse authored
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
-
Patrick McHardy authored
fix infinite loop in the SCTP-netfilter code: check SCTP chunk size to guarantee progress of for_each_sctp_chunk(). (all other uses of for_each_sctp_chunk() are preceded by do_basic_checks(), so this fix should be complete.) Based on patch from Ingo Molnar <mingo@elte.hu> CVE-2006-1527 Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- 02 May, 2006 6 commits
-
-
Ayaz Abdulla authored
This patch fixes the issues with multiple irqs. I am resending based on feedback. I decoupled the dma mask for consistent memory and fixed leak with multiple irq in error path. Thanks to Manfred for catching the spin lock problem. Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
-
Craig Brind authored
Fixes Rhine I cards disclosing fragments of previously transmitted frames in new transmissions. Before transmission, any socket buffer (skb) shorter than the ethernet minimum length of 60 bytes was zero-padded. On Rhine I cards the data can later be copied into an aligned transmission buffer without copying this padding. This resulted in the transmission of the frame with the extra bytes beyond the provided content leaking the previous contents of this buffer on to the network. Now zero-padding is repeated in the local aligned buffer if one is used. Following a suggestion from the via-rhine maintainer, no attempt is made here to avoid the duplicated effort of padding the skb if it is known that an aligned buffer will definitely be used. This is to make the change "obviously correct" and allow it to be applied to a stable kernel if necessary. There is no change to the flow of control and the changes are only to the Rhine I code path. The patch has run on an in-service Rhine-I host without incident. Frames shorter than 60 bytes are now correctly zero-padded when captured on a separate host. I see no unusual stats reported by ifconfig, and no unusual log messages. Signed-off-by: Craig Brind <craigbrind@gmail.com> Signed-off-by: Roger Luethi <rl@hellgate.ch> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Olaf Hering authored
On Sat, Mar 11, Olaf Hering wrote: > Why is the /sys/class/net/eth0/device symlink not created for the > mv643xx_eth driver? Does this work for other platform device drivers? > Seems to work for the ps2 keyboard at least. The SET_NETDEV_DEV has to be done before a call to register_netdev. With the new patch below, the device symlink for the platform device was created. Unfortunately, after the 4 ls commands, the network connection died. No idea if the box crashed or if something else broke, lost remote access. Provide sysfs 'device' in /class/net/ethN Also, set module owner field, like pcnet32 driver does. Signed-off-by: Olaf Hering <olh@suse.de> Acked-by: Dale Farnsworth <dale@farnsworth.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
-
Jens Axboe authored
Apply the same rules as the anon pipe pages, only allow stealing if no one else is using the page. Signed-off-by: Jens Axboe <axboe@suse.de>
-
Jens Axboe authored
Currently we rely on the PIPE_BUF_FLAG_LRU flag being set correctly to know whether we need to fiddle with page LRU state after stealing it, however for some origins we just don't know if the page is on the LRU list or not. So remove PIPE_BUF_FLAG_LRU and do this check/add manually in pipe_to_file() instead. Signed-off-by: Jens Axboe <axboe@suse.de>
-
Jens Axboe authored
We need to use the minium of {len, PAGE_SIZE-off}, not {len, PAGE_SIZE}-off. The latter doesn't make any sense, and could cause us to attempt negative length transfers... Signed-off-by: Jens Axboe <axboe@suse.de>
-