... instead of manual device_create_file() and device_remove_file()
calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: Johannes Thumshirn <johannes.thumshirn@men.de>
Link: http://lkml.kernel.org/r/1423046938-18111-7-git-send-email-tiwai@suse.deSigned-off-by: NBorislav Petkov <bp@suse.de>

... instead of manual device_create_file() and device_remove_file()
calls.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
[ Add NULL terminator to i7core_dev_attrs[] caught by the build robot. ]
Reported-by: NHuang Ying <ying.huang@intel.com>
Link: http://lkml.kernel.org/r/1423046938-18111-6-git-send-email-tiwai@suse.deSigned-off-by: NBorislav Petkov <bp@suse.de>

... instead of possibly uninitialized return value.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: http://lkml.kernel.org/r/1423046938-18111-5-git-send-email-tiwai@suse.de
[ Add a commit message, albeit a small one. ]
Signed-off-by: NBorislav Petkov <bp@suse.de>

Instead of calling device_create_file() and device_remove_file()
manually, pass the static attribute groups with the new
edac_mc_add_mc_with_groups(). The conditional creation of inject sysfs
files is done by a proper is_visible callback.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: http://lkml.kernel.org/r/1423046938-18111-4-git-send-email-tiwai@suse.deSigned-off-by: NBorislav Petkov <bp@suse.de>

Add edac_mc_add_mc_with_groups() for initializing the mem_ctl_info
object with the optional attribute groups.  This allows drivers to
pass additional sysfs entries without manual (and racy)
device_create_file() and co calls.

edac_mc_add_mc() is kept as is, just calling edac_mc_add_with_groups()
with NULL groups.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: http://lkml.kernel.org/r/1423046938-18111-3-git-send-email-tiwai@suse.deSigned-off-by: NBorislav Petkov <bp@suse.de>

Instead of manual calls of device_create_file() and
device_remove_file(), use static attribute groups with proper
is_visible callbacks for managing the sysfs entries.

This simplifies the code a lot and avoids the possible races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: http://lkml.kernel.org/r/1423046938-18111-2-git-send-email-tiwai@suse.deSigned-off-by: NBorislav Petkov <bp@suse.de>

The pci_dev_put() function tests whether its argument is NULL and thus
the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Link: http://lkml.kernel.org/r/54CFC12C.9010002@users.sourceforge.netSigned-off-by: NBorislav Petkov <bp@suse.de>

Upstream checkpatch now requires this.
Reviewed-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>

Signed-off-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: NRoland Dreier <roland@purestorage.com>

For, !HAVE_CLK the clk API returns a NULL cookie. Rework the
initialization code to handle that. If clk_get_rate() delivers 0, we use
the fallback mechanisms. The patch is pretty easy when ignoring white
space issues (git diff -b).
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NMax Filippov <jcmvbkbc@gmail.com>

The exynos_tmu_data() function should on entrance test not only for valid
data pointer, but also for data->tmu_read one.
It is important, since afterwards it is dereferenced to get temperature code.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Tested-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>

Code that does this:

	if (!(d_unhashed(tmp) && tmp->d_inode)) {
		...
		simple_unlink(parent->d_inode, tmp);
	}

is broken because:

	!(d_unhashed(tmp) && tmp->d_inode)

is equivalent to:

	!d_unhashed(tmp) || !tmp->d_inode

so it is possible to get into simple_unlink() with tmp->d_inode == NULL.

simple_unlink(), however, assumes tmp->d_inode cannot be NULL.

I think that what was meant is this:

	!d_unhashed(tmp) && tmp->d_inode

and that the logical-not operator or the final close-bracket was misplaced.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Bryan O'Sullivan <bos@pathscale.com>
cc: Roland Dreier <rolandd@cisco.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

We don't really need to recalculate the effective rate of a clock when a
per-user clock is removed, if the constraints of the later aren't
limiting the requested rate.

This was causing problems with clocks that never had a rate set before,
as rate_req would be zero. Though this could be considered a bug in the
implementation of those clocks, this should be checked somewhere else.

Fixes: 1c8e6004 ("clk: Add rate constraints to clocks")
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NMichael Turquette <mturquette@linaro.org>

From a locking point of view it is safe to check waiting_msg without
a lock, but there is a memory ordering issue that causes it to
possibly not be set right when viewed from another processor.  We are
already claiming a lock right after that, move the check to inside
the lock to enforce the memory ordering.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The seq_printf like functions will soon be changed to return void.

Convert these uses to check seq_has_overflowed instead.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Instead of manual calls of device_create_file() and
device_remove_file(), implement the condition in is_visible callback
for the attribute group and put these entries to the group, too.
This simplifies the code and avoids the possible races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

This adds a loop through the elements in the linked list, recv_msgs using
list_for_entry_safe in order to free messages in this list.  In addition
we are using the safe version of this marco in order to prevent use after
bugs related to deleting the element we are on currently by holding a
pointer to the next element after the current one we are on and freeing
with the function, ipmi_free_recv_msg internally in this loop.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

A new harmless warning has come up on ARM builds with gcc-4.9:

drivers/char/ipmi/ipmi_msghandler.c: In function 'smi_send.isra.11':
include/linux/spinlock.h:372:95: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
  raw_spin_unlock_irqrestore(&lock->rlock, flags);
                                                                                               ^
drivers/char/ipmi/ipmi_msghandler.c:1490:16: note: 'flags' was declared here
  unsigned long flags;
                ^

This could be worked around by initializing the 'flags' variable, but it
seems better to rework the code to avoid this.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 7ea0ed2b ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

As part of the internal y2038 cleanup, this patch removes
timespec usage in the ipmi driver, replacing it timespec64

Cc: openipmi-developer@lists.sourceforge.net
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NCorey Minyard <minyard@mvista.com>

The driver uses #ifdef DEBUG_TIMING in order to conditionally print out
timestamped debug messages. Unfortunately it adds the ifdefs all over the
usage sites.

This patch cleans it up by adding a debug_timestamp() function which
is compiled out if DEBUG_TIMING isn't present. This cleans up all
the ugly ifdefs in the function logic.

Cc: openipmi-developer@lists.sourceforge.net
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NCorey Minyard <minyard@mvista.com>

Removes a no longer needed FIXME comment in the function,acpi_gpe_irq_setup
for the file,ipmi_si_intf.c. This comment is no longer needed as clearly we
are passing the correct level of  ACPI_GPE_LEVEL_TRIGGERED to the installer
function,acpi_install_gpe_handler due to no breakage after years of using
this ACPI level in the function,acpi_install_gpe_handler.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit or error. This is obsolete meanwhile, the core will do it.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

There can't be more than a few IPMI messages allocated at any one time,
so converting the messages to slabs would be a waste.  So just remove
the FIXME.
Suggested-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

This makes all sync commands uninterruptible and schedules without timeout
so the controller either has to post a completion or the timeout recovery
fails the command. This fixes potential memory or data corruption from
a command timing out too early or woken by a signal. Previously any DMA
buffers mapped for that command would have been released even though we
don't know what the controller is planning to do with those addresses.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

We don't track queues in a llist, subscribe to hot-cpu notifications,
or internally retry commands. Delete the unused artifacts.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

It should be a logical bitwise AND, not conditional.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

The driver has to end unreturned commands at some point even if the
controller has not provided a completion. The driver tried to be safe by
deleting IO queues prior to ending all unreturned commands. That should
cause the controller to internally abort inflight commands, but IO queue
deletion request does not have to be successful, so all bets are off. We
still have to make progress, so to be extra safe, this patch doesn't
clear a queue to release the dma mapping for a command until after the
pci device has been disabled.

This patch removes the special handling during device initialization
so controller recovery can be done all the time. This is possible since
initialization is not inlined with pci probe anymore.
Reported-by: NNilish Choudhury <nilesh.choudhury@oracle.com>
Signed-off-by: NKeith Busch <keith.busch@intel.com>

This performs the longest parts of nvme device probe in scheduled work.
This speeds up probe significantly when multiple devices are in use.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

This creates a new class type for nvme devices to register their
management character devices with. This is so we do not rely on miscdev
to provide enough minors for as many nvme devices some people plan to
use. The previous limit was approximately 60 NVMe controllers, depending
on the platform and kernel. Now the limit is 1M, which ought to be enough
for anybody.

Since we have a new device class, it makes sense to attach the block
devices under this as well, so part of this patch moves the management
handle initialization prior to the namespaces discovery.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

The original translation created collisions on Inquiry VPD 83 for many
existing devices. Newer specifications provide other ways to translate
based on the device's version can be used to create unique identifiers.

Version 1.1 provides an EUI64 field that uniquely identifies each
namespace, and 1.2 added the longer NGUID field for the same reason.
Both follow the IEEE EUI format and readily translate to the SCSI device
identification EUI designator type 2h. For devices implementing either,
the translation will use this type, defaulting to the EUI64 8-byte type if
implemented then NGUID's 16 byte version if not. If neither are provided,
the 1.0 translation is used, and is updated to use the SCSI String format
to guarantee a unique identifier.

Knowing when to use the new fields depends on the nvme controller's
revision. The NVME_VS macro was not decoding this correctly, so that is
fixed in this patch and moved to a more appropriate place.

Since the Identify Namespace structure required an update for the NGUID
field, this patch adds the remaining new 1.2 fields to the structure.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

Adds support for NVMe metadata formats and exposes block devices for
all namespaces regardless of their format. Namespace formats that are
unusable will have disk capacity set to 0, but a handle to the block
device is created to simplify device management. A namespace is not
usable when the format requires host interleave block and metadata in
single buffer, has no provisioned storage, or has better data but failed
to register with blk integrity.

The namespace has to be scanned in two phases to support separate
metadata formats. The first establishes the sector size and capacity
prior to invoking add_disk. If metadata is required, the capacity will
be temporarilly set to 0 until it can be revalidated and registered with
the integrity extenstions after add_disk completes.

The driver relies on the integrity extensions to provide the metadata
buffer. NVMe requires this be a single physically contiguous region,
so only one integrity segment is allowed per command. If the metadata
is used for T10 PI, the driver provides mappings to save and restore
the reftag physical block translation. The driver provides no-op
functions for generate and verify if metadata is not used for protection
information. This way the setup is always provided by the block layer.

If a request does not supply a required metadata buffer, the command
is failed with bad address. This could only happen if a user manually
disables verify/generate on such a disk. The only exception to where
this is okay is if the controller is capable of stripping/generating
the metadata, which is possible on some types of formats.

The metadata scatter gather list now occupies the spot in the nvme_iod
that used to be used to link retryable IOD's, but we don't do that
anymore, so the field was unused.
Signed-off-by: NKeith Busch <keith.busch@intel.com>

We currently read the information about idle states from the DT
so as to populate the cpuidle table. Use those APIs to read from
the DT that can avoid endianness conversions of the property values
in the cpuidle driver.
Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

IOSF_MBI is tristate. Baytrail driver isn't.
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Acked-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This converts the rbd driver to use the blk-mq infrastructure.  Except
for switching to a per-request work item this is almost mechanical.

This was tested by Alexandre DERUMIER in November, and found to give
him 120000 iops, although the only comparism available was an old
3.10 kernel which gave 80000iops.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NAlex Elder <elder@linaro.org>
[idryomov@gmail.com: context, blk_mq_init_queue() EH]
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>

If the clone is resized down to 0, it becomes standalone.  If such
resize is carried over while an image is mapped we would detect this
and call rbd_dev_parent_put() which means "let go of all parent state,
including the spec(s) of parent images(s)".  This leads to a mismatch
between "rbd info" and sysfs parent fields, so a fix is in order.

    # rbd create --image-format 2 --size 1 foo
    # rbd snap create foo@snap
    # rbd snap protect foo@snap
    # rbd clone foo@snap bar
    # DEV=$(rbd map bar)
    # rbd resize --allow-shrink --size 0 bar
    # rbd resize --size 1 bar
    # rbd info bar | grep parent
            parent: rbd/foo@snap

Before:

    # cat /sys/bus/rbd/devices/0/parent
    (no parent image)

After:

    # cat /sys/bus/rbd/devices/0/parent
    pool_id 0
    pool_name rbd
    image_id 10056b8b4567
    image_name foo
    snap_id 2
    snap_name snap
    overlap 0
Signed-off-by: NIlya Dryomov <idryomov@redhat.com>
Reviewed-by: NJosh Durgin <jdurgin@redhat.com>
Reviewed-by: NAlex Elder <elder@linaro.org>

header_rwsem should be released on errors.  Also remove useless
rbd_dev->mapping.size != rbd_dev->header.image_size test.
Signed-off-by: NIlya Dryomov <idryomov@redhat.com>

It's been largely superseded by dup_token() and unused for over
2 years, identified by cppcheck.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
[idryomov@redhat.com: changelog]
Signed-off-by: NIlya Dryomov <idryomov@redhat.com>

Commit 32726d2d ("ARM: SAMSUNG: Remove legacy clock code")
already removed the callback pointer, but there was one remaining
user:

drivers/cpufreq/s3c24xx-cpufreq.c: In function 's3c_cpufreq_resume_clocks':
drivers/cpufreq/s3c24xx-cpufreq.c:149:14: error: 'struct s3c_cpufreq_info' has no member named 'resume_clocks'
  cpu_cur.info->resume_clocks();
              ^
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 32726d2d ("ARM: SAMSUNG: Remove legacy clock code")
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: 3.17+ <stable@vger.kernel.org> # v3.17+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
are marked init but are called from a context that might be run after
the __init sections are discarded, as the compiler points out:

WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()

This removes the __init markings.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Intel's Quark X1000 SoC contains a set of registers called
Isolated Memory Regions. IMRs are accessed over the IOSF mailbox
interface. IMRs are areas carved out of memory that define
read/write access rights to the various system agents within the
Quark system. For a given agent in the system it is possible to
specify if that agent may read or write an area of memory
defined by an IMR with a granularity of 1 KiB.

Quark_SecureBootPRM_330234_001.pdf section 4.5 details the
concept of IMRs quark-x1000-datasheet.pdf section 12.7.4 details
the implementation of IMRs in silicon.

eSRAM flush, CPU Snoop write-only, CPU SMM Mode, CPU non-SMM
mode, RMU and PCIe Virtual Channels (VC0 and VC1) can have
individual read/write access masks applied to them for a given
memory region in Quark X1000. This enables IMRs to treat each
memory transaction type listed above on an individual basis and
to filter appropriately based on the IMR access mask for the
memory region. Quark supports eight IMRs.

Since all of the DMA capable SoC components in the X1000 are
mapped to VC0 it is possible to define sections of memory as
invalid for DMA write operations originating from Ethernet, USB,
SD and any other DMA capable south-cluster component on VC0.
Similarly it is possible to mark kernel memory as non-SMM mode
read/write only or to mark BIOS runtime memory as SMM mode
accessible only depending on the particular memory footprint on
a given system.

On an IMR violation Quark SoC X1000 systems are configured to
reset the system, so ensuring that the IMR memory map is
consistent with the EFI provided memory map is critical to
ensure no IMR violations reset the system.

The API for accessing IMRs is based on MTRR code but doesn't
provide a /proc or /sys interface to manipulate IMRs. Defining
the size and extent of IMRs is exclusively the domain of
in-kernel code.

Quark firmware sets up a series of locked IMRs around pieces of
memory that firmware owns such as ACPI runtime data. During boot
a series of unlocked IMRs are placed around items in memory to
guarantee no DMA modification of those items can take place.
Grub also places an unlocked IMR around the kernel boot params
data structure and compressed kernel image. It is necessary for
the kernel to tear down all unlocked IMRs in order to ensure
that the kernel's view of memory passed via the EFI memory map
is consistent with the IMR memory map. Without tearing down all
unlocked IMRs on boot transitory IMRs such as those used to
protect the compressed kernel image will cause IMR violations and system reboots.

The IMR init code tears down all unlocked IMRs and sets a
protective IMR around the kernel .text and .rodata as one
contiguous block. This sanitizes the IMR memory map with respect
to the EFI memory map and protects the read-only portions of the
kernel from unwarranted DMA access.
Tested-by: NOng, Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: NBryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: NAndy Shevchenko <andy.schevchenko@gmail.com>
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
Reviewed-by: NOng, Boon Leong <boon.leong.ong@intel.com>
Cc: andy.shevchenko@gmail.com
Cc: dvhart@infradead.org
Link: http://lkml.kernel.org/r/1422635379-12476-2-git-send-email-pure.logic@nexus-software.ieSigned-off-by: NIngo Molnar <mingo@kernel.org>