- 16 3月, 2011 6 次提交
-
-
由 Artem Bityutskiy 提交于
This patch adds a possibility to dynamically switch UBI self-checks on and off, instead of toggling them compile-time from the configuration menu. This is much more flexible, and consistent with UBIFS, and this also simplifies UBI Kconfig menu and the code. This patch introduces two levels of self-checks - general, which includes all self-checks which are relatively fast, and I/O, which includes write-verify checks and erase-verify checks, which are relatively slow and involve flash I/O. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
This patch adds a possibility to dynamically select UBI debugging messages, instead of selecting them compile-time from the configuration menu. This is much more flexible, and consistent with UBIFS, and this also simplifies UBI Kconfig menu and the code. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
This additional little macro is used to print a bit more messages while scanning the media. However, we have the 'dbg_bld()' macro for this, so we better us 'dbg_bld()' and kill UBI_IO_DEBUG. This simplifies the code a tiny bit. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
This patch kills the 'ubi->dbg_peb_buf' debugging buffer and the associated mutex, because all users of this buffer are now gone. We are killing this buffer because we are going to switch to dynamic debugging control, just like in UBIFS, which means that CONFIG_MTD_UBI_DEBUG_PARANOID will be removed. In this case we'd end up always allocating 'ubi->dbg_peb_buf', which is rather large (128KiB or more), and this would be wasteful. Thus, we are just killing it. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
Instead of using pre-allocated 'ubi->dbg_peb_buf' buffer in 'ubi_dbg_check_all_ff()', dynamically allocate it when needed. The intend is to get rid of the pre-allocated 'ubi->dbg_peb_buf' buffer completely. And the need for this arises because we want to change to dynamic debugging control instead of compile-time control, i.e., we are going to kill the CONFIG_MTD_UBI_DEBUG_PARANOID Kconfig option, which would mean that 'ubi->dbg_peb_buf' is always allocated, which would be wasteful. Thus, we are getting rid of 'ubi->dbg_peb_buf', and this is a preparation for that. signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
Instead of using pre-allocated 'ubi->dbg_peb_buf' buffer in 'ubi_dbg_check_write()', dynamically allocate it when needed. The intend is to get rid of the pre-allocated 'ubi->dbg_peb_buf' buffer completely. And the need for this arises because we want to change to dynamic debugging control instead of compile-time control, i.e., we are going to kill the CONFIG_MTD_UBI_DEBUG_PARANOID Kconfig option, which would mean that 'ubi->dbg_peb_buf' is always allocated, which would be wasteful. Thus, we are getting rid of 'ubi->dbg_peb_buf', and this is a preparation for that. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
- 07 2月, 2011 5 次提交
-
-
由 Artem Bityutskiy 提交于
When the read operation fails, UBI tries to re-read several times in a hope that one of the subsequent reads may succeed. However, currently UBI re-reads only if MTD failed to read all data, but does not re-reads if all the data were read, but with an integrity error (-EBADMSB). This patch makes UBI to always re-try reading. This should be useful for reading NAND pages with unstable bits - re-reading may help to get correct data. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
Just make them a bit more readable and explanatory. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
During scanning UBI allocates one struct ubi_scan_leb object for each PEB, so it can end up allocating thousands of them. Use slab cache to reduce memory consumption for these 48-byte objects, because currently used 'kmalloc()' ends up allocating 64 bytes per object, instead of 48. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
This change affects only the debugging code. Namely, use mtd->read() function instead of ubi_io_read() to avoid bit-flips injection (ubi_dbg_is_bitflip()) which we do not want on the debugging path. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Artem Bityutskiy 提交于
When reading data from the flash, corrupt the buffer we are about to read to. The idea is to fix the following possible situation: 1. The buffer contains data from previous operation, e.g., read from another PEB previously. The data looks like expected, e.g., if we just do not read anything and return - the caller would not notice this. E.g., if we are reading a VID header, the buffer may contain a valid VID header from another PEB. 2. The driver is buggy and returns use success or -EBADMSG or -EUCLEAN, but it does not actually put any data to the buffer. This may confuse UBI or upper layers - they may think the buffer contains valid data while in fact it is just old data. Thus, try to reveal such buggy MTD drivers with simple debugging code which fills the read buffer with 0x12 constant. Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
- 26 1月, 2011 3 次提交
-
-
由 Artem Bityutskiy 提交于
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 John Ogness 提交于
Wrong macro was used in calculating the data offset: UBI_EC_HDR_SIZE instead of UBI_VID_HDR_SIZE. The data offset should be VID header offset + VID header size (aligned to the minimum I/O unit). This was not a bug only because currently UBI_EC_HDR_SIZE and UBI_VID_HDR_SIZE have the same value of 64 bytes. Commit message was amended by Artem. Signed-off-by: NJohn Ogness <john.ogness@linutronix.de> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
由 Holger Brunck 提交于
In 'nor_erase_prepare()' we want to make sure the UBI headers are corrupted. But it is possible that one of the headers just contains all 0xFFs, which is also OK, because UBI will erase it in case of a power cut. Signed-off-by: NHolger Brunck <holger.brunck@keymile.com> Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
-
- 04 1月, 2011 1 次提交
-
-
由 J. K. Cliburn 提交于
Commit 3f5a2a71 zeroes out the statistics message block (SMB) and coalescing message block (CMB) when adapter ring resources are freed. This is desirable behavior, but, as a side effect, the commit leads to an oops when atl1_set_ringparam() attempts to alter the number of rx or tx elements in the ring buffer (by using ethtool -G, for example). We don't want SMB or CMB to change during this operation. Modify atl1_set_ringparam() to preserve SMB and CMB when changing ring parameters. Cc: stable@kernel.org Signed-off-by: NJay Cliburn <jcliburn@gmail.com> Reported-by: NTõnu Raitviir <jussuf@linux.ee> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 03 1月, 2011 5 次提交
-
-
由 Hans Verkuil 提交于
em28xx uses core assisted locking, so it shouldn't use .ioctl. The .ioctl callback was replaced by .unlocked_ioctl for video nodes, but not for radio nodes. This is now corrected. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
It seems that cx88 and ivtv use wm8775 on some different modes. The patch that added support for a board with wm8775 broke ivtv boards with this device. As we're too close to release 2.6.37, let's just revert it. Reported-by: NAndy Walls <awalls@md.metrocast.net> Reported-by: NEric Sharkey <eric@lisaneric.org> Reported-by: NAuric <auric@aanet.com.au> Reported by: David Gesswein <djg@pdp8online.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Andy Walls 提交于
This patch fixes a regression that crept into 2.6.36. The volume control scale in the cx25840 driver has an unusual mapping from register values to v4l2 volume control values. Enforce the mapping limits, so that the default volume control setting does not fall out of bounds to prevent the cx25840 module device probe from failing. Signed-off-by: NAndy Walls <awalls@md.metrocast.net> Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Saeed Bishara 提交于
use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function aquires the spin lock that needed to protect the drivers data. Cc: <stable@kernel.org> Signed-off-by: NSaeed Bishara <saeed@marvell.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Maurus Cuelenaere 提交于
The owner field was removed from struct attribute in 6fd69dc5, so don't assign it anymore. Signed-off-by: NMaurus Cuelenaere <mcuelenaere@gmail.com> Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
-
- 01 1月, 2011 5 次提交
-
-
由 Julia Lawall 提交于
The earlier call to atm_dev_lookup increases the reference count of dev, so decrease it on the way out. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x, E; constant C; @@ x = atm_dev_lookup(...); ... when != false x != NULL when != true x == NULL when != \(E = x\|x = E\) when != atm_dev_put(dev); *return -C; // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ben Hutchings 提交于
Commit 56543af9 "starfire: use BUILD_BUG_ON for netdrv_addr_t" revealed that the preprocessor condition used to find the size of dma_addr_t yielded the wrong result for some architectures and configurations. This was kluged for 64-bit PowerPC in commit 3e502e63 by adding yet another case to the condition. However, 64-bit MIPS configurations are not detected reliably either. This should be fixed by using CONFIG_ARCH_DMA_ADDR_T_64BIT, but that isn't yet defined everywhere it should be. Signed-off-by: NBen Hutchings <ben@decadent.org.uk> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David Sterba 提交于
Besides -ETIMEDOUT and -EINTR, pci_read_vpd may return other error values like -ENODEV or -EINVAL which are ignored due to the buggy check, but the data are not read from VPD anyway and this is checked subsequently with at most 3 needless loop iterations. This does not show up as a runtime bug. CC: Matt Carlson <mcarlson@broadcom.com> CC: Michael Chan <mchan@broadcom.com> Signed-off-by: NDavid Sterba <dsterba@suse.cz> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jesper Juhl 提交于
We are leaking memory in drivers/net/cnic.c::cnic_alloc_uio_rings() if either of the calls to dma_alloc_coherent() fail. This patch fixes it by freeing both the memory allocated with kzalloc() and memory allocated with previous calls to dma_alloc_coherent() when there's a failure. Thanks to Joe Perches <joe@perches.com> for suggesting a better implementation than my initial version. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Acked-by: NMichael Chan <mchan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jesper Juhl 提交于
Hi, In drivers/isdn/gigaset/capi.c::do_disconnect_req() we will leak the memory allocated (with kmalloc) to 'b3cmsg' if the call to alloc_skb() fails. ... b3cmsg = kmalloc(sizeof(*b3cmsg), GFP_KERNEL); allocation here ------^ if (!b3cmsg) { dev_err(cs->dev, "%s: out of memory\n", __func__); send_conf(iif, ap, skb, CAPI_MSGOSRESOURCEERR); return; } capi_cmsg_header(b3cmsg, ap->id, CAPI_DISCONNECT_B3, CAPI_IND, ap->nextMessageNumber++, cmsg->adr.adrPLCI | (1 << 16)); b3cmsg->Reason_B3 = CapiProtocolErrorLayer1; b3skb = alloc_skb(CAPI_DISCONNECT_B3_IND_BASELEN, GFP_KERNEL); if (b3skb == NULL) { dev_err(cs->dev, "%s: out of memory\n", __func__); send_conf(iif, ap, skb, CAPI_MSGOSRESOURCEERR); return; leak here ------^ ... This leak is easily fixed by just kfree()'ing the memory allocated to 'b3cmsg' right before we return. The following patch does that. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Acked-by: NTilman Schmidt <tilman@imap.cc> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 31 12月, 2010 1 次提交
-
-
由 Nitin Gupta 提交于
This reverts commit 7e24cce3 because it was never appropriate for mainline. Do not check for init flag before starting I/O - zram module is unusable without this fix. The oops mentioned in the reverted commit message was actually a problem only with the zram version as present in project's own repository where we allocate struct zram_stats_cpu upon device initialization. OTOH, In mainline/staging version of zram, we allocate struct stats upfront, so this oops cannot happen in mainline version. Checking for init_done flag in zram_make_request() results in a *no-op* for any I/O operation since we simply always return success. This flag is actually set when the first write occurs on a zram disk which triggers its initialization. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=25722Reported-by: NDennis Jansen <dennis.jansen@web.de> Signed-off-by: NNitin Gupta <ngupta@vflare.org> Cc: Anton Blanchard <anton@samba.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 12月, 2010 4 次提交
-
-
由 Chris Wilson 提交于
As we have already detected something attached to the chip during initialisation, always report the LVDS connector status as connected during probing. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Chris Wilson 提交于
As I feared, whilst this fixed the clocks for the Lenovo U160, it broke many other machines. So lets reverts commit 448f53a1 and search for the real bug. Reported-and-tested-by: Travis Hume <travis@computoring.org> [et al] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25842 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32698Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Jate Sujjavanich 提交于
After grabbing a msg from the msgq, the mcfqspi_work function calls list_del_init on the mcfqspi->msgq which unintentionally deletes the rest of the list before it can be processed. If qspi call was made using spi_sync, this can result in a process hang. Signed-off-by: NJate Sujjavanich <jsujjavanich@syntech-fuelmaster.com> Acked-by: NSteven King <sfking@fdwdc.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
由 Gregory CLEMENT 提交于
When SPI wake up from OFF mode, CS is in the wrong state: force it to the inactive state. During the system life, I monitored the CS behavior using a oscilloscope. I also activated debug in omap2_mcspi, so I saw when driver disable the clocks and restore context when device is not used.Each time the CS was in the correct state. It was only when system was put suspend to ram with off-mode activated that on resume the CS was in wrong state( ie activated). Changelog: * Change from v1 to v2: - Rebase on linus/master (after 2.6.37-rc1) - Do some clean-up and fix indentation on both patches - Add more explanations for patch 2 * Change from v2 to v3: - Use directly resume function of spi_master instead of using function - from spi_device as Grant Likely pointed it out. - Force this transition explicitly for each CS used by a device. * Change from v3 to v4: - Patch clean-up according to Kevin Hilman and checkpatch. - Now force CS to be in inactive state only if it was inactive when it was suspended. * Change from v4 to v5: - Rebase on linus/master (after 2.6.37-rc3) - Collapse some lines as pointed by Grant Likely - Fix a spelling * Change from v5 to v6: - Rebase on linus/master (after 2.6.37-rc7) - Use CONFIG_SUSPEND instead of CONFIG_PM - Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and add the resume method there. - Fix multi-line comment style * Change from v6 to v7: - Rebase on linus/master (after 2.6.37-rc8) - Drop an extra line Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net> Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 29 12月, 2010 5 次提交
-
-
由 Dan Carpenter 提交于
The intent here was to test if the allocation failed but we tested "SharedMemSize" instead of "SharedMemAddr" by mistake. Signed-off-by: NDan Carpenter <error27@gmail.com> Reviewed-by: NJiri Pirko <jpirko@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 stephen hemminger 提交于
Linux would not connect to other router running old version Cisco IOS (12.0). This is most likely a bug in that version of IOS, since it is fixed in later versions. As a workaround this patch allows a module parameter to be set to disable compressing the protocol ID. See: https://bugzilla.vyatta.com/show_bug.cgi?id=3979 RFC 1990 allows an implementation to formulate MP fragments as if protocol compression had been negotiated. This allows us to always send compressed protocol IDs. But some implementations don't accept MP fragments with compressed protocol IDs. This parameter allows us to interoperate with them. The default value of the configurable parameter is the same as the current behavior: protocol compression is enabled. If protocol compression is disabled we will not send compressed protocol IDs. This is based on an earlier patch by Bob Gilligan (using a sysctl). Module parameter is writable to allow for enabling even if ppp is already loaded for other uses. Signed-off-by: NStephen Hemminger <shemminger@vyatta.com> Acked-by: NEric Dumazet <eric.dumazet@gmail.com> Acked-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Breno Leitao 提交于
This patch avoids disabling the vlan flags using ethtool. Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Williams 提交于
A race exists when initializing ueagle-atm devices where the generic atm device may not yet be created before the driver attempts to initialize it's PHY signal state, which checks whether the atm device has been created or not. This often causes the sysfs 'carrier' attribute to be '1' even though no signal has actually been found. uea_probe usbatm_usb_probe driver->bind (uea_bind) uea_boot kthread_run(uea_kthread) uea_kthread usbatm_atm_init uea_start_reset atm_dev_register UPDATE_ATM_SIGNAL UPDATE_ATM_SIGNAL checks whether the ATM device has been created and if not, will not update the PHY signal state. Because of the race that does not always happen in time, and the PHY signal state remains ATM_PHY_SIG_FOUND even though no signal exists. To fix the race, just create the kthread during initialization, and only after initialization is complete, start the thread that reboots the device and initializes PHY state. [ 3030.490931] uea_probe: calling usbatm_usb_probe [ 3030.490946] ueagle-atm 8-2:1.0: usbatm_usb_probe: trying driver ueagle-atm with vendor=1110, product=9031, ifnum 0 [ 3030.493691] uea_bind: setting usbatm [ 3030.496932] usb 8-2: [ueagle-atm] using iso mode [ 3030.497283] ueagle-atm 8-2:1.0: usbatm_usb_probe: using 3021 byte buffer for rx channel 0xffff880125953508 <kthread already started before usbatm_usb_probe() has returned> [ 3030.497292] usb 8-2: [ueagle-atm] (re)booting started <UPDATE_ATM_SIGNAL checks whether ATM device has been created yet before setting PHY state> [ 3030.497298] uea_start_reset: atm dev (null) <and since it hasn't been created yet PHY state is not set> [ 3030.497306] ueagle-atm 8-2:1.0: usbatm_usb_probe: using 3392 byte buffer for tx channel 0xffff8801259535b8 [ 3030.497374] usbatm_usb_probe: about to init [ 3030.497379] usbatm_usb_probe: calling usbatm_atm_init <atm device finally gets created> [ 3030.497384] usbatm_atm_init: creating atm device! Signed-off-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ahmed S. Darwish 提交于
The current code mis-calculates the ramoops header size, leading to an overflow over the next record at best, or over a non-allocated region at worst. Fix that calculation. Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com> Acked-by: NMarco Stornelli <marco.stornelli@gmail.com> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 27 12月, 2010 4 次提交
-
-
由 Guennadi Liakhovetski 提交于
LCDC hardware can support 1920x1080 formats, adjust the driver to cover them. Besides, instead of guessing some "reasonable" validity checks, only verify values in .fb_check_var(), that we are sure, we cannot support. Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Fabio Estevam 提交于
MX27 and MX25 have 10 bits in the YMAX field of LCDC Size Register. Fix the maximum value for yres. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
-
由 Jeff Garzik 提交于
We don't need or want MSR usage here, on x86-64. x86-64 was disabled intentionally in Kconfig, but commit 9272dcc2 changed that. drivers/ata/pata_cs5536.c:47:1: warning: "rdmsr" redefined In file included from arch/x86/include/asm/irqflags.h:60, from include/linux/irqflags.h:15, from arch/x86/include/asm/system.h:11, from arch/x86/include/asm/processor.h:17, from include/linux/prefetch.h:14, from include/linux/list.h:7, from include/linux/module.h:9, from drivers/ata/pata_cs5536.c:33: arch/x86/include/asm/paravirt.h:146:1: warning: this is the location of the previous definition drivers/ata/pata_cs5536.c:48:1: warning: "wrmsr" redefined arch/x86/include/asm/paravirt.h:154:1: warning: this is the location of the previous definition Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
由 Rafael J. Wysocki 提交于
GPEs with corresponding _Lxx/_Exx control methods need to be disabled during initialization in case they have been enabled by the BIOS, so that they don't fire up until they are enabled by acpi_update_gpes(). References: https://bugzilla.kernel.org/show_bug.cgi?id=25412Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 26 12月, 2010 1 次提交
-
-
由 Jarek Poplawski 提交于
Joel Soete reported oopses during pppoe over sundance NIC, caused by a bug in skb allocation and dma mapping code, where skb_reserve() bytes weren't taken into account. As a followup to the patch: "sundance: Fix oopses with corrupted skb_shared_info" very similar code is fixed here for three other drivers. Signed-off-by: NJarek Poplawski <jarkao2@gmail.com> Cc: Joel Soete <soete.joel@scarlet.be> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-