Instead of starting with the error details, report the decoded, readable
error type first.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

It is very useful to have the family/model/stepping with the reported
error so dump it. This saves us asking the bug reporter about it.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Having the functional unit names in each bank decode is only misleading
as this code supports multiple families and there's no guarantee the
mapping between FUs and MCE banks will stay the same.

And also, knowing the functional unit name doesn't help much since you
end up looking at the respective BKDG anyway.

So drop all FU references and use the MC bank numbers instead.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This removes an open coded simple_open() function and replaces file
operations references to the function with simple_open() instead.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This removes an open coded simple_open() function and replaces file
operations references to the function with simple_open() instead.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This is the complement to previous commit "EDAC: Fix csrow size
reported in sysfs". This fixes the memory controller size reporting on
csrow-based memory controllers. The csrow size is already combined for
both channels. Without this patch memory size is reported doubled.
Signed-off-by: NJosh Hunt <johunt@akamai.com>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

On csrow-based memory controllers, we combine the csrow size from both
channels and there's no need to do that again in csrow_size_show which
leads to double the size of a csrow.

Fix it.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Initialize the mem_ctl_info descriptor of a csrow properly.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The first flag is ->csbased and will be used in common EDAC code later.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Make sure code pays attention to K8 having only one DCT, reformat and
cleanup code, correct debug messages, remove unused code.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Instead of open-coding it, use the DBAM_DIMM macro in
amd64_csrow_nr_pages() which we have already.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This basically reverts 603adaf6 ("amd64_edac: fix K8 chip select
reporting") because it was a clumsy workaround for DIMM sizes reporting
on K8 which got superceded by a much more correct one with 41d8bfab
("amd64_edac: Improve DRAM address mapping") without removing the prior
one. Remove it now finally.
Reported-by: NJosh Hunt <johunt@akamai.com>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Rewrite CE/UE paths so that they use the same code and drop additional
code duplication in handle_ue. Add a struct err_info which collects
required info for the error reporting. This, in turn, helps slimming all
edac_mc_handle_error() calls down to one.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

All families report a valid error address when encountering a DRAM ECC
error so no need to check it.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

When injecting DRAM ECC errors over the F3xB[8,C] interface, the machine
does this by injecting the error in the next non-cached access. This
takes relatively long time on a normal system so that in order for us to
expedite it, we disable the caches around the injection.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Invert kstrtoul return value testing and win one indentation level.
Also, shorten up macro names so that the lines can fit into 80 cols. No
functional change.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

amd64_get_dram_hole_info: remove local variable 'base'.
sys_addr_to_dram_addr: do not clear local variable 'ret'. Also, sanitize
constants formatting.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

A reported error could look like this

[  226.178315] EDAC MC0: 1 CE  on mc#0csrow#0channel#0 (csrow:0 channel:0 page:0x427c0d offset:0xde0 grain:0 syndrome:0x1c6)

with two spaces back-to-back due to the msg argument of
edac_mc_handle_error being passed on empty by the specific drivers.
Handle that.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The tracepoint decodes the error type later anyway so remove a useless
assignment to the temporary p which gets overwritten later anyway.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Only levels [0:4] are allowed so enforce that. Also, while at it,
massage Kconfig text and add valid debug levels range to the module
parameter description.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Currently, we unconditionally enable PCI polling and we don't look at
the edac_op_state module parameter. Make this dependent on the parameter
setting supplied on the command line.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

dev_pm_qos_add_request() can return 0, 1, or a negative error code,
therefore the correct error test is "if (error < 0)." Checking just for
non-zero return code leads to erroneous setting of the req->dev pointer
to NULL, which then leads to a repeated call to
dev_pm_qos_add_ancestor_request() in st1232_ts_irq_handler(). This in turn
leads to an Oops, when the I2C host adapter is unloaded and reloaded again
because of the inconsistent state of its QoS request list.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

fix bug where a register which was only meant to be read in 578xx/57712
devices causes a bogus error message to be logged when read from other
devices.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch reverts b01af457.

The original patch was tested with emulated hardware. Real
hardware chokes.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=47041Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Hi Jens,

Another tiny patch.

Removed __packed before the struct smart_attr and added __packed at end of
the structure to fix padding issue.
Signed-off-by: NSelvan Mani  <smani@micron.com>
Signed-off-by: NAsai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Calling the request handler directly on a plugged queue defeats
the performance improvements provided by the plugging mechanism.
Use the __blk_run_queue function instead of calling the request
handler directly, so that we don't interfere with the block
layer's ability to plug the queue.
Signed-off-by: NEd Cashin <ecashin@coraid.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

The dereference to port should be moved below the NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

If we're building a 32-bit kernel and CONFIG_LBADF isn't set,
sector_t is 32-bits wide. The shifts by 32 and 40 are thus
larger than we support.

Cast the sector offset to a u64 to avoid these warnings.
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Previous commit use value 3 for erasemode mask.
Changing the mask to correct value to 2
Signed-off-by: NSelvan Mani <smani@micron.com>
Signed-off-by: NAsai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Earlier lba address was assigned directly to lba_low and lba_low_ex,
which would result in a different number (bytes reversed) in
big-endian systems. Now assigning lba address byte-by-byte to fis.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSelvan Mani <smani@micron.com>
Signed-off-by: NAsai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

The mtip driver lifted this code from elsewhere and then added a special
handling check for SEC_ERASE_UNIT. If the caller tries to do a security
erase but passes no output data for the command then outbuf is not
allocated and the driver duly explodes.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NSelvan Mani <smani@micron.com>
Signed-off-by: NAsai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Request based dm attempts to re-run the request queue off the
request completion path. If used with a driver that potentially does
end_io from its request_fn, we could deadlock trying to recurse
back into request dispatch. Fix this by punting the request queue
run to kblockd.

Tested to fix a quickly reproducible deadlock in such a scenario.

Cc: stable@kernel.org
Acked-by: NAlasdair G Kergon <agk@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

We need to first destroy the floppy_wq workqueue before cleaning up
the queue. Otherwise we might race with still pending work with the
workqueue, but all the block queue already gone. This might lead to
various oopses, such as

 CPU 0
 Pid: 6, comm: kworker/u:0 Not tainted 3.7.0-rc4 #1 Bochs Bochs
 RIP: 0010:[<ffffffff8134eef5>]  [<ffffffff8134eef5>] blk_peek_request+0xd5/0x1c0
 RSP: 0000:ffff88000dc7dd88  EFLAGS: 00010092
 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff88000f602688 RSI: ffffffff81fd95d8 RDI: 6b6b6b6b6b6b6b6b
 RBP: ffff88000dc7dd98 R08: ffffffff81fd95c8 R09: 0000000000000000
 R10: ffffffff81fd9480 R11: 0000000000000001 R12: 6b6b6b6b6b6b6b6b
 R13: ffff88000dc7dfd8 R14: ffff88000dc7dfd8 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000000 CR3: 0000000001e11000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process kworker/u:0 (pid: 6, threadinfo ffff88000dc7c000, task ffff88000dc5ecc0)
 Stack:
  0000000000000000 0000000000000000 ffff88000dc7ddb8 ffffffff8134efee
  ffff88000dc7ddb8 0000000000000000 ffff88000dc7dde8 ffffffff814aef3c
  ffffffff81e75d80 ffff88000dc0c640 ffff88000fbfb000 ffffffff814aed90
 Call Trace:
  [<ffffffff8134efee>] blk_fetch_request+0xe/0x30
  [<ffffffff814aef3c>] redo_fd_request+0x1ac/0x400
  [<ffffffff814aed90>] ? start_motor+0x130/0x130
  [<ffffffff8106b526>] process_one_work+0x136/0x450
  [<ffffffff8106af65>] ? manage_workers+0x205/0x2e0
  [<ffffffff8106bb6d>] worker_thread+0x14d/0x420
  [<ffffffff8106ba20>] ? rescuer_thread+0x1a0/0x1a0
  [<ffffffff8107075a>] kthread+0xba/0xc0
  [<ffffffff810706a0>] ? __kthread_parkme+0x80/0x80
  [<ffffffff818b553a>] ret_from_fork+0x7a/0xb0
  [<ffffffff810706a0>] ? __kthread_parkme+0x80/0x80
 Code: 0f 84 c0 00 00 00 83 f8 01 0f 85 e2 00 00 00 81 4b 40 00 00 80 00 48 89 df e8 58 f8 ff ff be fb ff ff ff
 fe ff ff <49> 8b 1c 24 49 39 dc 0f 85 2e ff ff ff 41 0f b6 84 24 28 04 00
 RIP  [<ffffffff8134eef5>] blk_peek_request+0xd5/0x1c0
  RSP <ffff88000dc7dd88>
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Tested-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Properly terminate the DMA transfer in case the DMA PIO transfer
or setup fails for any reason.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

Do not fail if dpll4_m4_ck is missing. The clock is not there on omap24xx,
so this should not be a hard error.

The patch retains the functionality before the commit 185bae10 (OMAPDSS:
DSS: Cleanup cpu_is_xxxx checks).
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When a write to a replacement device completes, we carefully
and correctly found the rdev that the write actually went to
and the blithely called rdev_dec_pending on the primary rdev,
even if this write was to the replacement.

This means that any writes to an array while a replacement
was ongoing would cause the nr_pending count for the primary
device to go negative, so it could never be removed.

This bug has been present since replacement was introduced in
3.3, so it is suitable for any -stable kernel since then.
Reported-by: N"George Spelvin" <linux@horizon.com>
Cc: stable@vger.kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

When a replacement operation completes there is a small window
when the original device is marked 'faulty' and the replacement
still looks like a replacement.  The faulty should be removed and
the replacement moved in place very quickly, bit it isn't instant.

So the code write out to the array must handle the possibility that
the only working device for some slot in the replacement - but it
doesn't.  If the primary device is faulty it just gives up.  This
can lead to corruption.

So make the code more robust: if either  the primary or the
replacement is present and working, write to them.  Only when
neither are present do we give up.

This bug has been present since replacement was introduced in
3.3, so it is suitable for any -stable kernel since then.
Reported-by: N"George Spelvin" <linux@horizon.com>
Cc: stable@vger.kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

Only compile time tested, noticed nv50_fence_create was never used,
so fix this. This will probably fix vblank on nv50 cards.

Hopefully this is still in time for 3.7 final release.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

commit 9e444768
    MD: raid5 avoid unnecessary zero page for trim

change raid5 to clear R5_Discard when the complete request is
handled rather than when submitting the per-device discard request.
However it did not clear R5_Discard for the parity device.

This means that if the stripe_head was reused before it expired from
the cache, the setting would be wrong and a hang would result.

Also if the R5_Uptodate bit happens to be set, R5_Discard again
won't be cleared.  But R5_Uptodate really should be clear at this point.

So make sure R5_Discard is cleared in all cases, and clear
R5_Uptodate when a 'discard' completes.
Signed-off-by: NNeilBrown <neilb@suse.de>

stripe_handle.

The chunk of code in stripe_handle which responds to a
*_result value in reconstruct_state is really the completion
of some processing that happened outside of handle_stripe
(possibly asynchronously) and so should be one of the first
things done in handle_stripe().

After the next patch it will be important that it happens before
handle_stripe_clean_event(), as that will clear some dev->flags
bit that this code tests.
Signed-off-by: NNeilBrown <neilb@suse.de>