This patch removes some unneeded checks of pointers being NULL before
calling kfree() on them.  kfree() handles NULL pointers just fine, checking
first is pointless.
Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Due to the use of write-behind, it is possible for md to write a page to
the bitmap file that is still completing writeback.  This is not allowed.

With this patch, we detect those cases and either force a sync write, or
back off and try later, as appropriate.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

1/ Must typecast int to (sector_t) before inverting or we
 might not invert enough bits.

2/ When "bitmap_offset" was added to mdp_superblock_1, we didn't increase
   the count of words-used (96 to 100).
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

currently, md updates all superblocks (one on each device) in series.  It
waits for one write to complete before starting the next.  This isn't a big
problem as superblock updates don't happen that often.

However it is neater to do it in parallel, and if the drives in the array have
gone to "sleep" after a period of idleness, then waking them is parallel is
faster (and someone else should be worrying about power drain).

Futher, we will need parallel superblock updates for a future patch which
keeps the intent-logging bitmap near the superblock.

Also remove the silly code that retired superblock updates 100 times.  This
simply never made sense.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This provides an alternate to storing the bitmap in a separate file.  The
bitmap can be stored at a given offset from the superblock.  Obviously the
creator of the array must make sure this doesn't intersect with data....
After is good for version-0.90 superblocks.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Before completing a 'write' the md superblock might need to be updated.
This is best done by the md_thread.

The current code schedules this up and queues the write request for later
handling by the md_thread.

However some personalities (Raid5/raid6) will deadlock if the md_thread
tries to submit requests to its own array.

So this patch changes things so the processes submitting the request waits
for the superblock to be written and then submits the request itself.

This fixes a recently-created deadlock in raid5/raid6
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When an array is degraded, bit in the intent-bitmap are never cleared.  So if
a recently failed drive is re-added, we only need to reconstruct the block
that are still reflected in the bitmap.

This patch adds support for this re-adding.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Otherwise it could have a random value and might BUG.  This fixes a BUG
during resync problem in raid1 introduced by the bitmap-based-intent-loggin
patches.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The logic here is wrong.  if fullsync is 0, it WILL BUG.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When looking for pages that need cleaning we skip pages that don't have
BITMAP_PAGE_CLEAN set.  But if it is the 'current' page we will have cleared
that bit ourselves, so skipping it is wrong.  So: move the 'skip this page'
inside 'if page != lastpage'.

Also fold call of file_page_offset into the one place where the value (bit) is
used.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Currently we don't wait for updates to the bitmap to be flushed to disk
properly.  The infrastructure all there, but it isn't being used....

A separate kernel thread (bitmap_writeback_daemon) is needed to wait for each
page as we cannot get callbacks when a page write completes.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- report sync_size properly  - need /2 to convert sectors to KB
- move everything over 2 spaces to allow proper spelling of
  "events cleared".
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A u64 is not an unsigned long long.  On power4 it is `long', and printk warns.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

As the array-wide clean bit (in the superblock) is set more agressively than
the bits in the bitmap are cleared, it is possible to have an array which is
clean despite there being bits set in the bitmap.

These bits will currently never get cleared, as they can only be cleared by a
resync pass, which never happens.

No, when reading bits from disk, be aware of whether the whole array is known
to be in sync, and act accordingly.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The debugging message printed the wrong pid, which didn't help remove bugs....
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

bitmap_daemon_work clears bits in the bitmap for blocks that haven't been
written to for a while.  It needs to be called regularly to make sure the
bitmap doesn't endup full of ones ....  but it wasn't.

So call it from the increasingly-inaptly-named md_check_recovery
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

1/ When init from disk, it is a BUG if there is nowhere
   to init from,
2/ use seq_path to print path in /proc/mdstat
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

With this patch, the intent to write to some block in the array can be logged
to a bitmap file.  Each bit represents some number of sectors and is set
before any update happens, and only cleared when all writes relating to all
sectors are complete.

After an unclean shutdown, information in this bitmap can be used to optimise
resync - only sectors which could be out-of-sync need to be updated.

Also if a drive is removed and then added back into an array, the recovery can
make use of the bitmap to optimise reconstruction.  This is not implemented in
this patch.

Currently the bitmap is stored in a file which must (obviously) be stored on a
separate device.

The patch only provided infrastructure.  It does not update any personalities
to bitmap intent logging.

Md arrays can still be used with no bitmap file.  This patch has minimal
impact on such arrays.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

1/ change the return value (which is number-of-sectors synced)
 from 'int' to 'sector_t'.
 The number of sectors is usually easily small enough to fit
 in an int, but if resync needs to abort, it may want to return
 the total number of remaining sectors, which could be large.
 Also errors cannot be returned as negative numbers now, so use
 0 instead
2/ Add a 'skipped' return parameter to allow the array to report
 that it skipped the sectors.  This allows md to take this into account
 in the speed calculations.
 Currently there is no important skipping, but the bitmap-based-resync
 that is coming will use this.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When md marks the superblock dirty before a write, it calls
generic_make_request (to write the superblock) from within
generic_make_request (to write the first dirty block), which could cause
problems later.

With this patch, the superblock write is always done by the helper thread, and
write request are delayed until that write completes.

Also, the locking around marking the array dirty and writing the superblock is
improved to avoid possible races.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

md_enter_safemode checks if it is time to mark the md superblock as 'clean'.
i.e.  if all writes have completed and a suitable delay has passed.

This is currently called from md_handle_safemode which in-turn is called
(almost) every time md_check_recovery is called, and from the end of
md_do_sync which causes the mddev->thread to run, which will always call
md_check_recovery as well.

So it doesn't need to be a separate function and fits quite well into
md_check_recovery.

The "almost" is because multipathd calls md_check_recovery but not
md_handle_safemode.  This is OK because the code from md_enter_safemode is a
no-op if mddev->safemode == 0, which it always is for a multipathd (providing
we don't allow it to be set to 2 on a signal...)
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Currently if add_new_disk is used to hot-add a drive to a degraded array,
recovery doesn't start ...  because we didn't tell it to.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

i.e.  missing or failed drives are moved to the end of the list.  The means
a 3 drive md array with the first drive missing can be shrunk to a two
drive array.  Currently that isn't possible.

Also, the "last_used" device number might be out-of-range after the number
of devices is reduced, so we set it to 0.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Several drivers miss filling in the access_align field.  So this patch has
them fill it in.
Signed-off-by: NJames Simmons <jsimmons@www.infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Shrink the stack when calling the drawing alignment functions.
Signed-off-by: NJames Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Improve the fonts for use with the framebuffer.

I've added all the characters marked 'FIXME' in the sun12x22 font and
created a 10x18 font (based on the sun12x22 font) and a 7x14 font (based
on the vga8x16 font).

This patch is non-intrusive, no options are enabled by default so most
users won't notice a thing.

I am placing my changes under the GPL, however, I've not seen any copyright
notices on the sun12x22 font and the vga8x16 font which I derived my new
fonts from so I don't know what the copyright status is.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add support for the Arc monochrome LCD board.

The board uses KS108 controllers to drive individual 64x64 LCD matrices.
The board can be paneled in a variety of setups such as 2x1=128x64,
4x4=256x256 and so on.  The board/host interface is through GPIO.
Signed-off-by: NJaya Kumar <jayalk@intworks.biz>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: <linux-fbdev-devel@lists.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Changed the tests in intelfb_set_par to check also the parameter
var.accel_flags.  If null, do nothing about ring buffers.

Now, the DirectFB i830 driver could nicely work even if intelfb is hw
accelerated.  Just change the /etc/fb.modes file to disable console hw
acceleration when starting a DirectFB app.
Signed-off-by: NSylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- Add voffset option to avoid conficts with Xorg i810 driver
Signed-off-by: NSylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Currently when going from vgacon to fbcon the VT screenbuffer are often
different sizes.  In the case when they are different sizes a new VT
screenbuffer is allocated and the contents are copied into the new buffer.

Currently the amount copied from VGA text memory to the new screenbuf is
the size of the framebuffer console.  If the framebuffer console new VT
screen buffer is greater than the VGA text memory size then we get some of
the VGA BIOS contents as well.

This patch will only allow you to copy up to the size of VGA text memory
now.  The rest is filled with erase characters.

Initial patch by Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: NJames Simmons <jsimmons@www.infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their
use in the framebuffer console.  The idea is instead move the pixmap
functionality below the accelerated functions intead of on top as the way
it is now.  If there is no objection please apply.  This is against Linus
latestr GIT tree.  Thank you.
Signed-off-by: NJames Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Can't use this fancy name, because it's used to generate a sysfs filename:

kobject_register failed for Intel(R) 830M/845G/852GM/855GM/865G/915G
 Framebuffer Driver (-13)
  [<c01bf8e3>] kobject_register+0x43/0x70
  [<c022dfe2>] bus_add_driver+0x52/0xa0
  [<c01c8c10>] pci_device_shutdown+0x0/0x20
  [<c01c8d71>] pci_register_driver+0x61/0x80
  [<c0387099>] intelfb_init+0x59/0x70
  [<c03787cc>] do_initcalls+0x2c/0xc0
  [<c0159025>] kern_mount+0x15/0x17
  [<c01002a0>] init+0x0/0x100
  [<c01002ca>] init+0x2a/0x100
  [<c0100f58>] kernel_thread_helper+0x0/0x18
  [<c0100f5d>] kernel_thread_helper+0x5/0x18

Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix the size passed to release_mem_region in an error path.

Also adjust the message printed when vesafb cannot load; the comment there
already says this must not be fatal, so the message should also not mention
the word 'abort' otherwise indicating a problem to worry about in the log.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NGerd Knorr <kraxel@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

s1d13xxxfb_remove() is referenced from s1d13xxxfb_probe(), which is marked
__devinit().  So s1d13xxxfb_remove() cannot be marked __devexit.

Does this all make sense?  Clearly the __devexit section will still be in
core when the __devinit code is run, if the driver was loaded as a module.

But I suppose that if the driver is statically linked, the __devexit section
might be dropped early in boot.  Still, we wouldn't drop __devexit prior to
initcall completion, at which point the __devinit code has all been run
anyway.

verdict: this code was legal and made sense.  Is this a generic problem, or an
arm-specific problem?

  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
`.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o

Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I don't see any reason why the framebuffer should need to be cleared,
and it makes Tux vanish.

Cc: <linux-fbdev-devel@lists.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch fixes a race in the command reference counting logic by putting
spinlocks around kobject_put() in the command_put function.

- Also added debug messages.

- Changed a memcpy to memcpy_fromio since we are reading from io space.
Signed-off-by: NMax Asbock <masbock@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>