summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP: Make plat/omap-pm.h local to mach-omap2Tony Lindgren2012-10-191-1/+0
| | | | | | | | | | | | | | | We must move this for ARM common zImage support. Note that neither drivers/media/rc/ir-rx51.c or drivers/media/platform/omap3isp/ispvideo.c need to include omap-pm.h, so this patch removes the include for those files. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi> Cc: linux-media@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP1: Move plat/tc.h to mach/tc.h for omap1Tony Lindgren2012-10-171-1/+1
| | | | | | | | | We cannot keep this in plat as it causes problems with the ARM single zImage support. Cc: Felipe Balbi <balbi@ti.com> Cc: linux-pcmcia@lists.infradead.org Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: Make plat/fpga.h local to arch/arm/plat-omapTony Lindgren2012-10-172-6/+6
| | | | | | | | | | | | | | | | | | There's no need to have this file in plat/fpga.h. We can make it local to plat-omap replacing fpga_read/write functions directly with readb/writeb as that's how they are already defined in fpga.h. Note that 2420 based H4 is also using the fpga, so let's keep the led support around in plat-omap until we flip over mach-omap2 to device tree. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: linux-fbdev@vger.kernel.org Cc: Felipe Balbi <balbi@ti.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge branch 'omap-for-v3.8/cleanup-headers-dss' into ↵Tony Lindgren2012-10-1713-83/+233
|\ | | | | | | | | | | | | | | | | | | omap-for-v3.8/cleanup-headers Conflicts: arch/arm/mach-omap2/board-omap3logic.c arch/arm/mach-omap2/gpmc.c drivers/media/platform/omap/omap_vout.c drivers/media/platform/omap/omap_vout_vrfb.c
| * Merge remote-tracking branch 'tomi/3.8/vrfb-conversion' into ↵Tony Lindgren2012-10-177-32/+128
| |\ | | | | | | | | | omap-for-v3.8/cleanup-headers-dss
| | * OMAPFB: use omap_vrfb_supported()Tomi Valkeinen2012-10-171-5/+1
| | | | | | | | | | | | | | | | | | Replace cpu_is_*() check with omap_vrfb_supported(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: VRFB: add omap_vrfb_supported()Tomi Valkeinen2012-10-171-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | Add an exported function omap_vrfb_supported() which returns true if the vrfb driver has been loaded succesfully. This can be used to decide if VRFB can be used or not. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAP: move arch/arm/plat-omap/include/plat/vrfb.hTomi Valkeinen2012-10-177-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that vrfb driver is not omap dependent anymore, we can move vrfb.h from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
| | * OMAP: VRFB: convert vrfb to platform deviceTomi Valkeinen2012-10-171-20/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch converts vrfb library into a platform device, in an effort to remove omap dependencies. The platform device is registered in arch/arm/plat-omap/fb.c and assigned resources depending on whether running on omap2 or omap3. The vrfb driver will parse those resources and use them to access vrfb configuration registers and the vrfb virtual rotation areas. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com>
| * | OMAPDSS: remove <plat/cpu.h> includesTomi Valkeinen2012-10-173-5/+0
| | | | | | | | | | | | | | | | | | | | | cpu_is_* calls are no longer used in omapdss, so the includes for <plat/cpu.h> can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: HDMI: use omapdss_versionTomi Valkeinen2012-10-163-4/+16
| | | | | | | | | | | | | | | | | | Use omapdss_version in hdmi.c to select the proper hdmi features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: DSS: use omapdss_versionTomi Valkeinen2012-10-161-10/+27
| | | | | | | | | | | | | | | | | | Use omapdss_version in dss.c to select the proper dss features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: DISPC: use omapdss_versionTomi Valkeinen2012-10-161-13/+28
| | | | | | | | | | | | | | | | | | Use omapdss_version in dispc.c to select the proper dispc features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: use omapdss_version in dss_features.cTomi Valkeinen2012-10-163-19/+34
| |/ | | | | | | | | | | | | Pass the omapdss_version to dss_features.c and use it to select the proper dss features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | Merge branch 'omap-for-v3.8/cleanup-headers-mmc' into ↵Tony Lindgren2012-10-172-12/+17
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | omap-for-v3.8/cleanup-headers Conflicts: arch/arm/mach-omap1/devices.c arch/arm/mach-omap2/omap_hwmod_33xx_data.c arch/arm/mach-omap2/omap_hwmod_3xxx_data.c drivers/mmc/host/omap.c
| * | mmc: omap: Remove cpu_is_omap usage from the driverTony Lindgren2012-10-151-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed for the ARM common zImage support. We can use the existing slot features to pass omap1 specific options to the driver. For omap2 we don't want to pass anything new as that will be eventually moved to use device tree based init. Note that this patch depends on earlier patch that moves plat/mmc.h into include/linux/platform_data. Cc: linux-mmc@vger.kernel.org Cc: Venkatraman S <svenkatr@ti.com> Acked-by: Chris Ball <cjb@laptop.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | ARM: OMAP: Split plat/mmc.h into local headers and platform_dataTony Lindgren2012-10-152-4/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | We need to remove this from plat for ARM common zImage support. Also remove includes not needed by the omap_hsmmc.c driver. Cc: linux-mmc@vger.kernel.org Acked-by: Chris Ball <cjb@laptop.org> Acked-by: Venkatraman S <svenkatr@ti.com> [tony@atomide.com: fold in removal of unused driver includes] Signed-off-by: Tony Lindgren <tony@atomide.com>
* | Merge branch 'omap-for-v3.8/cleanup-headers-gpmc' into ↵Tony Lindgren2012-10-172-26/+108
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | omap-for-v3.8/cleanup-headers Conflicts: arch/arm/mach-omap2/board-3430sdp.c arch/arm/mach-omap2/board-h4.c arch/arm/mach-omap2/board-rx51-peripherals.c arch/arm/mach-omap2/board-rx51.c arch/arm/mach-omap2/pm34xx.c drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c
| * | mtd: nand: omap: handle gpmc bch[48]Afzal Mohammed2012-10-151-11/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gpmc-nand bch registers are now available in driver, make use of it to handle bch[48] instead of relying on gpmc exported functions. And so nand driver no longer needs gpmc header, remove it. Signed-off-by: Afzal Mohammed <afzal@ti.com>
| * | mtd: nand: omap: bring in gpmc nand macrosAfzal Mohammed2012-10-151-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Bring onto driver the macros defined in gpmc.h that are not necessary outside driver, helps in removing inclusion of gpmc.h too. Also remove GPMC prefix on those macros to make clear it's independence with gpmc header. Signed-off-by: Afzal Mohammed <afzal@ti.com>
| * | mtd: onenand: omap: use pdata info instead of cpu_isAfzal Mohammed2012-10-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platform data now contains a field to indicate whether soc belongs to omap34xx family, use it instead of cpu_is_* check. This helps in removing dependency of platform specific header file - cpu.h Signed-off-by: Afzal Mohammed <afzal@ti.com>
| * | mtd: nand: omap: read nand using register addressAfzal Mohammed2012-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that gpmc-nand registers are available in driver, use it to read nand data. "65b97cf mtd: nand: omap2: handle nand on gpmc" modified all other instances. After initial versions of that patch, a new change added reading nand data using gpmc exposed function. In the final version this change was not taken care. Signed-off-by: Afzal Mohammed <afzal@ti.com>
| * | mtd: nand: omap: free region as per resource sizeAfzal Mohammed2012-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | memory as is now obtained via resource, upon freeing use resource size. This also helps get rid of one macro. Signed-off-by: Afzal Mohammed <afzal@ti.com>
| * | mtd: onenand: omap: cleanup gpmc dependencyAfzal Mohammed2012-10-151-2/+0
| |/ | | | | | | | | | | | | | | requesting, freeing gpmc cs is now handled fully by gpmc, remove left out gpmc dependency as well as unnecessary include of gpmc.h Signed-off-by: Afzal Mohammed <afzal@ti.com>
* | Merge branch 'omap-for-v3.8/cleanup-headers-dma' into ↵Tony Lindgren2012-10-1716-15/+41
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | omap-for-v3.8/cleanup-headers Conflicts: drivers/crypto/omap-aes.c drivers/crypto/omap-sham.c drivers/dma/omap-dma.c
| * | ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.hLokesh Vutla2012-10-1515-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | Move plat/dma.h to plat-omap/dma-omap.h as part of single zImage work Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | ARM: OMAP2+: DMA: Moving OMAP2+ DMA channel definitions to mach-omap2Lokesh Vutla2012-10-154-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to omap1, some of the omap2+ dma channel definitions are used by some drivers. For moving omap2+ dma channel definitions to mach-omap2/, the used ones should be defined locally to driver. Drivers can eliminate it using DT, platform data, or IORESOURCE_DMA And moving omap2+ DMA channel definitions to mach-omap2 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions to mach-omap1Lokesh Vutla2012-10-154-0/+9
| |/ | | | | | | | | | | | | | | | | | | | | Some of the omap1 dma channel definitions are used by some drivers. For moving omap1 dma channel definitions to mach-omap1/, the used ones should be defined locally to driver. Driver can eliminate it by using DT, platform data, or IORESOURCE_DMA. And moving OMAP1 DMA channel definitions to mach-omap1 Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | ARM: OMAP: Trivial driver changes to remove include plat/cpu.hTony Lindgren2012-10-164-18/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers should not use cpu_is_omap or cpu_class_is_omap macros, they should be private to the platform init code. And we'll be removing plat/cpu.h and only have a private soc.h for the arch/arm/*omap* code. This patch is intended as preparation for the core omap changes and removes the need to include plat/cpu.h from several drivers. This is needed for the ARM common zImage support. These changes are OK to do because: - omap-rng.c does not need plat/cpu.h - omap-aes.c and omap-sham.c get the proper platform_data passed to them so they don't need extra checks in the driver - omap-dma.c and omap-pcm.c can test the arch locally as omap1 and omap2 cannot be compiled together because of conflicting compiler flags Cc: Deepak Saxena <dsaxena@plexity.net> Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: David S. Miller <davem@davemloft.net> Cc: Venkatraman S <svenkatr@ti.com> Cc: Chris Ball <cjb@laptop.org> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Dan Williams <djbw@fb.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: linux-crypto@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: linux-kernel@vger.kernel.org [tony@atomide.com: mmc changes folded in to an earlier patch] Signed-off-by: Tony Lindgren <tony@atomide.com>
* | staging: tidspbridge: remove unnecessary include of <plat/clock.h>Paul Walmsley2012-10-161-1/+0
|/ | | | | | | | | The DSPBridge driver includes arch/arm/plat-omap/include/plat/clock.h. All of the <plat/ ...> includes are causing problems with the ARM single image kernel effort. Remove this one. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge tag 'md-3.7' of git://neil.brown.name/mdLinus Torvalds2012-10-1311-127/+567
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull md updates from NeilBrown: - "discard" support, some dm-raid improvements and other assorted bits and pieces. * tag 'md-3.7' of git://neil.brown.name/md: (29 commits) md: refine reporting of resync/reshape delays. md/raid5: be careful not to resize_stripes too big. md: make sure manual changes to recovery checkpoint are saved. md/raid10: use correct limit variable md: writing to sync_action should clear the read-auto state. Subject: [PATCH] md:change resync_mismatches to atomic64_t to avoid races md/raid5: make sure to_read and to_write never go negative. md: When RAID5 is dirty, force reconstruct-write instead of read-modify-write. md/raid5: protect debug message against NULL derefernce. md/raid5: add some missing locking in handle_failed_stripe. MD: raid5 avoid unnecessary zero page for trim MD: raid5 trim support md/bitmap:Don't use IS_ERR to judge alloc_page(). md/raid1: Don't release reference to device while handling read error. raid: replace list_for_each_continue_rcu with new interface add further __init annotations to crypto/xor.c DM RAID: Fix for "sync" directive ineffectiveness DM RAID: Fix comparison of index and quantity for "rebuild" parameter DM RAID: Add rebuild capability for RAID10 DM RAID: Move 'rebuild' checking code to its own function ...
| * md: refine reporting of resync/reshape delays.NeilBrown2012-10-111-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If 'resync_max' is set to 0 (as is often done when starting a reshape, so the mdadm can remain in control during a sensitive period), and if the reshape request is initially delayed because another array using the same array is resyncing or reshaping etc, when user-space cannot easily tell when the delay changes from being due to a conflicting reshape, to being due to resync_max = 0. So introduce a new state: (curr_resync == 3) to reflect this, make sure it is visible both via /proc/mdstat and via the "sync_completed" sysfs attribute, and ensure that the event transition from one delay state to the other is properly notified. Signed-off-by: NeilBrown <neilb@suse.de>
| * md/raid5: be careful not to resize_stripes too big.NeilBrown2012-10-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When a RAID5 is reshaping, conf->raid_disks is increased before mddev->delta_disks becomes zero. This can result in check_reshape calling resize_stripes with a number that is too large. This particularly happens when md_check_recovery calls ->check_reshape(). If we use ->previous_raid_disks, we don't risk this. Signed-off-by: NeilBrown <neilb@suse.de>
| * md: make sure manual changes to recovery checkpoint are saved.NeilBrown2012-10-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | If you make an array bigger but suppress resync of the new region with mdadm --grow /dev/mdX --size=max --assume-clean then stop the array before anything is written to it, the effect of the "--assume-clean" is lost and the array will resync the new space when restarted. So ensure that we update the metadata in the case. Reported-by: Sebastian Riemer <sebastian.riemer@profitbricks.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md/raid10: use correct limit variableDan Carpenter2012-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Clang complains that we are assigning a variable to itself. This should be using bad_sectors like the similar earlier check does. Bug has been present since 3.1-rc1. It is minor but could conceivably cause corruption or other bad behaviour. Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md: writing to sync_action should clear the read-auto state.NeilBrown2012-10-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases array are started in 'read-auto' state where in nothing gets written to any device until the array is written to. The purpose of this is to make accidental auto-assembly of the wrong arrays less of a risk, and to allow arrays to be started to read suspend-to-disk images without actually changing anything (as might happen if the array were dirty and a resync seemed necessary). Explicitly writing the 'sync_action' for a read-auto array currently doesn't clear the read-auto state, so the sync action doesn't happen, which can be confusing. So allow any successful write to sync_action to clear any read-auto state. Reported-by: Alexander Kühn <alexander.kuehn@nagilum.de> Signed-off-by: NeilBrown <neilb@suse.de>
| * Subject: [PATCH] md:change resync_mismatches to atomic64_t to avoid racesJianpeng Ma2012-10-115-8/+9
| | | | | | | | | | | | | | | | Now that multiple threads can handle stripes, it is safer to use an atomic64_t for resync_mismatches, to avoid update races. Signed-off-by: Jianpeng Ma <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md/raid5: make sure to_read and to_write never go negative.NeilBrown2012-10-111-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to_read and to_write are part of the result of analysing a stripe before handling it. Their use is to avoid some loops and tests if the values are known to be zero. Thus it is not a problem if they are a little bit larger than they should be. So decrementing them in handle_failed_stripe serves little value, and due to races it could cause some loops to be skipped incorrectly. So remove those decrements. Reported-by: "Jianpeng Ma" <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md: When RAID5 is dirty, force reconstruct-write instead of read-modify-write.Alexander Lyakas2012-10-111-3/+16
| | | | | | | | | | | | Signed-off-by: Alex Lyakas <alex@zadarastorage.com> Suggested-by: Yair Hershko <yair@zadarastorage.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md/raid5: protect debug message against NULL derefernce.NeilBrown2012-10-111-1/+1
| | | | | | | | | | | | | | | | | | The pr_debug in add_stripe_bio could race with something changing *bip, so it is best to hold the lock until after the pr_debug. Reported-by: "Jianpeng Ma" <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md/raid5: add some missing locking in handle_failed_stripe.NeilBrown2012-10-111-0/+2
| | | | | | | | | | | | | | | | | | We really should hold the stripe_lock while accessing 'toread' else we could race with add_stripe_bio and corrupt a list. Reported-by: "Jianpeng Ma" <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * MD: raid5 avoid unnecessary zero page for trimShaohua Li2012-10-111-18/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to avoid zero discarded dev page, because it's useless for discard. But if we don't zero it, another read/write hit such page in the cache and will get inconsistent data. To avoid zero the page, we don't set R5_UPTODATE flag after construction is done. In this way, discard write request is still issued and finished, but read will not hit the page. If the stripe gets accessed soon, we need reread the stripe, but since the chance is low, the reread isn't a big deal. Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * MD: raid5 trim supportShaohua Li2012-10-112-3/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Discard for raid4/5/6 has limitation. If discard request size is small, we do discard for one disk, but we need calculate parity and write parity disk. To correctly calculate parity, zero_after_discard must be guaranteed. Even it's true, we need do discard for one disk but write another disks, which makes the parity disks wear out fast. This doesn't make sense. So an efficient discard for raid4/5/6 should discard all data disks and parity disks, which requires the write pattern to be (A, A+chunk_size, A+chunk_size*2...). If A's size is smaller than chunk_size, such pattern is almost impossible in practice. So in this patch, I only handle the case that A's size equals to chunk_size. That is discard request should be aligned to stripe size and its size is multiple of stripe size. Since we can only handle request with specific alignment and size (or part of the request fitting stripes), we can't guarantee zero_after_discard even zero_after_discard is true in low level drives. The block layer doesn't send down correctly aligned requests even correct discard alignment is set, so I must filter out. For raid4/5/6 parity calculation, if data is 0, parity is 0. So if zero_after_discard is true for all disks, data is consistent after discard. Otherwise, data might be lost. Let's consider a scenario: discard a stripe, write data to one disk and write parity disk. The stripe could be still inconsistent till then depending on using data from other data disks or parity disks to calculate new parity. If the disk is broken, we can't restore it. So in this patch, we only enable discard support if all disks have zero_after_discard. If discard fails in one disk, we face the similar inconsistent issue above. The patch will make discard follow the same path as normal write request. If discard fails, a resync will be scheduled to make the data consistent. This isn't good to have extra writes, but data consistency is important. If a subsequent read/write request hits raid5 cache of a discarded stripe, the discarded dev page should have zero filled, so the data is consistent. This patch will always zero dev page for discarded request stripe. This isn't optimal because discard request doesn't need such payload. Next patch will avoid it. Signed-off-by: Shaohua Li <shli@fusionio.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md/bitmap:Don't use IS_ERR to judge alloc_page().Jianpeng Ma2012-10-111-6/+2
| | | | | | | | | | Signed-off-by: Jianpeng Ma <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * md/raid1: Don't release reference to device while handling read error.NeilBrown2012-10-111-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get a read error, we arrange for raid1d to handle it. Currently we release the reference on the device. This can result in conf->mirrors[read_disk].rdev being NULL in fix_read_error, if the device happens to get removed before the read error is handled. So instead keep the reference until the read error has been fully handled. Reported-by: hank <pyu@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * raid: replace list_for_each_continue_rcu with new interfaceMichael Wang2012-10-111-6/+3
| | | | | | | | | | | | | | | | | | | | This patch replaces list_for_each_continue_rcu() with list_for_each_entry_continue_rcu() to save a few lines of code and allow removing list_for_each_continue_rcu(). Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * DM RAID: Fix for "sync" directive ineffectivenessJonathan Brassow2012-10-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two table arguments that can be given to a DM RAID target that control whether the array is forced to (re)synchronize or skip initialization: "sync" and "nosync". When "sync" is given, we set mddev->recovery_cp to 0 in order to cause the device to resynchronize. This is insufficient if there is a bitmap in use, because the array will simply look at the bitmap and see that there is no recovery necessary. The fix is to skip over the loading of the superblocks when "sync" is given, causing new superblocks to be written that will force the array to go through initialization (i.e. synchronization). Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * DM RAID: Fix comparison of index and quantity for "rebuild" parameterJonathan Brassow2012-10-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | DM RAID: Fix comparison of index and quantity for "rebuild" parameter The "rebuild" parameter takes an index argument that starts counting from zero. The conditional used to validate the index was using '>' rather than '>=', leaving the door open for an index value that would be 1 too large. Reported-by: Neil Brown <neilb@suse.de> Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * DM RAID: Add rebuild capability for RAID10Jonathan Brassow2012-10-111-1/+33
| | | | | | | | | | | | | | | | | | | | | | DM RAID: Add code to validate replacement slots for RAID10 arrays RAID10 can handle 'copies - 1' failures for each mirror group. This code ensures the user has provided a valid array - one whose devices specified for rebuild do not exceed the amount of redundancy available. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
| * DM RAID: Move 'rebuild' checking code to its own functionJonathan Brassow2012-10-111-25/+50
| | | | | | | | | | | | | | | | | | | | | | | | DM RAID: Move chunk of code to it's own function The code that checks whether device replacements/rebuilds are possible given a specific RAID type is moved to it's own function. It will further expand when the code to check RAID10 is added. A separate function makes it easier to read. Signed-off-by: Jonathan Brassow <jbrassow@redhat.com> Signed-off-by: NeilBrown <neilb@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 06:54:41 +0100