* [PATCH] Documentation/admin-guide/README.rst: add a label for cross-referencing
From: Michael Rodin @ 2018-06-03 18:16 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, linux-kernel, Michael Rodin
Add a label to the top of the file to allow cross-referencing.
Currently it's not possible to cross-reference this file from
Documentation/process/howto.rst because of the missing label.
Signed-off-by: Michael Rodin <michael-git@rodin.online>
---
Documentation/admin-guide/README.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst
index 02caa7efd5ef..15ea785b2dfa 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -1,3 +1,5 @@
+.. _readme:
+
Linux kernel release 4.x <http://kernel.org/>
=============================================
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] PCI: Add pci=safemode option
From: okaya @ 2018-06-02 17:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-pci, timur, linux-arm-msm,
linux-arm-kernel, Jonathan Corbet, Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Christoffer Dall, Paul E. McKenney, Marc Zyngier,
Kai-Heng Feng, Thymo van Beers, Frederic Weisbecker,
Konrad Rzeszutek Wilk, David Rientjes, Rafael J. Wysocki,
Keith Busch, Dongdong Liu, Frederick Lawler, Oza Pawandeep,
Gabriele Paoloni, open list:DOCUMENTATION, open list
In-Reply-To: <20180602174307.GB14870@amd>
On 2018-06-02 13:43, Pavel Machek wrote:
> Hi!
>
>> > And you should explain what exactly in PCI is "optional". Who defines
>> > this and where is that list and what can go wrong if those options are
>> > not enabled?
>>
>> Bjorn and I discussed the need for such a "safe" mode feature when you
>> want to bring up PCI for a platform. You want to turn off everything
>> as
>> a starter and just stick to bare minimum.
>>
>> I can add a few words describing them. The goal of this option is to
>> keep
>> base PCI features with MSI only. Things like PME, AER, ASPM, Extended
>> Tags, LTR, Relaxed Ordering, SRIOV are all considered optional.
>> safemode
>> is certainly not intended for production environments.
>>
>> I can taint the kernel as a suggestion.
>
> I don't think tainting is required. even modern platforms should work
> in the safe mode.
Yeah, concern was getting used to the safe mode and never running the
full stack to fix the actual issues like getting away with crappy
hardware and firmware.
It becomes a support issue for the community.
> Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PCI: Add pci=safemode option
From: Pavel Machek @ 2018-06-02 17:43 UTC (permalink / raw)
To: Sinan Kaya
Cc: Greg Kroah-Hartman, linux-pci, timur, linux-arm-msm,
linux-arm-kernel, Jonathan Corbet, Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Christoffer Dall, Paul E. McKenney, Marc Zyngier,
Kai-Heng Feng, Thymo van Beers, Frederic Weisbecker,
Konrad Rzeszutek Wilk, David Rientjes, Rafael J. Wysocki,
Keith Busch, Dongdong Liu, Frederick Lawler, Oza Pawandeep,
Gabriele Paoloni, open list:DOCUMENTATION, open list
In-Reply-To: <6c317ed8-cca3-8862-5f3b-12cf14e4d53b@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
Hi!
> > And you should explain what exactly in PCI is "optional". Who defines
> > this and where is that list and what can go wrong if those options are
> > not enabled?
>
> Bjorn and I discussed the need for such a "safe" mode feature when you
> want to bring up PCI for a platform. You want to turn off everything as
> a starter and just stick to bare minimum.
>
> I can add a few words describing them. The goal of this option is to keep
> base PCI features with MSI only. Things like PME, AER, ASPM, Extended
> Tags, LTR, Relaxed Ordering, SRIOV are all considered optional. safemode
> is certainly not intended for production environments.
>
> I can taint the kernel as a suggestion.
I don't think tainting is required. even modern platforms should work
in the safe mode.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] docs/admin-guide/mm: add high level concepts overview
From: Randy Dunlap @ 2018-06-02 0:09 UTC (permalink / raw)
To: Mike Rapoport, Jonathan Corbet; +Cc: linux-doc, linux-mm, linux-kernel
In-Reply-To: <20180529113725.GB13092@rapoport-lnx>
On 05/29/2018 04:37 AM, Mike Rapoport wrote:
> Hi,
>
> From 2d3ec7ea101a66b1535d5bec4acfc1e0f737fd53 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Date: Tue, 29 May 2018 14:12:39 +0300
> Subject: [PATCH] docs/admin-guide/mm: add high level concepts overview
>
> The are terms that seem obvious to the mm developers, but may be somewhat
There are [or: These are]
> obscure for, say, less involved readers.
>
> The concepts overview can be seen as an "extended glossary" that introduces
> such terms to the readers of the kernel documentation.
>
> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> ---
> Documentation/admin-guide/mm/concepts.rst | 222 ++++++++++++++++++++++++++++++
> Documentation/admin-guide/mm/index.rst | 5 +
> 2 files changed, 227 insertions(+)
> create mode 100644 Documentation/admin-guide/mm/concepts.rst
>
> diff --git a/Documentation/admin-guide/mm/concepts.rst b/Documentation/admin-guide/mm/concepts.rst
> new file mode 100644
> index 0000000..291699c
> --- /dev/null
> +++ b/Documentation/admin-guide/mm/concepts.rst
> @@ -0,0 +1,222 @@
> +.. _mm_concepts:
> +
> +=================
> +Concepts overview
> +=================
> +
> +The memory management in Linux is complex system that evolved over the
is a complex
> +years and included more and more functionality to support variety of
support a variety of
> +systems from MMU-less microcontrollers to supercomputers. The memory
> +management for systems without MMU is called ``nommu`` and it
without an MMU
> +definitely deserves a dedicated document, which hopefully will be
> +eventually written. Yet, although some of the concepts are the same,
> +here we assume that MMU is available and CPU can translate a virtual
that an MMU and a CPU
> +address to a physical address.
> +
> +.. contents:: :local:
> +
> +Virtual Memory Primer
> +=====================
> +
> +The physical memory in a computer system is a limited resource and
> +even for systems that support memory hotplug there is a hard limit on
> +the amount of memory that can be installed. The physical memory is not
> +necessary contiguous, it might be accessible as a set of distinct
Change comma to semi-colon or period (and if latter, s/it/It/).
> +address ranges. Besides, different CPU architectures, and even
> +different implementations of the same architecture have different view
views of
> +how these address ranges defined.
> +
> +All this makes dealing directly with physical memory quite complex and
> +to avoid this complexity a concept of virtual memory was developed.
> +
> +The virtual memory abstracts the details of physical memory from the
virtual memory {system, implementation} abstracts
> +application software, allows to keep only needed information in the
software, allowing the VM to keep only needed information in the
> +physical memory (demand paging) and provides a mechanism for the
> +protection and controlled sharing of data between processes.
> +
> +With virtual memory, each and every memory access uses a virtual
> +address. When the CPU decodes the an instruction that reads (or
> +writes) from (or to) the system memory, it translates the `virtual`
> +address encoded in that instruction to a `physical` address that the
> +memory controller can understand.
> +
> +The physical system memory is divided into page frames, or pages. The
> +size of each page is architecture specific. Some architectures allow
> +selection of the page size from several supported values; this
> +selection is performed at the kernel build time by setting an
> +appropriate kernel configuration option.
> +
> +Each physical memory page can be mapped as one or more virtual
> +pages. These mappings are described by page tables that allow
> +translation from virtual address used by programs to real address in
from a virtual address to {a, the} real address in
> +the physical memory. The page tables organized hierarchically.
tables are organized
> +
> +The tables at the lowest level of the hierarchy contain physical
> +addresses of actual pages used by the software. The tables at higher
> +levels contain physical addresses of the pages belonging to the lower
> +levels. The pointer to the top level page table resides in a
> +register. When the CPU performs the address translation, it uses this
> +register to access the top level page table. The high bits of the
> +virtual address are used to index an entry in the top level page
> +table. That entry is then used to access the next level in the
> +hierarchy with the next bits of the virtual address as the index to
> +that level page table. The lowest bits in the virtual address define
> +the offset inside the actual page.
> +
> +Huge Pages
> +==========
> +
> +The address translation requires several memory accesses and memory
> +accesses are slow relatively to CPU speed. To avoid spending precious
> +processor cycles on the address translation, CPUs maintain a cache of
> +such translations called Translation Lookaside Buffer (or
> +TLB). Usually TLB is pretty scarce resource and applications with
> +large memory working set will experience performance hit because of
> +TLB misses.
> +
> +Many modern CPU architectures allow mapping of the memory pages
> +directly by the higher levels in the page table. For instance, on x86,
> +it is possible to map 2M and even 1G pages using entries in the second
> +and the third level page tables. In Linux such pages are called
> +`huge`. Usage of huge pages significantly reduces pressure on TLB,
> +improves TLB hit-rate and thus improves overall system performance.
> +
> +There are two mechanisms in Linux that enable mapping of the physical
> +memory with the huge pages. The first one is `HugeTLB filesystem`, or
> +hugetlbfs. It is a pseudo filesystem that uses RAM as its backing
> +store. For the files created in this filesystem the data resides in
> +the memory and mapped using huge pages. The hugetlbfs is described at
> +:ref:`Documentation/admin-guide/mm/hugetlbpage.rst <hugetlbpage>`.
> +
> +Another, more recent, mechanism that enables use of the huge pages is
> +called `Transparent HugePages`, or THP. Unlike the hugetlbfs that
> +requires users and/or system administrators to configure what parts of
> +the system memory should and can be mapped by the huge pages, THP
> +manages such mappings transparently to the user and hence the
> +name. See
> +:ref:`Documentation/admin-guide/mm/transhuge.rst <admin_guide_transhuge>`
> +for more details about THP.
> +
> +Zones
> +=====
> +
> +Often hardware poses restrictions on how different physical memory
> +ranges can be accessed. In some cases, devices cannot perform DMA to
> +all the addressable memory. In other cases, the size of the physical
> +memory exceeds the maximal addressable size of virtual memory and
> +special actions are required to access portions of the memory. Linux
> +groups memory pages into `zones` according to their possible
> +usage. For example, ZONE_DMA will contain memory that can be used by
> +devices for DMA, ZONE_HIGHMEM will contain memory that is not
> +permanently mapped into kernel's address space and ZONE_NORMAL will
> +contain normally addressed pages.
> +
> +The actual layout of the memory zones is hardware dependent as not all
> +architectures define all zones, and requirements for DMA are different
> +for different platforms.
> +
> +Nodes
> +=====
> +
> +Many multi-processor machines are NUMA - Non-Uniform Memory Access -
> +systems. In such systems the memory is arranged into banks that have
> +different access latency depending on the "distance" from the
> +processor. Each bank is referred as `node` and for each node Linux
is referred to as a `node`
> +constructs an independent memory management subsystem. A node has it's
its
> +own set of zones, lists of free and used pages and various statistics
> +counters. You can find more details about NUMA in
> +:ref:`Documentation/vm/numa.rst <numa>` and in
> +:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`.
> +
> +Page cache
> +==========
> +
> +The physical memory is volatile and the common case for getting data
> +into the memory is to read it from files. Whenever a file is read, the
> +data is put into the `page cache` to avoid expensive disk access on
> +the subsequent reads. Similarly, when one writes to a file, the data
> +is placed in the page cache and eventually gets into the backing
> +storage device. The written pages are marked as `dirty` and when Linux
> +decides to reuse them for other purposes, it makes sure to synchronize
> +the file contents on the device with the updated data.
> +
> +Anonymous Memory
> +================
> +
> +The `anonymous memory` or `anonymous mappings` represent memory that
> +is not backed by a filesystem. Such mappings are implicitly created
> +for program's stack and heap or by explicit calls to mmap(2) system
> +call. Usually, the anonymous mappings only define virtual memory areas
> +that the program is allowed to access. The read accesses will result
> +in creation of a page table entry that references a special physical
> +page filled with zeroes. When the program performs a write, regular
write, a regular
> +physical page will be allocated to hold the written data. The page
> +will be marked dirty and if the kernel will decide to repurpose it,
> +the dirty page will be swapped out.
> +
> +Reclaim
> +=======
> +
> +Throughout the system lifetime, a physical page can be used for storing
> +different types of data. It can be kernel internal data structures,
> +DMA'able buffers for device drivers use, data read from a filesystem,
> +memory allocated by user space processes etc.
> +
> +Depending on the page usage it is treated differently by the Linux
> +memory management. The pages that can be freed at any time, either
> +because they cache the data available elsewhere, for instance, on a
> +hard disk, or because they can be swapped out, again, to the hard
> +disk, are called `reclaimable`. The most notable categories of the
> +reclaimable pages are page cache and anonymous memory.
> +
> +In most cases, the pages holding internal kernel data and used as DMA
> +buffers cannot be repurposed, and they remain pinned until freed by
> +their user. Such pages are called `unreclaimable`. However, in certain
> +circumstances, even pages occupied with kernel data structures can be
> +reclaimed. For instance, in-memory caches of filesystem metadata can
> +be re-read from the storage device and therefore it is possible to
> +discard them from the main memory when system is under memory
> +pressure.
> +
> +The process of freeing the reclaimable physical memory pages and
> +repurposing them is called (surprise!) `reclaim`. Linux can reclaim
> +pages either asynchronously or synchronously, depending on the state
> +of the system. When system is not loaded, most of the memory is free
When {the, a} system
> +and allocation request will be satisfied immediately from the free
requests
or
and an allocation request
> +pages supply. As the load increases, the amount of the free pages goes
> +down and when it reaches a certain threshold (high watermark), an
> +allocation request will awaken the ``kswapd`` daemon. It will
> +asynchronously scan memory pages and either just free them if the data
> +they contain is available elsewhere, or evict to the backing storage
> +device (remember those dirty pages?). As memory usage increases even
> +more and reaches another threshold - min watermark - an allocation
> +will trigger the `direct reclaim`. In this case allocation is stalled
s/the//
> +until enough memory pages are reclaimed to satisfy the request.
> +
> +Compaction
> +==========
> +
> +As the system runs, tasks allocate and free the memory and it becomes
> +fragmented. Although with virtual memory it is possible to present
> +scattered physical pages as virtually contiguous range, sometimes it is
> +necessary to allocate large physically contiguous memory areas. Such
> +need may arise, for instance, when a device driver requires large
requires a large
> +buffer for DMA, or when THP allocates a huge page. Memory `compaction`
> +addresses the fragmentation issue. This mechanism moves occupied pages
> +from the lower part of a memory zone to free pages in the upper part
> +of the zone. When a compaction scan is finished free pages are grouped
> +together at the beginning of the zone and allocations of large
> +physically contiguous areas become possible.
> +
> +Like reclaim, the compaction may happen asynchronously in ``kcompactd``
in the
> +daemon or synchronously as a result of memory allocation request.
of a memory allocation request.
> +
> +OOM killer
> +==========
> +
> +It may happen, that on a loaded machine memory will be exhausted. When
no comma.
> +the kernel detects that the system runs out of memory (OOM) it invokes
> +`OOM killer`. Its mission is simple: all it has to do is to select a
> +task to sacrifice for the sake of the overall system health. The
> +selected task is killed in a hope that after it exits enough memory
> +will be freed to continue normal operation.
thanks for doing this overview.
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Eric Northup @ 2018-06-01 21:22 UTC (permalink / raw)
To: gengdongjiu
Cc: rkrcmar, corbet, christoffer.dall, Marc Zyngier, linux,
Catalin Marinas, will.deacon, KVM, linux-doc, james.morse,
linux-arm-kernel, Linux Kernel Mailing List, linux-acpi
In-Reply-To: <1527772139-19665-3-git-send-email-gengdongjiu@huawei.com>
On Wed, May 30, 2018 at 10:04 PM Dongjiu Geng <gengdongjiu@huawei.com> wrote:
>
> For the migrating VMs, user space may need to know the exception
> state. For example, in the machine A, KVM make an SError pending,
> when migrate to B, KVM also needs to pend an SError.
>
> This new IOCTL exports user-invisible states related to SError.
> Together with appropriate user space changes, user space can get/set
> the SError exception state to do migrate/snapshot/suspend.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> --
> this series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
> change since V12:
> 1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 & HCR_VSE) in kvm_arm_vcpu_get_events()
>
> Change since V11:
> Address James's comments, thanks James
> 1. Align the struct of kvm_vcpu_events to 64 bytes
> 2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
> 3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
> 4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
>
> Change since V10:
> Address James's comments, thanks James
> 1. Merge the helper function with the user.
> 2. Move the ISS_MASK into pend_guest_serror() to clear top bits
> 3. Make kvm_vcpu_events struct align to 4 bytes
> 4. Add something check in the kvm_arm_vcpu_set_events()
> 5. Check kvm_arm_vcpu_get/set_events()'s return value.
> 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
> contain kernel stack.
> ---
> Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
> arch/arm/include/asm/kvm_host.h | 6 ++++++
> arch/arm/kvm/guest.c | 12 ++++++++++++
> arch/arm64/include/asm/kvm_emulate.h | 5 +++++
> arch/arm64/include/asm/kvm_host.h | 7 +++++++
> arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
> arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/inject_fault.c | 7 ++++++-
> arch/arm64/kvm/reset.c | 1 +
> virt/kvm/arm/arm.c | 21 +++++++++++++++++++++
> 10 files changed, 135 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index fdac969..8896737 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -835,11 +835,13 @@ struct kvm_clock_data {
>
> Capability: KVM_CAP_VCPU_EVENTS
> Extended by: KVM_CAP_INTR_SHADOW
> -Architectures: x86
> +Architectures: x86, arm, arm64
> Type: vm ioctl
> Parameters: struct kvm_vcpu_event (out)
> Returns: 0 on success, -1 on error
>
> +X86:
> +
> Gets currently pending exceptions, interrupts, and NMIs as well as related
> states of the vcpu.
>
> @@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
> - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
> smi contains a valid state.
>
> +ARM, ARM64:
> +
> +Gets currently pending SError exceptions as well as related states of the vcpu.
> +
> +struct kvm_vcpu_events {
> + struct {
> + __u8 serror_pending;
> + __u8 serror_has_esr;
> + /* Align it to 8 bytes */
> + __u8 pad[6];
> + __u64 serror_esr;
> + } exception;
> + __u32 reserved[12];
>
> +};
> +
> 4.32 KVM_SET_VCPU_EVENTS
>
> -Capability: KVM_CAP_VCPU_EVENTS
> +Capebility: KVM_CAP_VCPU_EVENTS
> Extended by: KVM_CAP_INTR_SHADOW
> -Architectures: x86
> +Architectures: x86, arm, arm64
> Type: vm ioctl
> Parameters: struct kvm_vcpu_event (in)
> Returns: 0 on success, -1 on error
>
> +X86:
> +
> Set pending exceptions, interrupts, and NMIs as well as related states of the
> vcpu.
>
> @@ -910,6 +929,12 @@ shall be written into the VCPU.
>
> KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
>
> +ARM, ARM64:
> +
> +Set pending SError exceptions as well as related states of the vcpu.
> +
> +See KVM_GET_VCPU_EVENTS for the data structure.
> +
>
> 4.33 KVM_GET_DEBUGREGS
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index c7c28c8..39f9901 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
> int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
> int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events);
> +
> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events);
> +
> unsigned long kvm_call_hyp(void *hypfn, ...);
> void force_vm_exit(const cpumask_t *mask);
>
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index a18f33e..c685f0e 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> return -EINVAL;
> }
>
> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events)
> +{
> + return -EINVAL;
> +}
> +
> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events)
> +{
> + return -EINVAL;
> +}
> +
> int __attribute_const__ kvm_target_cpu(void)
> {
> switch (read_cpuid_part()) {
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 1dab3a9..18f61ff 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
> return (unsigned long *)&vcpu->arch.hcr_el2;
> }
>
> +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->arch.vsesr_el2;
> +}
> +
> static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
> {
> vcpu->arch.vsesr_el2 = vsesr;
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 469de8a..357304a 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
> int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
> int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events);
> +
> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events);
>
> #define KVM_ARCH_WANT_MMU_NOTIFIER
> int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
> @@ -363,6 +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
> int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> +
> struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
>
> void __kvm_set_tpidr_el2(u64 tpidr_el2);
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 04b3256..df4faee 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -39,6 +39,7 @@
> #define __KVM_HAVE_GUEST_DEBUG
> #define __KVM_HAVE_IRQ_LINE
> #define __KVM_HAVE_READONLY_MEM
> +#define __KVM_HAVE_VCPU_EVENTS
>
> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>
> @@ -153,6 +154,18 @@ struct kvm_sync_regs {
> struct kvm_arch_memory_slot {
> };
>
> +/* for KVM_GET/SET_VCPU_EVENTS */
> +struct kvm_vcpu_events {
> + struct {
> + __u8 serror_pending;
> + __u8 serror_has_esr;
> + /* Align it to 8 bytes */
> + __u8 pad[6];
> + __u64 serror_esr;
> + } exception;
> + __u32 reserved[12];
It will be easier to re-purpose this in the future if the field is
reserved and is checked that it must be zero. SET_VCPU_EVENTS would
return EINVAL if reserved fields get used until a later meaning is
defined for them.
> +};
> +
> /* If you need to interpret the index values, here is the key: */
> #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> #define KVM_REG_ARM_COPROC_SHIFT 16
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 56a0260..71d3841 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> return -EINVAL;
> }
>
> +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events)
> +{
> + events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
> + events->exception.serror_has_esr =
> + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
> + (!!vcpu_get_vsesr(vcpu));
> +
> + if (events->exception.serror_pending &&
> + events->exception.serror_has_esr)
> + events->exception.serror_esr = vcpu_get_vsesr(vcpu);
> + else
> + events->exception.serror_esr = 0;
> +
> + return 0;
> +}
> +
> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> + struct kvm_vcpu_events *events)
> +{
> + bool serror_pending = events->exception.serror_pending;
> + bool has_esr = events->exception.serror_has_esr;
> +
> + if (serror_pending && has_esr) {
> + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
> + return -EINVAL;
> +
> + kvm_set_sei_esr(vcpu, events->exception.serror_esr);
> +
> + } else if (serror_pending) {
> + kvm_inject_vabt(vcpu);
> + }
> +
> + return 0;
> +}
> +
> int __attribute_const__ kvm_target_cpu(void)
> {
> unsigned long implementor = read_cpuid_implementor();
> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> index d8e7165..9e0ca56 100644
> --- a/arch/arm64/kvm/inject_fault.c
> +++ b/arch/arm64/kvm/inject_fault.c
> @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>
> static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
> {
> - vcpu_set_vsesr(vcpu, esr);
> + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
> *vcpu_hcr(vcpu) |= HCR_VSE;
> }
>
> @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)
> {
> pend_guest_serror(vcpu, ESR_ELx_ISV);
> }
> +
> +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome)
> +{
> + pend_guest_serror(vcpu, syndrome);
> +}
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 38c8a64..20e919a 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
> break;
> case KVM_CAP_SET_GUEST_DEBUG:
> case KVM_CAP_VCPU_ATTRIBUTES:
> + case KVM_CAP_VCPU_EVENTS:
> r = 1;
> break;
> default:
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index a4c1b76..8b43968 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1107,6 +1107,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> r = kvm_arm_vcpu_has_attr(vcpu, &attr);
> break;
> }
> + case KVM_GET_VCPU_EVENTS: {
> + struct kvm_vcpu_events events;
> +
> + memset(&events, 0, sizeof(events));
> + if (kvm_arm_vcpu_get_events(vcpu, &events))
> + return -EINVAL;
> +
> + if (copy_to_user(argp, &events, sizeof(events)))
> + return -EFAULT;
> +
> + return 0;
> + }
> + case KVM_SET_VCPU_EVENTS: {
> + struct kvm_vcpu_events events;
> +
> + if (copy_from_user(&events, argp,
> + sizeof(struct kvm_vcpu_events)))
> + return -EFAULT;
> +
> + return kvm_arm_vcpu_set_events(vcpu, &events);
> + }
> default:
> r = -EINVAL;
> }
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V3] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 19:00 UTC (permalink / raw)
To: linux-pci, timur
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Jonathan Corbet,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Paul E. McKenney, Christoffer Dall, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Greg Kroah-Hartman,
David Rientjes, Philippe Ombredanne, Kate Stewart, Tom Lendacky,
Juergen Gross, Borislav Petkov, Mikulas Patocka, Petr Tesarik,
Boris Ostrovsky, Dou Liyang, Ram Pai, open list:DOCUMENTATION,
open list
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 ---
arch/x86/pci/early.c | 44 -------------------------
drivers/pci/pci.c | 5 +++
drivers/pci/pci.h | 1 +
drivers/pci/probe.c | 19 +++++++++++
8 files changed, 26 insertions(+), 59 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e490902..e64f1d8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2995,7 +2995,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8 offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..f5fc953 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -57,47 +57,3 @@ int early_pci_allowed(void)
PCI_PROBE_CONF1;
}
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97acba7..04052dc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, the PCI config space of each device is printed during boot. */
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..c33265e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,6 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 56771f3..3678f0a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1545,6 +1545,23 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ if (!pci_early_dump)
+ return;
+
+ pci_info(pdev, "config space:\n");
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1594,6 +1611,8 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V2] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 18:58 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-pci, timur, Kate Stewart, open list:DOCUMENTATION,
Petr Tesarik, Ram Pai, Kai-Heng Feng, H. Peter Anvin,
Boris Ostrovsky, Christoffer Dall, Jonathan Corbet,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Ingo Molnar,
David Rientjes, Thymo van Beers, Borislav Petkov, Tom Lendacky,
Marc Zyngier, linux-arm-msm, Frederic Weisbecker, Mikulas Patocka,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Juergen Gross, Dou Liyang, Paul E. McKenney, Greg Kroah-Hartman,
open list, Philippe Ombredanne
In-Reply-To: <20180601185310.GA175802@bhelgaas-glaptop.roam.corp.google.com>
On 6/1/2018 2:53 PM, Bjorn Helgaas wrote:
>> + pci_info(pdev, "pci 0000:%02x:%02x.%d config space:\n",
>> + pdev->bus->number, PCI_SLOT(pdev->devfn),
>> + PCI_FUNC(pdev->devfn));
> I'm still missing something -- why go to the trouble of pdev->bus->number,
> PCI_SLOT(), etc? Isn't the output going to look like this?
>
> pci 0000:00:00.0: pci 0000:00:00.0 config space:
>
> In other words, wouldn't the following be enough?
>
> pci_info(pdev, "config space:\n");
>
You are right. The origin print function was pr_info. We don't need that
stuff anymore.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux-next v5 10/13] Documentation: hwmon: Add documents for PECI hwmon client drivers
From: Guenter Roeck @ 2018-06-01 18:54 UTC (permalink / raw)
To: Jae Hyun Yoo
Cc: Jean Delvare, Jonathan Corbet, linux-hwmon, linux-doc,
linux-kernel, openbmc, Jason M Biils, Randy Dunlap
In-Reply-To: <20180601182244.24028-1-jae.hyun.yoo@linux.intel.com>
On Fri, Jun 01, 2018 at 11:22:44AM -0700, Jae Hyun Yoo wrote:
> This commit adds hwmon documents for PECI cputemp and dimmtemp drivers.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
> Reviewed-by: James Feist <james.feist@linux.intel.com>
> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/hwmon/peci-cputemp | 78 +++++++++++++++++++++++++++++++
> Documentation/hwmon/peci-dimmtemp | 50 ++++++++++++++++++++
> 2 files changed, 128 insertions(+)
> create mode 100644 Documentation/hwmon/peci-cputemp
> create mode 100644 Documentation/hwmon/peci-dimmtemp
>
> diff --git a/Documentation/hwmon/peci-cputemp b/Documentation/hwmon/peci-cputemp
> new file mode 100644
> index 000000000000..821a9258f2e6
> --- /dev/null
> +++ b/Documentation/hwmon/peci-cputemp
> @@ -0,0 +1,78 @@
> +Kernel driver peci-cputemp
> +==========================
> +
> +Supported chips:
> + One of Intel server CPUs listed below which is connected to a PECI bus.
> + * Intel Xeon E5/E7 v3 server processors
> + Intel Xeon E5-14xx v3 family
> + Intel Xeon E5-24xx v3 family
> + Intel Xeon E5-16xx v3 family
> + Intel Xeon E5-26xx v3 family
> + Intel Xeon E5-46xx v3 family
> + Intel Xeon E7-48xx v3 family
> + Intel Xeon E7-88xx v3 family
> + * Intel Xeon E5/E7 v4 server processors
> + Intel Xeon E5-16xx v4 family
> + Intel Xeon E5-26xx v4 family
> + Intel Xeon E5-46xx v4 family
> + Intel Xeon E7-48xx v4 family
> + Intel Xeon E7-88xx v4 family
> + * Intel Xeon Scalable server processors
> + Intel Xeon Bronze family
> + Intel Xeon Silver family
> + Intel Xeon Gold family
> + Intel Xeon Platinum family
> + Addresses scanned: PECI client address 0x30 - 0x37
> + Datasheet: Available from http://www.intel.com/design/literature.htm
> +
> +Author:
> + Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> +
> +Description
> +-----------
> +
> +This driver implements a generic PECI hwmon feature which provides Digital
> +Thermal Sensor (DTS) thermal readings of the CPU package and CPU cores that are
> +accessible using the PECI Client Command Suite via the processor PECI client.
> +
> +All temperature values are given in millidegree Celsius and will be measurable
> +only when the target CPU is powered on.
> +
> +sysfs attributes
> +----------------
> +
> +temp1_label "Die"
> +temp1_input Provides current die temperature of the CPU package.
> +temp1_max Provides thermal control temperature of the CPU package
> + which is also known as Tcontrol.
> +temp1_crit Provides shutdown temperature of the CPU package which
> + is also known as the maximum processor junction
> + temperature, Tjmax or Tprochot.
> +temp1_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
> + the CPU package.
> +
> +temp2_label "Tcontrol"
> +temp2_input Provides current Tcontrol temperature of the CPU
> + package which is also known as Fan Temperature target.
> + Indicates the relative value from thermal monitor trip
> + temperature at which fans should be engaged.
> +temp2_crit Provides Tcontrol critical value of the CPU package
> + which is same to Tjmax.
> +
> +temp3_label "Tthrottle"
> +temp3_input Provides current Tthrottle temperature of the CPU
> + package. Used for throttling temperature. If this value
> + is allowed and lower than Tjmax - the throttle will
> + occur and reported at lower than Tjmax.
> +
> +temp4_label "Tjmax"
> +temp4_input Provides the maximum junction temperature, Tjmax of the
> + CPU package.
> +
> +temp[5-*]_label Provides string "Core X", where X is resolved core
> + number.
> +temp[5-*]_input Provides current temperature of each core.
> +temp[5-*]_max Provides thermal control temperature of the core.
> +temp[5-*]_crit Provides shutdown temperature of the core.
> +temp[5-*]_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
> + the core.
> diff --git a/Documentation/hwmon/peci-dimmtemp b/Documentation/hwmon/peci-dimmtemp
> new file mode 100644
> index 000000000000..c54f2526188c
> --- /dev/null
> +++ b/Documentation/hwmon/peci-dimmtemp
> @@ -0,0 +1,50 @@
> +Kernel driver peci-dimmtemp
> +===========================
> +
> +Supported chips:
> + One of Intel server CPUs listed below which is connected to a PECI bus.
> + * Intel Xeon E5/E7 v3 server processors
> + Intel Xeon E5-14xx v3 family
> + Intel Xeon E5-24xx v3 family
> + Intel Xeon E5-16xx v3 family
> + Intel Xeon E5-26xx v3 family
> + Intel Xeon E5-46xx v3 family
> + Intel Xeon E7-48xx v3 family
> + Intel Xeon E7-88xx v3 family
> + * Intel Xeon E5/E7 v4 server processors
> + Intel Xeon E5-16xx v4 family
> + Intel Xeon E5-26xx v4 family
> + Intel Xeon E5-46xx v4 family
> + Intel Xeon E7-48xx v4 family
> + Intel Xeon E7-88xx v4 family
> + * Intel Xeon Scalable server processors
> + Intel Xeon Bronze family
> + Intel Xeon Silver family
> + Intel Xeon Gold family
> + Intel Xeon Platinum family
> + Addresses scanned: PECI client address 0x30 - 0x37
> + Datasheet: Available from http://www.intel.com/design/literature.htm
> +
> +Author:
> + Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> +
> +Description
> +-----------
> +
> +This driver implements a generic PECI hwmon feature which provides Digital
> +Thermal Sensor (DTS) thermal readings of DIMM components that are accessible
> +using the PECI Client Command Suite via the processor PECI client.
> +
> +All temperature values are given in millidegree Celsius and will be measurable
> +only when the target CPU is powered on.
> +
> +sysfs attributes
> +----------------
> +
> +temp[N]_label Provides string "DIMM CI", where C is DIMM channel and
> + I is DIMM index of the populated DIMM.
> +temp[N]_input Provides current temperature of the populated DIMM.
> +
> +Note:
> + DIMM temperature attributes will appear when the client CPU's BIOS
> + completes memory training and testing.
> --
> 2.17.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] PCI: move early dump functionality from x86 arch into the common code
From: Bjorn Helgaas @ 2018-06-01 18:53 UTC (permalink / raw)
To: Sinan Kaya
Cc: linux-pci, timur, Kate Stewart, open list:DOCUMENTATION,
Petr Tesarik, Ram Pai, Kai-Heng Feng, H. Peter Anvin,
Boris Ostrovsky, Christoffer Dall, Jonathan Corbet,
maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT, Ingo Molnar,
David Rientjes, Thymo van Beers, Borislav Petkov, Tom Lendacky,
Marc Zyngier, linux-arm-msm, Frederic Weisbecker, Mikulas Patocka,
Andy Lutomirski, Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Juergen Gross, Dou Liyang, Paul E. McKenney, Greg Kroah-Hartman,
open list, Philippe Ombredanne
In-Reply-To: <1527878854-21419-1-git-send-email-okaya@codeaurora.org>
On Fri, Jun 01, 2018 at 02:47:28PM -0400, Sinan Kaya wrote:
> Move early dump functionality into common code so that it is available for
> all archtiectures. No need to carry arch specific reads around as the read
> hooks are already initialized by the time pci_setup_device() is getting
> called during scan.
> +static void early_dump_pci_device(struct pci_dev *pdev)
> +{
> + u32 value[256 / 4];
> + int i;
> +
> + if (!pci_early_dump)
> + return;
> +
> + pci_info(pdev, "pci 0000:%02x:%02x.%d config space:\n",
> + pdev->bus->number, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn));
I'm still missing something -- why go to the trouble of pdev->bus->number,
PCI_SLOT(), etc? Isn't the output going to look like this?
pci 0000:00:00.0: pci 0000:00:00.0 config space:
In other words, wouldn't the following be enough?
pci_info(pdev, "config space:\n");
> +
> + for (i = 0; i < 256; i += 4)
> + pci_read_config_dword(pdev, i, &value[i / 4]);
> +
> + print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
> + 256, false);
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 18:47 UTC (permalink / raw)
To: linux-pci, timur
Cc: linux-arm-msm, linux-arm-kernel, Sinan Kaya, Jonathan Corbet,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Paul E. McKenney, Christoffer Dall, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Greg Kroah-Hartman,
David Rientjes, Philippe Ombredanne, Kate Stewart, Juergen Gross,
Tom Lendacky, Borislav Petkov, Mikulas Patocka, Petr Tesarik,
Andy Lutomirski, Dou Liyang, Ram Pai, Boris Ostrovsky,
open list:DOCUMENTATION, open list
Move early dump functionality into common code so that it is available for
all archtiectures. No need to carry arch specific reads around as the read
hooks are already initialized by the time pci_setup_device() is getting
called during scan.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/pci-direct.h | 5 ---
arch/x86/kernel/setup.c | 5 ---
arch/x86/pci/common.c | 4 ---
arch/x86/pci/early.c | 44 -------------------------
drivers/pci/pci.c | 5 +++
drivers/pci/pci.h | 1 +
drivers/pci/probe.c | 21 ++++++++++++
8 files changed, 28 insertions(+), 59 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e490902..e64f1d8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2995,7 +2995,7 @@
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
- earlydump [X86] dump PCI config space before the kernel
+ earlydump dump PCI config space before the kernel
changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
diff --git a/arch/x86/include/asm/pci-direct.h b/arch/x86/include/asm/pci-direct.h
index e1084f7..e5e2129 100644
--- a/arch/x86/include/asm/pci-direct.h
+++ b/arch/x86/include/asm/pci-direct.h
@@ -14,9 +14,4 @@ extern void write_pci_config(u8 bus, u8 slot, u8 func, u8 offset, u32 val);
extern void write_pci_config_byte(u8 bus, u8 slot, u8 func, u8 offset, u8 val);
extern void write_pci_config_16(u8 bus, u8 slot, u8 func, u8 offset, u16 val);
-extern int early_pci_allowed(void);
-
-extern unsigned int pci_early_dump_regs;
-extern void early_dump_pci_device(u8 bus, u8 slot, u8 func);
-extern void early_dump_pci_devices(void);
#endif /* _ASM_X86_PCI_DIRECT_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2f86d88..480f250 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -991,11 +991,6 @@ void __init setup_arch(char **cmdline_p)
setup_clear_cpu_cap(X86_FEATURE_APIC);
}
-#ifdef CONFIG_PCI
- if (pci_early_dump_regs)
- early_dump_pci_devices();
-#endif
-
e820__reserve_setup_data();
e820__finish_early_params();
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 563049c..d4ec117 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -22,7 +22,6 @@
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2 |
PCI_PROBE_MMCONF;
-unsigned int pci_early_dump_regs;
static int pci_bf_sort;
int pci_routeirq;
int noioapicquirk;
@@ -599,9 +598,6 @@ char *__init pcibios_setup(char *str)
pci_probe |= PCI_BIG_ROOT_WINDOW;
return NULL;
#endif
- } else if (!strcmp(str, "earlydump")) {
- pci_early_dump_regs = 1;
- return NULL;
} else if (!strcmp(str, "routeirq")) {
pci_routeirq = 1;
return NULL;
diff --git a/arch/x86/pci/early.c b/arch/x86/pci/early.c
index e5f753c..f5fc953 100644
--- a/arch/x86/pci/early.c
+++ b/arch/x86/pci/early.c
@@ -57,47 +57,3 @@ int early_pci_allowed(void)
PCI_PROBE_CONF1;
}
-void early_dump_pci_device(u8 bus, u8 slot, u8 func)
-{
- u32 value[256 / 4];
- int i;
-
- pr_info("pci 0000:%02x:%02x.%d config space:\n", bus, slot, func);
-
- for (i = 0; i < 256; i += 4)
- value[i / 4] = read_pci_config(bus, slot, func, i);
-
- print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value, 256, false);
-}
-
-void early_dump_pci_devices(void)
-{
- unsigned bus, slot, func;
-
- if (!early_pci_allowed())
- return;
-
- for (bus = 0; bus < 256; bus++) {
- for (slot = 0; slot < 32; slot++) {
- for (func = 0; func < 8; func++) {
- u32 class;
- u8 type;
-
- class = read_pci_config(bus, slot, func,
- PCI_CLASS_REVISION);
- if (class == 0xffffffff)
- continue;
-
- early_dump_pci_device(bus, slot, func);
-
- if (func == 0) {
- type = read_pci_config_byte(bus, slot,
- func,
- PCI_HEADER_TYPE);
- if (!(type & 0x80))
- break;
- }
- }
- }
- }
-}
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97acba7..04052dc 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -115,6 +115,9 @@ static bool pcie_ari_disabled;
/* If set, the PCIe ATS capability will not be used. */
static bool pcie_ats_disabled;
+/* If set, the PCI config space of each device is printed during boot. */
+bool pci_early_dump;
+
bool pci_ats_disabled(void)
{
return pcie_ats_disabled;
@@ -5805,6 +5808,8 @@ static int __init pci_setup(char *str)
pcie_ats_disabled = true;
} else if (!strcmp(str, "noaer")) {
pci_no_aer();
+ } else if (!strcmp(str, "earlydump")) {
+ pci_early_dump = true;
} else if (!strncmp(str, "realloc=", 8)) {
pci_realloc_get_opt(str + 8);
} else if (!strncmp(str, "realloc", 7)) {
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a0..c33265e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -7,6 +7,7 @@
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
extern const unsigned char pcie_link_speed[];
+extern bool pci_early_dump;
bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 56771f3..7490f78fa 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1545,6 +1545,25 @@ static int pci_intx_mask_broken(struct pci_dev *dev)
return 0;
}
+static void early_dump_pci_device(struct pci_dev *pdev)
+{
+ u32 value[256 / 4];
+ int i;
+
+ if (!pci_early_dump)
+ return;
+
+ pci_info(pdev, "pci 0000:%02x:%02x.%d config space:\n",
+ pdev->bus->number, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn));
+
+ for (i = 0; i < 256; i += 4)
+ pci_read_config_dword(pdev, i, &value[i / 4]);
+
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
+ 256, false);
+}
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -1594,6 +1613,8 @@ int pci_setup_device(struct pci_dev *dev)
pci_printk(KERN_DEBUG, dev, "[%04x:%04x] type %02x class %#08x\n",
dev->vendor, dev->device, dev->hdr_type, dev->class);
+ early_dump_pci_device(dev);
+
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH linux-next v5 10/13] Documentation: hwmon: Add documents for PECI hwmon client drivers
From: Jae Hyun Yoo @ 2018-06-01 18:22 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck, Jonathan Corbet, linux-hwmon,
linux-doc, linux-kernel, openbmc
Cc: Jae Hyun Yoo, Jason M Biils, Randy Dunlap
This commit adds hwmon documents for PECI cputemp and dimmtemp drivers.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
---
Documentation/hwmon/peci-cputemp | 78 +++++++++++++++++++++++++++++++
Documentation/hwmon/peci-dimmtemp | 50 ++++++++++++++++++++
2 files changed, 128 insertions(+)
create mode 100644 Documentation/hwmon/peci-cputemp
create mode 100644 Documentation/hwmon/peci-dimmtemp
diff --git a/Documentation/hwmon/peci-cputemp b/Documentation/hwmon/peci-cputemp
new file mode 100644
index 000000000000..821a9258f2e6
--- /dev/null
+++ b/Documentation/hwmon/peci-cputemp
@@ -0,0 +1,78 @@
+Kernel driver peci-cputemp
+==========================
+
+Supported chips:
+ One of Intel server CPUs listed below which is connected to a PECI bus.
+ * Intel Xeon E5/E7 v3 server processors
+ Intel Xeon E5-14xx v3 family
+ Intel Xeon E5-24xx v3 family
+ Intel Xeon E5-16xx v3 family
+ Intel Xeon E5-26xx v3 family
+ Intel Xeon E5-46xx v3 family
+ Intel Xeon E7-48xx v3 family
+ Intel Xeon E7-88xx v3 family
+ * Intel Xeon E5/E7 v4 server processors
+ Intel Xeon E5-16xx v4 family
+ Intel Xeon E5-26xx v4 family
+ Intel Xeon E5-46xx v4 family
+ Intel Xeon E7-48xx v4 family
+ Intel Xeon E7-88xx v4 family
+ * Intel Xeon Scalable server processors
+ Intel Xeon Bronze family
+ Intel Xeon Silver family
+ Intel Xeon Gold family
+ Intel Xeon Platinum family
+ Addresses scanned: PECI client address 0x30 - 0x37
+ Datasheet: Available from http://www.intel.com/design/literature.htm
+
+Author:
+ Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
+
+Description
+-----------
+
+This driver implements a generic PECI hwmon feature which provides Digital
+Thermal Sensor (DTS) thermal readings of the CPU package and CPU cores that are
+accessible using the PECI Client Command Suite via the processor PECI client.
+
+All temperature values are given in millidegree Celsius and will be measurable
+only when the target CPU is powered on.
+
+sysfs attributes
+----------------
+
+temp1_label "Die"
+temp1_input Provides current die temperature of the CPU package.
+temp1_max Provides thermal control temperature of the CPU package
+ which is also known as Tcontrol.
+temp1_crit Provides shutdown temperature of the CPU package which
+ is also known as the maximum processor junction
+ temperature, Tjmax or Tprochot.
+temp1_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
+ the CPU package.
+
+temp2_label "Tcontrol"
+temp2_input Provides current Tcontrol temperature of the CPU
+ package which is also known as Fan Temperature target.
+ Indicates the relative value from thermal monitor trip
+ temperature at which fans should be engaged.
+temp2_crit Provides Tcontrol critical value of the CPU package
+ which is same to Tjmax.
+
+temp3_label "Tthrottle"
+temp3_input Provides current Tthrottle temperature of the CPU
+ package. Used for throttling temperature. If this value
+ is allowed and lower than Tjmax - the throttle will
+ occur and reported at lower than Tjmax.
+
+temp4_label "Tjmax"
+temp4_input Provides the maximum junction temperature, Tjmax of the
+ CPU package.
+
+temp[5-*]_label Provides string "Core X", where X is resolved core
+ number.
+temp[5-*]_input Provides current temperature of each core.
+temp[5-*]_max Provides thermal control temperature of the core.
+temp[5-*]_crit Provides shutdown temperature of the core.
+temp[5-*]_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of
+ the core.
diff --git a/Documentation/hwmon/peci-dimmtemp b/Documentation/hwmon/peci-dimmtemp
new file mode 100644
index 000000000000..c54f2526188c
--- /dev/null
+++ b/Documentation/hwmon/peci-dimmtemp
@@ -0,0 +1,50 @@
+Kernel driver peci-dimmtemp
+===========================
+
+Supported chips:
+ One of Intel server CPUs listed below which is connected to a PECI bus.
+ * Intel Xeon E5/E7 v3 server processors
+ Intel Xeon E5-14xx v3 family
+ Intel Xeon E5-24xx v3 family
+ Intel Xeon E5-16xx v3 family
+ Intel Xeon E5-26xx v3 family
+ Intel Xeon E5-46xx v3 family
+ Intel Xeon E7-48xx v3 family
+ Intel Xeon E7-88xx v3 family
+ * Intel Xeon E5/E7 v4 server processors
+ Intel Xeon E5-16xx v4 family
+ Intel Xeon E5-26xx v4 family
+ Intel Xeon E5-46xx v4 family
+ Intel Xeon E7-48xx v4 family
+ Intel Xeon E7-88xx v4 family
+ * Intel Xeon Scalable server processors
+ Intel Xeon Bronze family
+ Intel Xeon Silver family
+ Intel Xeon Gold family
+ Intel Xeon Platinum family
+ Addresses scanned: PECI client address 0x30 - 0x37
+ Datasheet: Available from http://www.intel.com/design/literature.htm
+
+Author:
+ Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
+
+Description
+-----------
+
+This driver implements a generic PECI hwmon feature which provides Digital
+Thermal Sensor (DTS) thermal readings of DIMM components that are accessible
+using the PECI Client Command Suite via the processor PECI client.
+
+All temperature values are given in millidegree Celsius and will be measurable
+only when the target CPU is powered on.
+
+sysfs attributes
+----------------
+
+temp[N]_label Provides string "DIMM CI", where C is DIMM channel and
+ I is DIMM index of the populated DIMM.
+temp[N]_input Provides current temperature of the populated DIMM.
+
+Note:
+ DIMM temperature attributes will appear when the client CPU's BIOS
+ completes memory training and testing.
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH linux-next v5 02/13] Documentation: ioctl: Add ioctl numbers for PECI subsystem
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
To: Jonathan Corbet, Martin K . Petersen, Darrick J . Wong,
Greg Kroah-Hartman, Bryant G . Ly, Michael Ellerman,
Tomohiro Kusumi, Frederic Barrat, Eric Sandeen, Arnd Bergmann,
Matthew R . Ochs, linux-doc, linux-kernel, openbmc
Cc: Jae Hyun Yoo, James Feist, Jason M Biils, Vernon Mauery
This commit updates ioctl-number.txt to reflect ioctl numbers used
by the PECI subsystem.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Cc: James Feist <james.feist@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
---
Documentation/ioctl/ioctl-number.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 480c8609dc58..1670ca4072b2 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -322,6 +322,8 @@ Code Seq#(hex) Include File Comments
0xB3 00 linux/mmc/ioctl.h
0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org>
0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org>
+0xB6 00-0F uapi/linux/peci-ioctl.h PECI subsystem
+ <mailto:jae.hyun.yoo@linux.intel.com>
0xC0 00-0F linux/usb/iowarrior.h
0xCA 00-0F uapi/misc/cxl.h
0xCA 10-2F uapi/misc/ocxl.h
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH linux-next v5 00/13] PECI device driver introduction
From: Jae Hyun Yoo @ 2018-06-01 18:20 UTC (permalink / raw)
To: Alan Cox, Andrew Jeffery, Andrew Lunn, Andy Shevchenko,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Rob Herring,
Ryan Chen, Stef van Os, Sumeet R Pawnikar, Vernon Mauery
Cc: linux-kernel, linux-doc, devicetree, linux-hwmon,
linux-arm-kernel, linux-aspeed, openbmc, Jae Hyun Yoo
Introduction of the Platform Environment Control Interface (PECI) bus
device driver. PECI is a one-wire bus interface that provides a
communication channel between an Intel processor and chipset components to
external monitoring or control devices. PECI is designed to support the
following sideband functions:
* Processor and DRAM thermal management
- Processor fan speed control is managed by comparing Digital Thermal
Sensor (DTS) thermal readings acquired via PECI against the
processor-specific fan speed control reference point, or TCONTROL. Both
TCONTROL and DTS thermal readings are accessible via the processor PECI
client. These variables are referenced to a common temperature, the TCC
activation point, and are both defined as negative offsets from that
reference.
- PECI based access to the processor package configuration space provides
a means for Baseboard Management Controllers (BMC) or other platform
management devices to actively manage the processor and memory power
and thermal features.
* Platform Manageability
- Platform manageability functions including thermal, power, and error
monitoring. Note that platform 'power' management includes monitoring
and control for both the processor and DRAM subsystem to assist with
data center power limiting.
- PECI allows read access to certain error registers in the processor MSR
space and status monitoring registers in the PCI configuration space
within the processor and downstream devices.
- PECI permits writes to certain registers in the processor PCI
configuration space.
* Processor Interface Tuning and Diagnostics
- Processor interface tuning and diagnostics capabilities
(Intel Interconnect BIST). The processors Intel Interconnect Built In
Self Test (Intel IBIST) allows for infield diagnostic capabilities in
the Intel UPI and memory controller interfaces. PECI provides a port to
execute these diagnostics via its PCI Configuration read and write
capabilities.
* Failure Analysis
- Output the state of the processor after a failure for analysis via
Crashdump.
PECI uses a single wire for self-clocking and data transfer. The bus
requires no additional control lines. The physical layer is a self-clocked
one-wire bus that begins each bit with a driven, rising edge from an idle
level near zero volts. The duration of the signal driven high depends on
whether the bit value is a logic '0' or logic '1'. PECI also includes
variable data transfer rate established with every message. In this way, it
is highly flexible even though underlying logic is simple.
The interface design was optimized for interfacing between an Intel
processor and chipset components in both single processor and multiple
processor environments. The single wire interface provides low board
routing overhead for the multiple load connections in the congested routing
area near the processor and chipset components. Bus speed, error checking,
and low protocol overhead provides adequate link bandwidth and reliability
to transfer critical device operating conditions and configuration
information.
This implementation provides the basic framework to add PECI extensions to
the Linux bus and device models. A hardware specific 'Adapter' driver can
be attached to the PECI bus to provide sideband functions described above.
It is also possible to access all devices on an adapter from userspace
through the /dev interface. A device specific 'Client' driver also can be
attached to the PECI bus so each processor client's features can be
supported by the 'Client' driver through an adapter connection in the bus.
This patch set includes Aspeed 24xx/25xx PECI driver and PECI
cputemp/dimmtemp drivers as the first implementation for both adapter and
client drivers on the PECI bus framework.
Please review.
Thanks,
-Jae
Changes since v4:
* Fixed an incorrect endianness handling in peci-aspeed.
* Added a comment to explain about the asm/intel-family.h inclusion.
* Added an MFD module to support multi-function PECI client devices.
Changes since v3:
* Made code more simple and compact.
* Removed unused header file inclusion.
* Fixed incorrect error return values and messages.
* Removed DTS margin temperature from the peci-cputemp.
* Made some magic numbers use defines.
* Moved peci_get_cpu_id() into peci-core as a common function.
* Replaced the cancel_delayed_work() call with a cancel_delayed_work_sync().
* Replaced AST and Aspeed uses with ASPEED.
* Simplified peci command timeout checking logic using
regmap_read_poll_timeout().
* Simplified endian swap codes using endian handling macros.
* Dropped regmap read/write error checking except for the first access.
* Added a PECI reset setting in the device tree node.
* Removed unnecessary sleep from the probe context.
* Removed IRQF_SHARED flag from irq request code in the ASPEED PECI driver.
* Fixed typos in documents.
* Combined peci-bus.txt, peci-adapter.txt and peci-client.txt into peci.txt.
* Fixed and swept documents to drop some incorrect or unnecessary
descriptions.
* Fixed device tree to make unit-address format use reg contents.
* Simplified bit manipulations using <linux/bitfield.h>.
* Made client CPU model checking use <asm/intel-family.h> if available.
* Modified adapter heap allocation method to use kobject reference count
based.
* Added the low-level PECI xfer IOCTL again to support the Redfish
requirement.
* Added PM domain attach/detach code.
* Added logic for device instantiation through sysfs.
* Fix a bug of interrupt status checking code in peci-aspeed driver.
Changes since v2:
* Divided peci-hwmon driver into two drivers, peci-cputemp and
peci-dimmtemp.
* Added generic dt binding documents for PECI bus, adapter and client.
* Removed in_atomic() call from the PECI core driver.
* Improved PECI commands masking logic.
* Added permission check logic for PECI ioctls.
* Removed unnecessary type casts.
* Fixed some invalid error return codes.
* Added the mark_updated() function to improve update interval checking
logic.
* Fixed a bug in populated DIMM checking function.
* Fixed some typo, grammar and style issues in documents.
* Rewrote hwmon drivers to use devm_hwmon_device_register_with_info API.
* Made peci_match_id() function as a static.
* Replaced a deprecated create_singlethread_workqueue() call with an
alloc_ordered_workqueue() call.
* Reordered local variable definitions in reversed xmas tree notation.
* Listed up client CPUs that can be supported by peci-cputemp and
peci-dimmtemp hwmon drivers.
* Added CPU generation detection logic which checks CPUID signature through
PECI connection.
* Improved interrupt handling logic in the Aspeed PECI adapter driver.
* Fixed SPDX license identifier style in header files.
* Changed some macros in peci.h to static inline functions.
* Dropped sleepable context checking code in peci-core.
* Adjusted rt_mutex protection scope in peci-core.
* Moved adapter->xfer() checking code into peci_register_adapter().
* Improved PECI command retry checking logic.
* Changed ioctl base from 'P' to 0xb6 to avoid confiliction and updated
ioctl-number.txt to reflect the ioctl number of PECI subsystem.
* Added a comment to describe PECI retry action.
* Simplified return code handling of peci_ioctl_ping().
* Changed type of peci_ioctl_fn[] to static const.
* Fixed range checking code for valid PECI commands.
* Fixed the error return code on invalid PECI commands.
* Fixed incorrect definitions of PECI ioctl and its handling logic.
Changes since v1:
* Additionally implemented a core driver to support PECI linux bus driver
model.
* Modified Aspeed PECI driver to make that to be an adapter driver in PECI
bus.
* Modified PECI hwmon driver to make that to be a client driver in PECI
bus.
* Simplified hwmon driver attribute labels and removed redundant strings.
* Removed core_nums from device tree setting of hwmon driver and modified
core number detection logic to check the resolved_core register in client
CPU's local PCI configuration area.
* Removed dimm_nums from device tree setting of hwmon driver and added
populated DIMM detection logic to support dynamic creation.
* Removed indexing gap on core temperature and DIMM temperature attributes.
* Improved hwmon registration and dynamic attribute creation logic.
* Fixed structure definitions in PECI uapi header to make that use __u8,
__u16 and etc.
* Modified wait_for_completion_interruptible_timeout error handling logic
in Aspeed PECI driver to deliver errors correctly.
* Removed low-level xfer command from ioctl and kept only high-level PECI
command suite as ioctls.
* Fixed I/O timeout logic in Aspeed PECI driver using ktime.
* Added a function into hwmon driver to simplify update delay checking.
* Added a function into hwmon driver to convert 10.6 to millidegree.
* Dropped non-standard attributes in hwmon driver.
* Fixed OF table for hwmon to make it indicate as a PECI client of Intel
CPU target.
* Added a maintainer of PECI subsystem into MAINTAINERS document.
Jae Hyun Yoo (13):
dt-bindings: Add a document of PECI subsystem
Documentation: ioctl: Add ioctl numbers for PECI subsystem
drivers/peci: Add support for PECI bus driver core
dt-bindings: Add a document of PECI adapter driver for ASPEED
AST24xx/25xx SoCs
ARM: dts: aspeed: peci: Add PECI node
drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx
dt-bindings: mfd: Add a document for PECI client mfd
drivers/mfd: Add PECI client mfd driver
dt-bindings: hwmon: Add documents for PECI hwmon client drivers
Documentation: hwmon: Add documents for PECI hwmon client drivers
drivers/hwmon: Add PECI cputemp driver
drivers/hwmon: Add PECI dimmtemp driver
Add maintainers for the PECI subsystem
.../bindings/hwmon/peci-cputemp.txt | 11 +
.../bindings/hwmon/peci-dimmtemp.txt | 13 +
.../devicetree/bindings/mfd/peci-client.txt | 23 +
.../devicetree/bindings/peci/peci-aspeed.txt | 57 +
.../devicetree/bindings/peci/peci.txt | 59 +
Documentation/hwmon/peci-cputemp | 78 +
Documentation/hwmon/peci-dimmtemp | 50 +
Documentation/ioctl/ioctl-number.txt | 2 +
MAINTAINERS | 12 +
arch/arm/boot/dts/aspeed-g4.dtsi | 26 +
arch/arm/boot/dts/aspeed-g5.dtsi | 26 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/hwmon/Kconfig | 28 +
drivers/hwmon/Makefile | 2 +
drivers/hwmon/peci-cputemp.c | 401 +++++
drivers/hwmon/peci-dimmtemp.c | 295 ++++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/peci-client.c | 205 +++
drivers/peci/Kconfig | 40 +
drivers/peci/Makefile | 9 +
drivers/peci/peci-aspeed.c | 498 ++++++
drivers/peci/peci-core.c | 1439 +++++++++++++++++
include/linux/mfd/peci-client.h | 60 +
include/linux/peci.h | 104 ++
include/uapi/linux/peci-ioctl.h | 265 +++
27 files changed, 3718 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
create mode 100644 Documentation/devicetree/bindings/mfd/peci-client.txt
create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
create mode 100644 Documentation/devicetree/bindings/peci/peci.txt
create mode 100644 Documentation/hwmon/peci-cputemp
create mode 100644 Documentation/hwmon/peci-dimmtemp
create mode 100644 drivers/hwmon/peci-cputemp.c
create mode 100644 drivers/hwmon/peci-dimmtemp.c
create mode 100644 drivers/mfd/peci-client.c
create mode 100644 drivers/peci/Kconfig
create mode 100644 drivers/peci/Makefile
create mode 100644 drivers/peci/peci-aspeed.c
create mode 100644 drivers/peci/peci-core.c
create mode 100644 include/linux/mfd/peci-client.h
create mode 100644 include/linux/peci.h
create mode 100644 include/uapi/linux/peci-ioctl.h
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] clk: renesas: cpg-mssr: Stop using printk format %pCr
From: Stephen Boyd @ 2018-06-01 16:37 UTC (permalink / raw)
To: Eduardo Valentin, Eric Anholt, Geert Uytterhoeven,
Greg Kroah-Hartman, Jia-Ju Bai, Jonathan Corbet,
Michael Turquette, Stefan Wahren, Zhang Rui
Cc: Petr Mladek, Sergey Senozhatsky, Geert Uytterhoeven, linux-doc,
linux-pm, linux-kernel, Steven Rostedt, linux-renesas-soc,
linux-serial, Linus Torvalds, linux-clk, linux-arm-kernel
In-Reply-To: <1527845302-12159-2-git-send-email-geert+renesas@glider.be>
Quoting Geert Uytterhoeven (2018-06-01 02:28:19)
> Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
> called in atomic context.
>
> Replace it by open-coding the operation. This is safe here, as the code
> runs in task context.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] PCI: Allow specifying devices using a base bus and path of devfns
From: Logan Gunthorpe @ 2018-06-01 15:47 UTC (permalink / raw)
To: Alex Williamson
Cc: linux-kernel, linux-pci, linux-doc, Stephen Bates,
Christoph Hellwig, Bjorn Helgaas, Jonathan Corbet, Ingo Molnar,
Thomas Gleixner, Paul E. McKenney, Marc Zyngier, Kai-Heng Feng,
Frederic Weisbecker, Dan Williams, Jérôme Glisse,
Benjamin Herrenschmidt, Christian König
In-Reply-To: <20180601083000.62d10d14@t450s.home>
On 01/06/18 08:30 AM, Alex Williamson wrote:
> Cool, I'm glad this worked. I note though that there's really not much
> difference between:
>
> [domain:]bus:slot.fn
>
> and
>
> [domain:]bus:slot.fn[/slot.fn[/slot.fn[/...]]]
>
> IOW, what's defined here as the "path:" specification doesn't require
> that we start at a root bus device, it can really specify a path
> starting anywhere, including the target device directly. So can we
> simply extend domain:bus:slot.fn to support paths without a separate
> identifier? Thanks,
Yes, I think you are right. I was just hesitant to change existing
behavior. But if that's the consensus I'll change it for v3.
Thanks,
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] PCI: Allow specifying devices using a base bus and path of devfns
From: Logan Gunthorpe @ 2018-06-01 15:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux Kernel Mailing List, linux-pci, Linux Documentation List,
Stephen Bates, Christoph Hellwig, Bjorn Helgaas, Jonathan Corbet,
Ingo Molnar, Thomas Gleixner, Paul E. McKenney, Marc Zyngier,
Kai-Heng Feng, Frederic Weisbecker, Dan Williams,
Jérôme Glisse, Benjamin Herrenschmidt, Alex Williamson,
Christian König
In-Reply-To: <CAHp75Vc4yxeM+jz2biMBoWB-h_dG1_Qx91VCP+f1mhvvgPVPxQ@mail.gmail.com>
On 01/06/18 04:41 AM, Andy Shevchenko wrote:
>> - specified in one of two formats:
>> + specified in one of three formats:
>
> ...in one of the following formats:
>
> in the first place and don't fix it each time you add/remove one?
Sure, I'll make the change in v3.
Thanks,
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/3] PCI: Make specifying PCI devices in kernel parameters reusable
From: Logan Gunthorpe @ 2018-06-01 15:46 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux Kernel Mailing List, linux-pci, Linux Documentation List,
Stephen Bates, Christoph Hellwig, Bjorn Helgaas, Jonathan Corbet,
Ingo Molnar, Thomas Gleixner, Paul E. McKenney, Marc Zyngier,
Kai-Heng Feng, Frederic Weisbecker, Dan Williams,
Jérôme Glisse, Benjamin Herrenschmidt, Alex Williamson,
Christian König
In-Reply-To: <CAHp75VcQwDGqND8v1RTo4+6Hyf9G5_2w9x9aiVONwKXsTKgJ1Q@mail.gmail.com>
On 01/06/18 04:39 AM, Andy Shevchenko wrote:
>> - pci=option[,option...] [PCI] various PCI subsystem options:
>> + pci=option[,option...] [PCI] various PCI subsystem options.
>> +
>> + Some options herein operate on a specific device
>> + or a set of devices (<pci_dev>). These are
>> + specified in one of two formats:
>
> I would rather to add
>
> <pci_dev>
>
> here in the same way as done for options.
> It would be easy for people to find a referenced paragraph.
Sorry, I don't understand what you are asking. Can you be more specific?
>> +
>> + [<domain>:]<bus>:<slot>.<func>
>> + pci:<vendor>:<device>[:<subvendor>:<subdevice>]
>> +
>> + Note: the first format specifies a PCI
>> + bus/slot/function address which may change
>> + if new hardware is inserted, if motherboard
>> + firmware changes, or due to changes caused
>> + by other kernel parameters. The second format
>> + selects devices using IDs from the
>> + configuration space which may match multiple
>> + devices in the system.
>
>> +static int pci_dev_str_match(struct pci_dev *dev, const char *p,
>> + const char **endptr)
>
> This change I hope has no functional alteration, so, can be split to a
> separate patch.
That's all this patch does... Or do you want be to separate out
documentation from implementation? That just seems a bit excessive to me.
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] lib/vsprintf: Remove atomic-unsafe support for printk format %pCr
From: Geert Uytterhoeven @ 2018-06-01 15:28 UTC (permalink / raw)
To: Petr Mladek
Cc: Linus Torvalds, Geert Uytterhoeven, Jia-Ju Bai, Jonathan Corbet,
Michael Turquette, Stephen Boyd, Zhang Rui, Eduardo Valentin,
Eric Anholt, Stefan Wahren, Greg Kroah-Hartman,
Sergey Senozhatsky, Steven Rostedt, open list:DOCUMENTATION,
linux-clk, Linux PM, linux-serial, linux-arm-kernel,
Linux-Renesas, Linux Kernel Mailing List, stable
In-Reply-To: <20180601151905.yilldc6vbachfw4k@pathway.suse.cz>
Hi Petr,
On Fri, Jun 1, 2018 at 5:19 PM, Petr Mladek <pmladek@suse.com> wrote:
> On Fri 2018-06-01 13:47:38, Petr Mladek wrote:
>> On Fri 2018-06-01 06:00:47, Linus Torvalds wrote:
>> > On Fri, Jun 1, 2018 at 4:29 AM Geert Uytterhoeven
>> > <geert+renesas@glider.be> wrote:
>> > >
>> > > This patch series:
>> > > - Changes all existing users of "%pCr" to print the result of
>> > > clk_get_rate() directly, which is safe as they all do this in task
>> > > context only,
>> > > - Removes support for the "%pCr" printk format.
>> >
>> > Looks good to me.
>> >
>> > What tree will this go through? The normal printk one? Just checking
>> > that this doesn't end up falling through the cracks because nobody
>> > knows who would take it...
>>
>> I will take it via printk.git. There already is bunch of vsprintf
>> changes for-4.18.
>
> It is in printk.git, branch for-4.18-vsprintf-pcr-removal now.
Thank you.
> Also I have added Cc: stable@vger.kernel.org into the commit messages.
I can confirm all stable version references ("v4.x+") match.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 15:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-pci, Timur Tabi, linux-arm-msm, linux-arm Mailing List,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Christoffer Dall, Paul E. McKenney, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, David Rientjes, Kate Stewart,
Philippe Ombredanne, Tom Lendacky, Juergen Gross, Borislav Petkov,
Mikulas Patocka, Petr Tesarik, Andy Lutomirski, Dou Liyang,
Ram Pai, Boris Ostrovsky, open list:DOCUMENTATION, open list
In-Reply-To: <CAHp75VdTyvQOqnSm67Uo5heP1otE98BbquM0TjSAorEzTgUwHQ@mail.gmail.com>
On 6/1/2018 11:24 AM, Andy Shevchenko wrote:
>> This was discussed here:
>>
>> https://www.spinics.net/lists/linux-pci/msg72859.html
> I understand what is it. What I'm pointing is the variable in the
> source without any comment. In the context you have in diff previous
> one has a comment.
oh, ok. I can take care of that too.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Andy Shevchenko @ 2018-06-01 15:24 UTC (permalink / raw)
To: Sinan Kaya
Cc: linux-pci, Timur Tabi, linux-arm-msm, linux-arm Mailing List,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Christoffer Dall, Paul E. McKenney, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, David Rientjes, Kate Stewart,
Philippe Ombredanne, Tom Lendacky, Juergen Gross, Borislav Petkov,
Mikulas Patocka, Petr Tesarik, Andy Lutomirski, Dou Liyang,
Ram Pai, Boris Ostrovsky, open list:DOCUMENTATION, open list
In-Reply-To: <53e4d6c3-ee19-fd04-4ba3-862d04558689@codeaurora.org>
On Fri, Jun 1, 2018 at 6:06 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 6/1/2018 11:02 AM, Andy Shevchenko wrote:
>> On Wed, May 30, 2018 at 7:34 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
>>> Move early dump functionality into common code so that it is available for
>>> all archtiectures. No need to carry arch specific reads around as the read
>>> hooks are already initialized by the time pci_setup_device() is getting
>>> called during scan.
>>
>>> /* If set, the PCIe ATS capability will not be used. */
>>> static bool pcie_ats_disabled;
>>>
>>> +bool pci_early_dump;
>>> +
>>
>> I didn't check above these, but maybe a good idea to add one line
>> comment what is this about?
>
> This was discussed here:
>
> https://www.spinics.net/lists/linux-pci/msg72859.html
I understand what is it. What I'm pointing is the variable in the
source without any comment. In the context you have in diff previous
one has a comment.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/4] lib/vsprintf: Remove atomic-unsafe support for printk format %pCr
From: Petr Mladek @ 2018-06-01 15:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Geert Uytterhoeven, baijiaju1990, Jonathan Corbet,
Michael Turquette, sboyd, Zhang Rui, Eduardo Valentin,
Eric Anholt, Stefan Wahren, Greg Kroah-Hartman,
Sergey Senozhatsky, Steven Rostedt, open list:DOCUMENTATION,
linux-clk, Linux PM, linux-serial, linux-arm-kernel,
Linux-Renesas, Linux Kernel Mailing List, stable
In-Reply-To: <20180601114738.kdoggkha2yosjgbv@pathway.suse.cz>
On Fri 2018-06-01 13:47:38, Petr Mladek wrote:
> On Fri 2018-06-01 06:00:47, Linus Torvalds wrote:
> > On Fri, Jun 1, 2018 at 4:29 AM Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> > >
> > > This patch series:
> > > - Changes all existing users of "%pCr" to print the result of
> > > clk_get_rate() directly, which is safe as they all do this in task
> > > context only,
> > > - Removes support for the "%pCr" printk format.
> >
> > Looks good to me.
> >
> > What tree will this go through? The normal printk one? Just checking
> > that this doesn't end up falling through the cracks because nobody
> > knows who would take it...
>
> I will take it via printk.git. There already is bunch of vsprintf
> changes for-4.18.
It is in printk.git, branch for-4.18-vsprintf-pcr-removal now.
Also I have added Cc: stable@vger.kernel.org into the commit messages.
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 15:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-pci, Timur Tabi, linux-arm-msm, linux-arm Mailing List,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Christoffer Dall, Paul E. McKenney, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, David Rientjes, Kate Stewart,
Philippe Ombredanne, Tom Lendacky, Juergen Gross, Borislav Petkov,
Mikulas Patocka, Petr Tesarik, Andy Lutomirski, Dou Liyang,
Ram Pai, Boris Ostrovsky, open list:DOCUMENTATION, open list
In-Reply-To: <CAHp75Vc3YKAR1P_F0fwD+ueGub4gVUjP0=wv4Egf_fTSVkSUjw@mail.gmail.com>
On 6/1/2018 11:02 AM, Andy Shevchenko wrote:
> On Wed, May 30, 2018 at 7:34 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> Move early dump functionality into common code so that it is available for
>> all archtiectures. No need to carry arch specific reads around as the read
>> hooks are already initialized by the time pci_setup_device() is getting
>> called during scan.
>
>> /* If set, the PCIe ATS capability will not be used. */
>> static bool pcie_ats_disabled;
>>
>> +bool pci_early_dump;
>> +
>
> I didn't check above these, but maybe a good idea to add one line
> comment what is this about?
This was discussed here:
https://www.spinics.net/lists/linux-pci/msg72859.html
>
>
>> extern const unsigned char pcie_link_speed[];
>> -
>> +extern bool pci_early_dump;
>> bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
>>
>
> Hmm... I would rather not attach this line to some function declarations.
Sure
>
>> +static void early_dump_pci_device(struct pci_dev *pdev)
>> +{
>> + u32 value[256 / 4];
>> + int i;
>> +
>> + dev_info(&pdev->dev, "pci 0000:%02x:%02x.%d config space:\n",
>> + pdev->bus->number, PCI_SLOT(pdev->devfn),
>> + PCI_FUNC(pdev->devfn));
>
> Shouldn't be this changed to pci_info() ?
Yeah, I need to get used to pci_info().
>
>> +
>> + for (i = 0; i < 256; i += 4)
>> + pci_read_config_dword(pdev, i, &value[i / 4]);
>> +
>> + print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
>> + 256, false);
>> +}
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: gengdongjiu @ 2018-06-01 15:04 UTC (permalink / raw)
To: Marc Zyngier, rkrcmar@redhat.com, corbet@lwn.net,
christoffer.dall@arm.com, linux@armlinux.org.uk,
catalin.marinas@arm.com, will.deacon@arm.com, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, james.morse@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 13453 bytes --]
Hi Marc,
>
> On 31/05/18 14:08, Dongjiu Geng wrote:
> > For the migrating VMs, user space may need to know the exception
> > state. For example, in the machine A, KVM make an SError pending, when
> > migrate to B, KVM also needs to pend an SError.
> >
> > This new IOCTL exports user-invisible states related to SError.
> > Together with appropriate user space changes, user space can get/set
> > the SError exception state to do migrate/snapshot/suspend.
> >
> > Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> > --
> > this series patch is separated from
> > https://www.spinics.net/lists/kvm/msg168917.html
> > change since V12:
> > 1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 &
> > HCR_VSE) in kvm_arm_vcpu_get_events()
> >
> > Change since V11:
> > Address James's comments, thanks James 1. Align the struct of
> > kvm_vcpu_events to 64 bytes 2. Avoid exposing the stale ESR value in
> > the kvm_arm_vcpu_get_events() 3. Change variables 'injected' name to
> > 'serror_pending' in the kvm_arm_vcpu_set_events() 4. Change to
> > sizeof(events) from sizeof(struct kvm_vcpu_events) in
> > kvm_arch_vcpu_ioctl()
> >
> > Change since V10:
> > Address James's comments, thanks James 1. Merge the helper function
> > with the user.
> > 2. Move the ISS_MASK into pend_guest_serror() to clear top bits 3.
> > Make kvm_vcpu_events struct align to 4 bytes 4. Add something check in
> > the kvm_arm_vcpu_set_events() 5. Check kvm_arm_vcpu_get/set_events()'s
> > return value.
> > 6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
> > contain kernel stack.
> > ---
> > Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
> > arch/arm/include/asm/kvm_host.h | 6 ++++++
> > arch/arm/kvm/guest.c | 12 ++++++++++++
> > arch/arm64/include/asm/kvm_emulate.h | 5 +++++
> > arch/arm64/include/asm/kvm_host.h | 7 +++++++
> > arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
> > arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
> > arch/arm64/kvm/inject_fault.c | 7 ++++++-
> > arch/arm64/kvm/reset.c | 1 +
> > virt/kvm/arm/arm.c | 21 +++++++++++++++++++++
> > 10 files changed, 135 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/virtual/kvm/api.txt
> > b/Documentation/virtual/kvm/api.txt
> > index fdac969..8896737 100644
> > --- a/Documentation/virtual/kvm/api.txt
> > +++ b/Documentation/virtual/kvm/api.txt
> > @@ -835,11 +835,13 @@ struct kvm_clock_data {
> >
> > Capability: KVM_CAP_VCPU_EVENTS
> > Extended by: KVM_CAP_INTR_SHADOW
> > -Architectures: x86
> > +Architectures: x86, arm, arm64
> > Type: vm ioctl
> > Parameters: struct kvm_vcpu_event (out)
> > Returns: 0 on success, -1 on error
> >
> > +X86:
> > +
> > Gets currently pending exceptions, interrupts, and NMIs as well as
> > related states of the vcpu.
> >
> > @@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
> > - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
> > smi contains a valid state.
> >
> > +ARM, ARM64:
> > +
> > +Gets currently pending SError exceptions as well as related states of the vcpu.
> > +
> > +struct kvm_vcpu_events {
> > + struct {
> > + __u8 serror_pending;
> > + __u8 serror_has_esr;
> > + /* Align it to 8 bytes */
> > + __u8 pad[6];
> > + __u64 serror_esr;
> > + } exception;
> > + __u32 reserved[12];
> > +};
> > +
> > 4.32 KVM_SET_VCPU_EVENTS
> >
> > -Capability: KVM_CAP_VCPU_EVENTS
> > +Capebility: KVM_CAP_VCPU_EVENTS
> > Extended by: KVM_CAP_INTR_SHADOW
> > -Architectures: x86
> > +Architectures: x86, arm, arm64
> > Type: vm ioctl
> > Parameters: struct kvm_vcpu_event (in)
> > Returns: 0 on success, -1 on error
> >
> > +X86:
> > +
> > Set pending exceptions, interrupts, and NMIs as well as related
> > states of the vcpu.
> >
> > @@ -910,6 +929,12 @@ shall be written into the VCPU.
> >
> > KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
> >
> > +ARM, ARM64:
> > +
> > +Set pending SError exceptions as well as related states of the vcpu.
> > +
> > +See KVM_GET_VCPU_EVENTS for the data structure.
> > +
> >
> > 4.33 KVM_GET_DEBUGREGS
> >
> > diff --git a/arch/arm/include/asm/kvm_host.h
> > b/arch/arm/include/asm/kvm_host.h index c7c28c8..39f9901 100644
> > --- a/arch/arm/include/asm/kvm_host.h
> > +++ b/arch/arm/include/asm/kvm_host.h
> > @@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu
> > *vcpu); int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64
> > __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const
> > struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu,
> > const struct kvm_one_reg *reg);
> > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events);
> > +
> > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events);
> > +
> > unsigned long kvm_call_hyp(void *hypfn, ...); void
> > force_vm_exit(const cpumask_t *mask);
> >
> > diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c index
> > a18f33e..c685f0e 100644
> > --- a/arch/arm/kvm/guest.c
> > +++ b/arch/arm/kvm/guest.c
> > @@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> > return -EINVAL;
> > }
> >
> > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events)
> > +{
> > + return -EINVAL;
> > +}
> > +
> > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events)
> > +{
> > + return -EINVAL;
> > +}
> > +
> > int __attribute_const__ kvm_target_cpu(void) {
> > switch (read_cpuid_part()) {
> > diff --git a/arch/arm64/include/asm/kvm_emulate.h
> > b/arch/arm64/include/asm/kvm_emulate.h
> > index 1dab3a9..18f61ff 100644
> > --- a/arch/arm64/include/asm/kvm_emulate.h
> > +++ b/arch/arm64/include/asm/kvm_emulate.h
> > @@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
> > return (unsigned long *)&vcpu->arch.hcr_el2; }
> >
> > +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) {
> > + return vcpu->arch.vsesr_el2;
> > +}
> > +
> > static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
> > {
> > vcpu->arch.vsesr_el2 = vsesr;
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index 469de8a..357304a 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu
> > *vcpu); int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64
> > __user *indices); int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const
> > struct kvm_one_reg *reg); int kvm_arm_set_reg(struct kvm_vcpu *vcpu,
> > const struct kvm_one_reg *reg);
> > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events);
> > +
> > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events);
> >
> > #define KVM_ARCH_WANT_MMU_NOTIFIER
> > int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); @@ -363,6
> > +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run
> > *run, int kvm_perf_init(void); int kvm_perf_teardown(void);
> >
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> > +
> > struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long
> > mpidr);
> >
> > void __kvm_set_tpidr_el2(u64 tpidr_el2); diff --git
> > a/arch/arm64/include/uapi/asm/kvm.h
> > b/arch/arm64/include/uapi/asm/kvm.h
> > index 04b3256..df4faee 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -39,6 +39,7 @@
> > #define __KVM_HAVE_GUEST_DEBUG
> > #define __KVM_HAVE_IRQ_LINE
> > #define __KVM_HAVE_READONLY_MEM
> > +#define __KVM_HAVE_VCPU_EVENTS
> >
> > #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
> >
> > @@ -153,6 +154,18 @@ struct kvm_sync_regs { struct
> > kvm_arch_memory_slot { };
> >
> > +/* for KVM_GET/SET_VCPU_EVENTS */
> > +struct kvm_vcpu_events {
> > + struct {
> > + __u8 serror_pending;
> > + __u8 serror_has_esr;
> > + /* Align it to 8 bytes */
> > + __u8 pad[6];
> > + __u64 serror_esr;
> > + } exception;
> > + __u32 reserved[12];
> > +};
> > +
> > /* If you need to interpret the index values, here is the key: */
> > #define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> > #define KVM_REG_ARM_COPROC_SHIFT 16
> > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c index
> > 56a0260..71d3841 100644
> > --- a/arch/arm64/kvm/guest.c
> > +++ b/arch/arm64/kvm/guest.c
> > @@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> > return -EINVAL;
> > }
> >
> > +int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events)
> > +{
> > + events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
> > + events->exception.serror_has_esr =
> > + cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
> > + (!!vcpu_get_vsesr(vcpu));
>
> This is odd. Isn't VSESR==0 a valid value? And isn't serror_has_esr always true when ARM64_HAS_RAS_EXTN is set?
An all-zero SError ESR now means: 'RAS error: Uncategorized' instead of 'no valid ISS'. yes, I think the VSESR can be 0. Thanks for the pointing out. So it is better to write as shown blow:
events->exception.serror_has_esr = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
> > +
> > + if (events->exception.serror_pending &&
> > + events->exception.serror_has_esr)
> > + events->exception.serror_esr = vcpu_get_vsesr(vcpu);
> > + else
> > + events->exception.serror_esr = 0;
> > +
> > + return 0;
> > +}
> > +
> > +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> > + struct kvm_vcpu_events *events)
> > +{
> > + bool serror_pending = events->exception.serror_pending;
> > + bool has_esr = events->exception.serror_has_esr;
> > +
> > + if (serror_pending && has_esr) {
> > + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
> > + return -EINVAL;
> > +
> > + kvm_set_sei_esr(vcpu, events->exception.serror_esr);
> > +
>
> Spurious blank line
I will remove this blank line
>
> > + } else if (serror_pending) {
> > + kvm_inject_vabt(vcpu);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > int __attribute_const__ kvm_target_cpu(void) {
> > unsigned long implementor = read_cpuid_implementor(); diff --git
> > a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c index
> > d8e7165..9e0ca56 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
> > @@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
> >
> > static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr) {
> > - vcpu_set_vsesr(vcpu, esr);
> > + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
> > *vcpu_hcr(vcpu) |= HCR_VSE;
> > }
> >
> > @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu) {
> > pend_guest_serror(vcpu, ESR_ELx_ISV); }
> > +
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) {
> > + pend_guest_serror(vcpu, syndrome);
> > +}
>
> I think it'd make more sense to rename pend_guest_serror to kvm_set_sei_esr and be done with it.
Ok, got it.
>
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index
> > 38c8a64..20e919a 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
> > break;
> > case KVM_CAP_SET_GUEST_DEBUG:
> > case KVM_CAP_VCPU_ATTRIBUTES:
> > + case KVM_CAP_VCPU_EVENTS:
> > r = 1;
> > break;
> > default:
> > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c index
> > a4c1b76..8b43968 100644
> > --- a/virt/kvm/arm/arm.c
> > +++ b/virt/kvm/arm/arm.c
> > @@ -1107,6 +1107,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
> > r = kvm_arm_vcpu_has_attr(vcpu, &attr);
> > break;
> > }
> > + case KVM_GET_VCPU_EVENTS: {
> > + struct kvm_vcpu_events events;
> > +
> > + memset(&events, 0, sizeof(events));
>
> You could write this as
>
> struct kvm_cpu_events events = { };
>
> but it'd make more sense if kvm_arm_vcpu_get_events() did all the work rather than having this split responsibility.
Ok, thanks for the good suggestion.
>
> > + if (kvm_arm_vcpu_get_events(vcpu, &events))
> > + return -EINVAL;
> > +
> > + if (copy_to_user(argp, &events, sizeof(events)))
> > + return -EFAULT;
> > +
> > + return 0;
> > + }
> > + case KVM_SET_VCPU_EVENTS: {
> > + struct kvm_vcpu_events events;
> > +
> > + if (copy_from_user(&events, argp,
> > + sizeof(struct kvm_vcpu_events)))
>
> Prefer using sizeof(events) instead.
Yes, it should, It is my careless. Thanks for the pointing out.
>
> > + return -EFAULT;
> > +
> > + return kvm_arm_vcpu_set_events(vcpu, &events);
> > + }
> > default:
> > r = -EINVAL;
> > }
> >
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±v‡"žØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢ø\x1e®G«éh®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš
^ permalink raw reply
* Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Andy Shevchenko @ 2018-06-01 15:02 UTC (permalink / raw)
To: Sinan Kaya
Cc: linux-pci, Timur Tabi, linux-arm-msm, linux-arm Mailing List,
Jonathan Corbet, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Christoffer Dall, Paul E. McKenney, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, David Rientjes, Kate Stewart,
Philippe Ombredanne, Tom Lendacky, Juergen Gross, Borislav Petkov,
Mikulas Patocka, Petr Tesarik, Andy Lutomirski, Dou Liyang,
Ram Pai, Boris Ostrovsky, open list:DOCUMENTATION, open list
In-Reply-To: <1527654876-26716-1-git-send-email-okaya@codeaurora.org>
On Wed, May 30, 2018 at 7:34 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Move early dump functionality into common code so that it is available for
> all archtiectures. No need to carry arch specific reads around as the read
> hooks are already initialized by the time pci_setup_device() is getting
> called during scan.
> /* If set, the PCIe ATS capability will not be used. */
> static bool pcie_ats_disabled;
>
> +bool pci_early_dump;
> +
I didn't check above these, but maybe a good idea to add one line
comment what is this about?
> extern const unsigned char pcie_link_speed[];
> -
> +extern bool pci_early_dump;
> bool pcie_cap_has_lnkctl(const struct pci_dev *dev);
>
Hmm... I would rather not attach this line to some function declarations.
> +static void early_dump_pci_device(struct pci_dev *pdev)
> +{
> + u32 value[256 / 4];
> + int i;
> +
> + dev_info(&pdev->dev, "pci 0000:%02x:%02x.%d config space:\n",
> + pdev->bus->number, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn));
Shouldn't be this changed to pci_info() ?
> +
> + for (i = 0; i < 256; i += 4)
> + pci_read_config_dword(pdev, i, &value[i / 4]);
> +
> + print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1, value,
> + 256, false);
> +}
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] PCI: move early dump functionality from x86 arch into the common code
From: Sinan Kaya @ 2018-06-01 14:45 UTC (permalink / raw)
To: linux-pci, timur
Cc: linux-arm-msm, linux-arm-kernel, Jonathan Corbet, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Bjorn Helgaas,
Christoffer Dall, Paul E. McKenney, Marc Zyngier, Kai-Heng Feng,
Thymo van Beers, Frederic Weisbecker, Konrad Rzeszutek Wilk,
Greg Kroah-Hartman, David Rientjes, Kate Stewart,
Philippe Ombredanne, Tom Lendacky, Juergen Gross, Borislav Petkov,
Mikulas Patocka, Petr Tesarik, Andy Lutomirski, Dou Liyang,
Ram Pai, Boris Ostrovsky, open list:DOCUMENTATION, open list
In-Reply-To: <1527654876-26716-1-git-send-email-okaya@codeaurora.org>
On 5/30/2018 12:34 AM, Sinan Kaya wrote:
> Move early dump functionality into common code so that it is available for
> all archtiectures. No need to carry arch specific reads around as the read
> hooks are already initialized by the time pci_setup_device() is getting
> called during scan.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 +-
> arch/x86/include/asm/pci-direct.h | 5 ---
> arch/x86/kernel/setup.c | 5 ---
> arch/x86/pci/common.c | 4 --
> arch/x86/pci/early.c | 50 -------------------------
> drivers/pci/pci.c | 4 ++
> drivers/pci/pci.h | 2 +-
> drivers/pci/probe.c | 19 ++++++++++
> 8 files changed, 25 insertions(+), 66 deletions(-)
Any feedback on the direction?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox