summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* rtc: dm355evm: set rangeAlexandre Belloni2019-04-041-0/+1
| | | | | | The MSP430 has a 32bit second counter. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: dm355evm: convert to devm_rtc_allocate_deviceAlexandre Belloni2019-04-041-7/+6
| | | | | | This allows further improvement of the driver. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: goldfish: convert to SPDX identifierAlexandre Belloni2019-04-041-10/+1
| | | | | | Use SPDX-License-Identifier instead of a verbose license text Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: goldfish: switch to rtc_time64_to_tm/rtc_tm_to_time64Alexandre Belloni2019-04-041-19/+8
| | | | | | | This RTC handles dates after 2106 (up to July 2554), call the 64bit versions of rtc_tm time conversion. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: goldfish: allow building on more than MIPSAlexandre Belloni2019-04-042-1/+3
| | | | | | | Goldfish can be ARM or x86, allow building the driver for more than just MIPS. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: goldfish: sort headersAlexandre Belloni2019-04-041-1/+1
| | | | | | Sort headers alphabetically. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: goldfish: add rangeAlexandre Belloni2019-04-041-0/+1
| | | | | | This RTC has a 64bit nanosecond counter. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: goldfish: convert to devm_rtc_allocate_deviceAlexandre Belloni2019-04-041-4/+4
| | | | | | This allows further improvement of the driver. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: use .set_timeAlexandre Belloni2019-04-041-3/+3
| | | | | | Use .set_time instead of the deprecated .set_mmss. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: switch to rtc_time64_to_tm/rtc_tm_to_time64Alexandre Belloni2019-04-041-5/+3
| | | | | | | Call the 64bit versions of rtc_tm time conversion as the range is enforced by the core. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: stop caching alarm_timeAlexandre Belloni2019-04-041-4/+3
| | | | | | | There is no point in caching alarm_time for .read_alarm because .read_alarm is only called at boo time and thus alarm_time is always 0. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: correct checkpatch issuesAlexandre Belloni2019-04-041-7/+7
| | | | | | Correct trivial whitespace issues. Also sort the headers. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: convert to SPDX identifierAlexandre Belloni2019-04-041-14/+1
| | | | | | Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: set rangeAlexandre Belloni2019-04-041-0/+1
| | | | | | CCVR is a 32bit second counter. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: xgene: fix possible race conditionAlexandre Belloni2019-04-041-7/+11
| | | | | | | | | | | The IRQ is requested before the struct rtc is allocated and registered, but this struct is used in the IRQ handler. This may lead to a NULL pointer dereference. Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc struct before requesting the IRQ. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: test: do not use assignment in if conditionAlexandre Belloni2019-04-041-1/+2
| | | | | | | Fix checkpatch error: drivers/rtc/rtc-test.c:155: ERROR: do not use assignment in if condition Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: 88pm80x: convert to SPDX identifierAlexandre Belloni2019-04-041-13/+1
| | | | | | Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ab-b5ze-s3: correct checkpatch issuesAlexandre Belloni2019-04-041-18/+16
| | | | | | Correct trivial whitespace and split strings issues. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: core: correct trivial checkpatch warningsAlexandre Belloni2019-04-048-90/+93
| | | | | | | Correct trivial checkpatch warnings, mostly whitespace issues and unbalanced braces. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: x1205: Add DT probing supportLinus Walleij2019-04-041-0/+7
| | | | | | | | | This makes it possible to probe the X1205 RTC from the device tree. This is needed when adding device tree boot support for the IXP4xx-based NSLU2 which has this RTC. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: da9063: convert header to SPDXWolfram Sang2019-04-041-11/+3
| | | | | | | | Covnert the header of the source file to SPDX. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: omap: let the core handle rangeAlexandre Belloni2019-04-041-16/+6
| | | | | | | | Let the core handle the RTC range instead of open coding it. Tested-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: mv: add rangeAlexandre Belloni2019-04-041-2/+5
| | | | | | | | This RTC handles time from 2000-01-01 00:00:00 to 2099-12-31 23:59:59 with a weird rollover to 2000-06-23 00:00:00. Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: mv: convert to devm_rtc_allocate_deviceAlexandre Belloni2019-04-041-10/+11
| | | | | | | This allows further improvement of the driver. Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: mv: convert to SPDX identifierAlexandre Belloni2019-04-041-4/+1
| | | | | | | Use SPDX-License-Identifier instead of a verbose license text. Reviewed-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: convert core to SPDX identifierAlexandre Belloni2019-03-189-45/+16
| | | | | | | Use SPDX-License-Identifier instead of a verbose license text. Also fix the block comment alignment. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ab-b5ze-s3: remove unnecessary checkAlexandre Belloni2019-03-181-10/+8
| | | | | | | The core already checks that the alarm is set in the future. IT is not necessary to do it again in the driver. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ab-b5ze-s3: convert to SPDX identifierAlexandre Belloni2019-03-181-9/+1
| | | | | | Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ab-b5ze-s3: switch to rtc_time64_to_tm/rtc_tm_to_time64Alexandre Belloni2019-03-181-28/+9
| | | | | | | Call the 64bit versions of rtc_time_to_tm as the range is enforced by the core. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ab-b5ze-s3: remove unnecessary gotosAlexandre Belloni2019-03-181-55/+38
| | | | | | Rework error handling to remove unnecessary gotos. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: ab-b5ze-s3: remove mutexAlexandre Belloni2019-03-181-17/+2
| | | | | | | The rtc_ops are already called with the RTC mutex locked so there is no need to have a separate lock, unless it is used in the irq handler. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: zynqmp: convert to SPDX identifierAlexandre Belloni2019-03-181-12/+1
| | | | | | Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: abx80x: remove useless .removeAlexandre Belloni2019-03-181-6/+0
| | | | | | .remove is empty, remove it. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: abx80x: use rtc_add_groupAlexandre Belloni2019-03-181-26/+6
| | | | | | | Use rtc_add_group to add the sysfs group in a race free manner. This has the side effect of moving the files to their proper location. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* rtc: abx80x: convert to SPDX identifierAlexandre Belloni2019-03-181-4/+1
| | | | | | Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
* Merge tag 'for-linus-5.1b-rc1b-tag' of ↵Linus Torvalds2019-03-171-1/+4
|\ | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fix from Juergen Gross: "A fix for a Xen bug introduced by David's series for excluding ballooned pages in vmcores" * tag 'for-linus-5.1b-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/balloon: Fix mapping PG_offline pages to user space
| * xen/balloon: Fix mapping PG_offline pages to user spaceDavid Hildenbrand2019-03-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The XEN balloon driver - in contrast to other balloon drivers - allows to map some inflated pages to user space. Such pages are allocated via alloc_xenballooned_pages() and freed via free_xenballooned_pages(). The pfn space of these allocated pages is used to map other things by the hypervisor using hypercalls. Pages marked with PG_offline must never be mapped to user space (as this page type uses the mapcount field of struct pages). So what we can do is, clear/set PG_offline when allocating/freeing an inflated pages. This way, most inflated pages can be excluded by dumping tools and the "reused for other purpose" balloon pages are correctly not marked as PG_offline. Fixes: 77c4adf6a6df (xen/balloon: mark inflated pages PG_offline) Reported-by: Julien Grall <julien.grall@arm.com> Tested-by: Julien Grall <julien.grall@arm.com> Signed-off-by: David Hildenbrand <david@redhat.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
* | Merge tag 'devdax-for-5.1' of ↵Linus Torvalds2019-03-1622-502/+1044
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull device-dax updates from Dan Williams: "New device-dax infrastructure to allow persistent memory and other "reserved" / performance differentiated memories, to be assigned to the core-mm as "System RAM". Some users want to use persistent memory as additional volatile memory. They are willing to cope with potential performance differences, for example between DRAM and 3D Xpoint, and want to use typical Linux memory management apis rather than a userspace memory allocator layered over an mmap() of a dax file. The administration model is to decide how much Persistent Memory (pmem) to use as System RAM, create a device-dax-mode namespace of that size, and then assign it to the core-mm. The rationale for device-dax is that it is a generic memory-mapping driver that can be layered over any "special purpose" memory, not just pmem. On subsequent boots udev rules can be used to restore the memory assignment. One implication of using pmem as RAM is that mlock() no longer keeps data off persistent media. For this reason it is recommended to enable NVDIMM Security (previously merged for 5.0) to encrypt pmem contents at rest. We considered making this recommendation an actively enforced requirement, but in the end decided to leave it as a distribution / administrator policy to allow for emulation and test environments that lack security capable NVDIMMs. Summary: - Replace the /sys/class/dax device model with /sys/bus/dax, and include a compat driver so distributions can opt-in to the new ABI. - Allow for an alternative driver for the device-dax address-range - Introduce the 'kmem' driver to hotplug / assign a device-dax address-range to the core-mm. - Arrange for the device-dax target-node to be onlined so that the newly added memory range can be uniquely referenced by numa apis" NOTE! I'm not entirely happy with the whole "PMEM as RAM" model because we currently have special - and very annoying rules in the kernel about accessing PMEM only with the "MC safe" accessors, because machine checks inside the regular repeat string copy functions can be fatal in some (not described) circumstances. And apparently the PMEM modules can cause that a lot more than regular RAM. The argument is that this happens because PMEM doesn't necessarily get scrubbed at boot like RAM does, but that is planned to be added for the user space tooling. Quoting Dan from another email: "The exposure can be reduced in the volatile-RAM case by scanning for and clearing errors before it is onlined as RAM. The userspace tooling for that can be in place before v5.1-final. There's also runtime notifications of errors via acpi_nfit_uc_error_notify() from background scrubbers on the DIMM devices. With that mechanism the kernel could proactively clear newly discovered poison in the volatile case, but that would be additional development more suitable for v5.2. I understand the concern, and the need to highlight this issue by tapping the brakes on feature development, but I don't see PMEM as RAM making the situation worse when the exposure is also there via DAX in the PMEM case. Volatile-RAM is arguably a safer use case since it's possible to repair pages where the persistent case needs active application coordination" * tag 'devdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: device-dax: "Hotplug" persistent memory for use like normal RAM mm/resource: Let walk_system_ram_range() search child resources mm/memory-hotplug: Allow memory resources to be children mm/resource: Move HMM pr_debug() deeper into resource code mm/resource: Return real error codes from walk failures device-dax: Add a 'modalias' attribute to DAX 'bus' devices device-dax: Add a 'target_node' attribute device-dax: Auto-bind device after successful new_id acpi/nfit, device-dax: Identify differentiated memory with a unique numa-node device-dax: Add /sys/class/dax backwards compatibility device-dax: Add support for a dax override driver device-dax: Move resource pinning+mapping into the common driver device-dax: Introduce bus + driver model device-dax: Start defining a dax bus model device-dax: Remove multi-resource infrastructure device-dax: Kill dax_region base device-dax: Kill dax_region ida
| * | device-dax: "Hotplug" persistent memory for use like normal RAMDave Hansen2019-02-284-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended for use with NVDIMMs that are physically persistent (physically like flash) so that they can be used as a cost-effective RAM replacement. Intel Optane DC persistent memory is one implementation of this kind of NVDIMM. Currently, a persistent memory region is "owned" by a device driver, either the "Direct DAX" or "Filesystem DAX" drivers. These drivers allow applications to explicitly use persistent memory, generally by being modified to use special, new libraries. (DIMM-based persistent memory hardware/software is described in great detail here: Documentation/nvdimm/nvdimm.txt). However, this limits persistent memory use to applications which *have* been modified. To make it more broadly usable, this driver "hotplugs" memory into the kernel, to be managed and used just like normal RAM would be. To make this work, management software must remove the device from being controlled by the "Device DAX" infrastructure: echo dax0.0 > /sys/bus/dax/drivers/device_dax/unbind and then tell the new driver that it can bind to the device: echo dax0.0 > /sys/bus/dax/drivers/kmem/new_id After this, there will be a number of new memory sections visible in sysfs that can be onlined, or that may get onlined by existing udev-initiated memory hotplug rules. This rebinding procedure is currently a one-way trip. Once memory is bound to "kmem", it's there permanently and can not be unbound and assigned back to device_dax. The kmem driver will never bind to a dax device unless the device is *explicitly* bound to the driver. There are two reasons for this: One, since it is a one-way trip, it can not be undone if bound incorrectly. Two, the kmem driver destroys data on the device. Think of if you had good data on a pmem device. It would be catastrophic if you compile-in "kmem", but leave out the "device_dax" driver. kmem would take over the device and write volatile data all over your good data. This inherits any existing NUMA information for the newly-added memory from the persistent memory device that came from the firmware. On Intel platforms, the firmware has guarantees that require each socket's persistent memory to be in a separate memory-only NUMA node. That means that this patch is not expected to create NUMA nodes, but will simply hotplug memory into existing nodes. Because NUMA nodes are created, the existing NUMA APIs and tools are sufficient to create policies for applications or memory areas to have affinity for or an aversion to using this memory. There is currently some metadata at the beginning of pmem regions. The section-size memory hotplug restrictions, plus this small reserved area can cause the "loss" of a section or two of capacity. This should be fixable in follow-on patches. But, as a first step, losing 256MB of memory (worst case) out of hundreds of gigabytes is a good tradeoff vs. the required code to fix this up precisely. This calculation is also the reason we export memory_block_size_bytes(). Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Keith Busch <keith.busch@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Ross Zwisler <zwisler@kernel.org> Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: linux-nvdimm@lists.01.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: Huang Ying <ying.huang@intel.com> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Add a 'modalias' attribute to DAX 'bus' devicesVishal Verma2019-02-271-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a 'modalias' attribute to devices under the DAX bus so that userspace is able to dynamically load modules as needed. Normally, udev can get the modalias from 'uevent', and that is correctly set up by the DAX bus. However other tooling such as 'libndctl' for interacting with drivers/nvdimm/, and 'libdaxctl' for drivers/dax/ can also use the modalias to dynamically load modules via libkmod lookups. The 'nd' bus set up by the libnvdimm subsystem exports a modalias attribute. Imitate this to export the same for the 'dax' bus. Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Add a 'target_node' attributeDan Williams2019-02-201-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The target-node attribute is the Linux numa-node that a device-dax instance may create when it is online. Prior to being online the device's 'numa_node' property reflects the closest online cpu node which is the typical expectation of a device 'numa_node'. Once it is online it becomes its own distinct numa node, i.e. 'target_node'. Export the 'target_node' property to give userspace tooling the ability to predict the effective numa-node from a device-dax instance configured to provide 'System RAM' capacity. Cc: Vishal Verma <vishal.l.verma@intel.com> Reported-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Auto-bind device after successful new_idDan Williams2019-01-241-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The typical 'new_id' attribute behavior is to immediately attach a device to its driver after a new device-id is added. Implement this behavior for the dax bus. Reported-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Reported-by: Brice Goglin <Brice.Goglin@inria.fr> Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | acpi/nfit, device-dax: Identify differentiated memory with a unique numa-nodeDan Williams2019-01-0610-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Persistent memory, as described by the ACPI NFIT (NVDIMM Firmware Interface Table), is the first known instance of a memory range described by a unique "target" proximity domain. Where "initiator" and "target" proximity domains is an approach that the ACPI HMAT (Heterogeneous Memory Attributes Table) uses to described the unique performance properties of a memory range relative to a given initiator (e.g. CPU or DMA device). Currently the numa-node for a /dev/pmemX block-device or /dev/daxX.Y char-device follows the traditional notion of 'numa-node' where the attribute conveys the closest online numa-node. That numa-node attribute is useful for cpu-binding and memory-binding processes *near* the device. However, when the memory range backing a 'pmem', or 'dax' device is onlined (memory hot-add) the memory-only-numa-node representing that address needs to be differentiated from the set of online nodes. In other words, the numa-node association of the device depends on whether you can bind processes *near* the cpu-numa-node in the offline device-case, or bind process *on* the memory-range directly after the backing address range is onlined. Allow for the case that platform firmware describes persistent memory with a unique proximity domain, i.e. when it is distinct from the proximity of DRAM and CPUs that are on the same socket. Plumb the Linux numa-node translation of that proximity through the libnvdimm region device to namespaces that are in device-dax mode. With this in place the proposed kmem driver [1] can optionally discover a unique numa-node number for the address range as it transitions the memory from an offline state managed by a device-driver to an online memory range managed by the core-mm. [1]: https://lore.kernel.org/lkml/20181022201317.8558C1D8@viggo.jf.intel.com Reported-by: Fan Du <fan.du@intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Oliver O'Halloran" <oohall@gmail.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Jérôme Glisse <jglisse@redhat.com> Reviewed-by: Yang Shi <yang.shi@linux.alibaba.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Add /sys/class/dax backwards compatibilityDan Williams2019-01-069-49/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the expectation that some environments may not upgrade libdaxctl (userspace component that depends on the /sys/class/dax hierarchy), provide a default / legacy dax_pmem_compat driver. The dax_pmem_compat driver implements the original /sys/class/dax sysfs layout rather than /sys/bus/dax. When userspace is upgraded it can blacklist this module and switch to the dax_pmem driver going forward. CONFIG_DEV_DAX_PMEM_COMPAT and supporting code will be deleted according to the dax_pmem entry in Documentation/ABI/obsolete/. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Add support for a dax override driverDan Williams2019-01-063-10/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce the 'new_id' concept for enabling a custom device-driver attach policy for dax-bus drivers. The intended use is to have a mechanism for hot-plugging device-dax ranges into the page allocator on-demand. With this in place the default policy of using device-dax for performance differentiated memory can be overridden by user-space policy that can arrange for the memory range to be managed as 'System RAM' with user-defined NUMA and other performance attributes. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Move resource pinning+mapping into the common driverDan Williams2019-01-065-79/+90
| | | | | | | | | | | | | | | | | | | | | | | | Move the responsibility of calling devm_request_resource() and devm_memremap_pages() into the common device-dax driver. This is another preparatory step to allowing an alternate personality driver for a device-dax range. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Introduce bus + driver modelDan Williams2019-01-065-87/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In support of multiple device-dax instances per device-dax-region and allowing the 'kmem' driver to attach to dax-instances instead of the current device-node access, convert the dax sub-system from a class to a bus. Recall that the kmem driver takes reserved / special purpose memories and assigns them to be managed by the core-mm. Aside from the fact the device-dax instances are registered and probed on a bus, two other lifetime-management changes are made: 1/ Delay attaching a cdev until driver probe time 2/ A new run_dax() helper is introduced to allow restoring dax-operation after a kill_dax() event. So, at driver ->probe() time we run_dax() and at ->remove() time we kill_dax() and invalidate all mappings. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Start defining a dax bus modelDan Williams2019-01-069-224/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Towards eliminating the dax_class, move the dax-device-attribute enabling to a new bus.c file in the core. The amount of code thrash of sub-sequent patches is reduced as no logic changes are made, just pure code movement. A temporary export of unregister_dex_dax() and dax_attribute_groups is needed to preserve compilation, but those symbols become static again in a follow-on patch. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Remove multi-resource infrastructureDan Williams2019-01-064-49/+10
| | | | | | | | | | | | | | | | | | | | | | | | The multi-resource implementation anticipated discontiguous sub-division support. That has not yet materialized, delete the infrastructure and related code. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
| * | device-dax: Kill dax_region baseDan Williams2019-01-064-8/+4
| | | | | | | | | | | | | | | | | | | | | Nothing consumes this attribute of a region and devres otherwise remembers the value for de-allocation purposes. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-08 10:59:01 +0000