Re: [PATCH v1] x86: Pin cr4 FSGSBASE
On Mon, May 25, 2020 at 10:28:48PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> Since there seem to be kernel modules floating around that set
> FSGSBASE incorrectly, prevent this in the CR4 pinning. Currently
> CR4 pinning just checks that bits are set, this also checks
> that the FSGSBASE bit is not set, and if it is clears it again.
So we are trying to "protect" ourselves from broken out-of-tree kernel
modules now? Why stop with this type of check, why not just forbid them
entirely if we don't trust them? :)
> Note this patch will need to be undone when the full FSGSBASE
> patches are merged. But it's a reasonable solution for v5.2+
> stable at least. Sadly the older kernels don't have the necessary
> infrastructure for this (although a simpler version of this
> could be added there too)
>
> Cc: sta...@vger.kernel.org # v5.2+
> Signed-off-by: Andi Kleen
> ---
> arch/x86/kernel/cpu/common.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index bed0cb83fe24..1f5b7871ae9a 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -385,6 +385,11 @@ void native_write_cr4(unsigned long val)
> /* Warn after we've set the missing bits. */
> WARN_ONCE(bits_missing, "CR4 bits went missing: %lx!?\n",
> bits_missing);
> + if (val & X86_CR4_FSGSBASE) {
> + WARN_ONCE(1, "CR4 unexpectedly set FSGSBASE!?\n");
Like this will actually be noticed by anyone who calls this? What is a
user supposed to do about this?
What about those systems that panic-on-warn?
> + val &= ~X86_CR4_FSGSBASE;
So you just prevented them from setting this, thereby fixing up their
broken code that will never be fixed because you did this? Why do this?
thanks,
greg k-h
RE: [PATCH] Input: elantech - Remove read/write registers in attr.
HI Dmitry: These changes would not affect all the behavior of the old IC, including all the TP functions THANKS JINGLE -Original Message- From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: Tuesday, May 26, 2020 12:17 PM To: Jingle.Wu Cc: linux-kernel@vger.kernel.org; linux-in...@vger.kernel.org; phoe...@emc.com.tw; dave.w...@emc.com.tw; josh.c...@emc.com.tw Subject: Re: [PATCH] Input: elantech - Remove read/write registers in attr. Hi Jingle, On Tue, May 26, 2020 at 10:22:46AM +0800, Jingle.Wu wrote: > New Elan IC would not be accessed with the specific regiters. What about older Elaan parts? We can't simply drop compatibility with older chips in newer kernels. Thanks. -- Dmitry
Re: [PATCH v3 16/18] nitro_enclaves: Add sample for ioctl interface usage
On Tue, May 26, 2020 at 01:13:32AM +0300, Andra Paraschiv wrote: > Signed-off-by: Alexandru Vasile > Signed-off-by: Andra Paraschiv Again, I can't take patches without any changelog text, and you shouldn't be writing them, as they are just lazy :) thanks, greg k-h
Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Tue, May 26, 2020 at 01:13:23AM +0300, Andra Paraschiv wrote: > +#define NE "nitro_enclaves: " Again, no need for this. > +#define NE_DEV_NAME "nitro_enclaves" KBUILD_MODNAME? > +#define NE_IMAGE_LOAD_OFFSET (8 * 1024UL * 1024UL) > + > +static char *ne_cpus; > +module_param(ne_cpus, charp, 0644); > +MODULE_PARM_DESC(ne_cpus, " - CPU pool used for Nitro Enclaves"); Again, please do not do this. Can you get the other amazon.com developers on the cc: list to review this before you send it out again? I feel like I am doing basic review of things that should be easily caught by them before you ask the community to review your code. And get them to sign off on it too, showing they agree with the design decisions here :) thanks, greg k-h
Re: [PATCH v4 2/3] dmaengine: ptdma: register PTDMA controller as a DMA resource
On 5/4/2020 11:44 AM, Vinod Koul wrote:
> [CAUTION: External Email]
>
> On 28-04-20, 16:13, Sanjay R Mehta wrote:
>
>> +static void pt_do_cmd_complete(unsigned long data)
>> +{
>> + struct pt_tasklet_data *tdata = (struct pt_tasklet_data *)data;
>> + struct pt_cmd *cmd = tdata->cmd;
>> + struct pt_cmd_queue *cmd_q = &cmd->pt->cmd_q;
>> + u32 tail;
>> +
>> + tail = lower_32_bits(cmd_q->qdma_tail + cmd_q->qidx * Q_DESC_SIZE);
>> + if (cmd_q->cmd_error) {
>> +/*
>> + * Log the error and flush the queue by
>> + * moving the head pointer
>> + */
>> + pt_log_error(cmd_q->pt, cmd_q->cmd_error);
>> + iowrite32(tail, cmd_q->reg_head_lo);
>> + }
>> +
>> + cmd->pt_cmd_callback(cmd->data, cmd->ret);
>
> So in the isr you schedule this tasklet and this invokes the calback..
> this is very inefficient.
>
> You should submit the next txn to dmaengine in your isr, keeping the dma
> idle at this point is very inefficient.
>
Sure, will incorporate the changes in the next version of patch.
>> +static void pt_cmd_callback(void *data, int err)
>> +{
>> + struct pt_dma_desc *desc = data;
>> + struct pt_dma_chan *chan;
>> + int ret;
>
> This is called as callback from pt layer..
Right.
>> +
>> + if (err == -EINPROGRESS)
>> + return;
>> +
>> + chan = container_of(desc->vd.tx.chan, struct pt_dma_chan,
>> + vc.chan);
>> +
>> + dev_dbg(chan->pt->dev, "%s - tx %d callback, err=%d\n",
>> + __func__, desc->vd.tx.cookie, err);
>> +
>> + if (err)
>> + desc->status = DMA_ERROR;
>> +
>> + while (true) {
>> + /* Check for DMA descriptor completion */
>> + desc = pt_handle_active_desc(chan, desc);
>> +
>> + /* Don't submit cmd if no descriptor or DMA is paused */
>> + if (!desc || chan->status == DMA_PAUSED)
>> + break;
>> +
>> + ret = pt_issue_next_cmd(desc);
>
> And you call this to issue next cmd... The missing thing I am seeing
> here is vchan_cookie_complete() you need to call that here for correct
> vchan list mgmt
>
Here before making call to issue next cmd, "vchan_vdesc_fini()" is been used in
place of
vchan_cookie_complete() in the pt_handle_active_desc() function.
>> +static struct pt_dma_desc *pt_create_desc(struct dma_chan *dma_chan,
>> + struct scatterlist *dst_sg,
>> + unsigned int dst_nents,
>> + struct scatterlist *src_sg,
>> + unsigned int src_nents,
>> + unsigned long flags)
>
> unaligned add indentation! Pls run checkpatch --strict to check for
> these oddities
>
Sure, will incorporate the changes in the next version of patch.
>> + dma_dev->dev = pt->dev;
>> + dma_dev->src_addr_widths = PT_DMA_WIDTH(dma_get_mask(pt->dev));
>> + dma_dev->dst_addr_widths = PT_DMA_WIDTH(dma_get_mask(pt->dev));
>> + dma_dev->directions = DMA_MEM_TO_MEM;
>> + dma_dev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
>> + dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
>> + dma_cap_set(DMA_INTERRUPT, dma_dev->cap_mask);
>> + dma_cap_set(DMA_PRIVATE, dma_dev->cap_mask);
>> +
>> + INIT_LIST_HEAD(&dma_dev->channels);
>> +
>> + chan = pt->pt_dma_chan;
>> + chan->pt = pt;
>> + dma_chan = &chan->vc.chan;
>> +
>> + dma_dev->device_free_chan_resources = pt_free_chan_resources;
>> + dma_dev->device_prep_dma_memcpy = pt_prep_dma_memcpy;
>> + dma_dev->device_prep_dma_interrupt = pt_prep_dma_interrupt;
>> + dma_dev->device_issue_pending = pt_issue_pending;
>> + dma_dev->device_tx_status = pt_tx_status;
>> + dma_dev->device_pause = pt_pause;
>> + dma_dev->device_resume = pt_resume;
>> + dma_dev->device_terminate_all = pt_terminate_all;
>
> Pls implement .device_synchronize as well
>
Sure, will incorporate the changes in the next version of patch.
>> +struct pt_dma_desc {
>> + struct virt_dma_desc vd;
>> +
>> + struct pt_device *pt;
>> +
>> + struct list_head pending;
>> + struct list_head active;
>
> why not use vc->desc_submitted, desc_issued instead!
>
Sure, will incorporate the changes in the next version of patch.
>> +
>> + enum dma_status status;
>> +
>> + size_t len;
>> +};
>> +
>> +struct pt_dma_chan {
>> + struct virt_dma_chan vc;
>> +
>> + struct pt_device *pt;
>> +
>> + enum dma_status status;
>
> channel status as well as desc, why do you need both?
You are right. will remove channel status from here.
> --
> ~Vinod
>
Re: [PATCH v3 04/18] nitro_enclaves: Init PCI device driver
On Tue, May 26, 2020 at 01:13:20AM +0300, Andra Paraschiv wrote: > The Nitro Enclaves PCI device is used by the kernel driver as a means of > communication with the hypervisor on the host where the primary VM and > the enclaves run. It handles requests with regard to enclave lifetime. > > Setup the PCI device driver and add support for MSI-X interrupts. > > Signed-off-by: Alexandru-Catalin Vasile > Signed-off-by: Alexandru Ciobotaru > Signed-off-by: Andra Paraschiv > --- > Changelog > > v2 -> v3 > > * Remove the GPL additional wording as SPDX-License-Identifier is already in > place. > * Remove the WARN_ON calls. > * Remove linux/bug include that is not needed. > * Update static calls sanity checks. > * Remove "ratelimited" from the logs that are not in the ioctl call paths. > * Update kzfree() calls to kfree(). > > v1 -> v2 > > * Add log pattern for NE. > * Update PCI device setup functions to receive PCI device data structure and > then get private data from it inside the functions logic. > * Remove the BUG_ON calls. > * Add teardown function for MSI-X setup. > * Update goto labels to match their purpose. > * Implement TODO for NE PCI device disable state check. > * Update function name for NE PCI device probe / remove. > --- > drivers/virt/nitro_enclaves/ne_pci_dev.c | 252 +++ > 1 file changed, 252 insertions(+) > create mode 100644 drivers/virt/nitro_enclaves/ne_pci_dev.c > > diff --git a/drivers/virt/nitro_enclaves/ne_pci_dev.c > b/drivers/virt/nitro_enclaves/ne_pci_dev.c > new file mode 100644 > index ..0b66166787b6 > --- /dev/null > +++ b/drivers/virt/nitro_enclaves/ne_pci_dev.c > @@ -0,0 +1,252 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2020 Amazon.com, Inc. or its affiliates. All Rights Reserved. > + */ > + > +/* Nitro Enclaves (NE) PCI device driver. */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "ne_misc_dev.h" > +#include "ne_pci_dev.h" > + > +#define DEFAULT_TIMEOUT_MSECS (12) /* 120 sec */ > + > +#define NE "nitro_enclaves: " Why is this needed? The dev_* functions should give you all the information that you need to properly describe the driver and device in question. No extra "prefixes" should be needed at all. thanks, greg k-h
Re: [PATCH v3 03/18] nitro_enclaves: Define enclave info for internal bookkeeping
On Tue, May 26, 2020 at 01:13:19AM +0300, Andra Paraschiv wrote: > +/* Nitro Enclaves (NE) misc device */ > +extern struct miscdevice ne_miscdevice; Why does your misc device need to be in a .h file? Having the patch series like this (add random .h files, and then start to use them), is hard to review. Would you want to try to review a series written in this way? thanks, greg k-h
Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface
On Tue, May 26, 2020 at 01:13:18AM +0300, Andra Paraschiv wrote:
> +struct enclave_get_slot_req {
> + /* Context ID (CID) for the enclave vsock device. */
> + u64 enclave_cid;
> +} __attribute__ ((__packed__));
Can you really "pack" a single member structure?
Anyway, we have better ways to specify this instead of the "raw"
__attribute__ option. But first see if you really need any of these, at
first glance, I do not think you do at all, and they can all be removed.
thanks,
greg k-h
[PATCH] doc: filesystems: format tables in locking properly
Commit 28df3d1539de ("nfsd: clients don't need to break their own
delegations") introduced lm_breaker_owns_lease and documented that in the
according table. Commit 43dbd0e7e62b ("mmap locking API: convert mmap_sem
comments") renamed mmap_sem to mmap_lock in another table. Both changes
created a table entry longer than the content before, but did not adjust
the tables. Hence, make htmldocs warns about malformed tables.
Adjust the tables to address the warning.
Signed-off-by: Lukas Bulwahn
---
Michel, Vlastimil, please ack this patch.
Andrew, please pick this minor doc fix patch into your -next tree, where
patch "mmap locking API: convert mmap_sem comments" has been applied.
Documentation/filesystems/locking.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/filesystems/locking.rst
b/Documentation/filesystems/locking.rst
index 318605de83f3..faf7f4abd54d 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -433,15 +433,15 @@ prototypes::
locking rules:
-== = = =
-opsinode->i_lock blocked_lock_lock may block
-== = = =
-lm_notify: yes yes no
-lm_grant: no no no
-lm_break: yes no no
-lm_change yes no no
-lm_breaker_owns_lease: no no no
-== = = =
+== = =
=
+opsinode->i_lock blocked_lock_lock may
block
+== = =
=
+lm_notify: yes yes no
+lm_grant: no no no
+lm_break: yes no no
+lm_change yes no no
+lm_breaker_owns_lease: no no no
+== = =
=
buffer_head
===
@@ -616,9 +616,9 @@ prototypes::
locking rules:
-= ===
+= = ===
opsmmap_lock PageLocked(page)
-= ===
+= = ===
open: yes
close: yes
fault: yes can return with page locked
@@ -626,7 +626,7 @@ map_pages: yes
page_mkwrite: yes can return with page locked
pfn_mkwrite: yes
access:yes
-= ===
+= = ===
->fault() is called when a previously not present pte is about
to be faulted in. The filesystem must find and return the page associated
--
2.17.1
Re: [PATCH v2 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Mon, May 25, 2020 at 11:49:50PM +0300, Paraschiv, Andra-Irina wrote: > > > On 22/05/2020 10:07, Greg KH wrote: > > On Fri, May 22, 2020 at 09:29:35AM +0300, Andra Paraschiv wrote: > > > +static char *ne_cpus; > > > +module_param(ne_cpus, charp, 0644); > > > +MODULE_PARM_DESC(ne_cpus, " - CPU pool used for Nitro > > > Enclaves"); > > This is not the 1990's, don't use module parameters if you can help it. > > Why is this needed, and where is it documented? > > This is a CPU pool that can be set by the root user and that includes CPUs > set aside to be used for the enclave(s) setup; these CPUs are offlined. From > this CPU pool, the kernel logic chooses the CPUs that are set for the > created enclave(s). > > The cpu-list format is matching the same that is documented here: > > https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html > > I've also thought of having a sysfs entry for the setup of this enclave CPU > pool. Ok, but again, do not use a module parameter, they are hard to use, tough to document, and global. All things we moved away from a long time ago. Please use something else for this (sysfs, configfs, etc.) instead. thanks, greg k-h
Re: [PATCH v2 16/18] nitro_enclaves: Add sample for ioctl interface usage
On Mon, May 25, 2020 at 11:57:26PM +0300, Paraschiv, Andra-Irina wrote: > > > On 22/05/2020 10:08, Greg KH wrote: > > On Fri, May 22, 2020 at 09:29:44AM +0300, Andra Paraschiv wrote: > > > Signed-off-by: Alexandru Vasile > > > Signed-off-by: Andra Paraschiv > > I know I don't take commits with no changelog text :( > > Included in v3 the changelog for each patch in the series, in addition to > the one in the cover letter; where no changes, I just mentioned that. :) But you didn't cc: me on that version :(
Re: [PATCH v3 1/6] arm64: Detect the ARMv8.4 TTL feature
Hi Anshuman, On 2020/5/26 10:39, Anshuman Khandual wrote: > This patch (https://patchwork.kernel.org/patch/11557359/) is adding some > more ID_AA64MMFR2 features including the TTL. I am going to respin parts > of the V4 series patches along with the above mentioned patch. So please > rebase this series accordingly, probably on latest next. > I noticed that some patches of your series have been merged into arm64 tree (for-next/cpufeature), such as TLB range, but this one not. Why? BTW, this patch is provided by Marc in his NV series [1], maybe you should also let him know. I will rebase my series after your patch is merged. [1] https://lore.kernel.org/linux-arm-kernel/d6032191-ba0e-82a4-4dde-11beef369...@arm.com/ Thanks, Zhenyu
Re: [RFC 07/16] KVM: mm: Introduce VM_KVM_PROTECTED
On 2020-05-22 05:52, Kirill A. Shutemov wrote: ... @@ -2773,6 +2780,7 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address, #define FOLL_LONGTERM 0x1 /* mapping lifetime is indefinite: see below */ #define FOLL_SPLIT_PMD0x2 /* split huge pmd before returning */ #define FOLL_PIN 0x4 /* pages must be released via unpin_user_page */ +#define FOLL_KVM 0x8 /* access to VM_KVM_PROTECTED VMAs */ I grabbed 0x8 already, for FOLL_FAST_ONLY. :) thanks, -- John Hubbard NVIDIA
Re: [PATCH v4 1/3] dmaengine: ptdma: Initial driver for the AMD PTDMA controller
On 5/26/2020 11:59 AM, Greg KH wrote:
> [CAUTION: External Email]
>
> On Tue, May 26, 2020 at 11:35:02AM +0530, Sanjay R Mehta wrote:
>> Apologies for my delayed response.
>>
+#include
+#include
+#include
+#include
+#include
+
+#include "ptdma.h"
+
+static int cmd_queue_length = 32;
+module_param(cmd_queue_length, uint, 0644);
+MODULE_PARM_DESC(cmd_queue_length,
+ " length of the command queue, a power of 2 (2 <= val <=
128)");
>>>
>>> Any reason for this as module param? who will configure this and how?
>>>
>> The command queue length can be from 2 to 64K command.
>> Therefore added as module parameter to allow the length of the queue to be
>> specified at load time.
>
> Please no, this is not the 1990's. No one can use them easily, make
> this configurable on a per-device basis if you really need to be able to
> change this.
>
> But step back, why do you need to change this at all? Why do you have a
> limit and why can you not just do this dynamically? The goal here
> should not have any user-changable options at all, it should "just
> work".
>
Sure Greg, will remove this.
+ * List of PTDMAs, PTDMA count, read-write access lock, and access
functions
+ *
+ * Lock structure: get pt_unit_lock for reading whenever we need to
+ * examine the PTDMA list. While holding it for reading we can acquire
+ * the RR lock to update the round-robin next-PTDMA pointer. The unit lock
+ * must be acquired before the RR lock.
+ *
+ * If the unit-lock is acquired for writing, we have total control over
+ * the list, so there's no value in getting the RR lock.
+ */
+static DEFINE_RWLOCK(pt_unit_lock);
+static LIST_HEAD(pt_units);
+
+static struct pt_device *pt_rr;
>>>
>>> why do we need these globals and not in driver context?
>>>
>> The AMD SOC has multiple PT controller's with the same PCI device ID and
>> hence the same driver is probed for each instance.
>> The driver stores the pt_device context of each PT controller in this global
>> list.
>
> That's horrid and not needed at all. No driver should have a static
> list anymore, again, this isn't the 1990's :)
>
Sure, will remove this :).
+static void pt_add_device(struct pt_device *pt)
+{
+ unsigned long flags;
+
+ write_lock_irqsave(&pt_unit_lock, flags);
+ list_add_tail(&pt->entry, &pt_units);
+ if (!pt_rr)
+ /*
+ * We already have the list lock (we're first) so this
+ * pointer can't change on us. Set its initial value.
+ */
+ pt_rr = pt;
+ write_unlock_irqrestore(&pt_unit_lock, flags);
+}
>>>
>>> Can you please explain what do you mean by having a list of devices and
>>> why are we adding/removing dynamically?
>>>
>> Since AMD SOC has many PT controller's with the same PCI device ID and
>> hence the same driver probed for initialization of each PT controller device
>> instance.
>
> That's fine, PCI drivers should all work on a per-device basis and not
> care if there are 1, or 1000 of the same device in the system.
>
>> Also, the number of PT controller varies for different AMD SOC's.
>
> Again, that's fine.
>
>> Therefore the dynamic adding/removing of each PT controller context to
>> global device list implemented.
>
> Such a list should never be needed, unless you are doing something
> really wrong. Please remove it and use the proper PCI device driver
> apis for your individual instances instead.
>
Sure, will incorporate the changes in the next version of patch set.
> thanks,
>
> greg k-h
>
Re: [RFC PATCH 0/3] METADATA design using V4l2 Request API
Hi, A gentle reminder for the review. On 2020-05-08 11:51, Dikshita Agarwal wrote: There are many commercialized video use cases which needs metadata info to be circulated between v4l2 client and v4l2 driver. METADATA has following requirements associated: •Metadata is an optional info available for a buffer. It is not mandatorily for every buffer. For ex. consider metadata ROI (Region Of Interest). ROI is specified by clients to indicate the region where enhanced quality is desired. This metadata is given as an input information to encoder output plane. Client may or may not specify the ROI for a frame during encode as an input metadata. Also if the client has not provided ROI metadata for a given frame, it would be incorrect to take the metadata from previous frame. If the data and metadata is asynchronous, it would be difficult for hardware to decide if it needs to wait for metadata buffer or not before processing the input frame for encoding. •Synchronize the buffer requirement across both the video node/session (incase metadata is being processed as a separate v4l2 video node/session). This is to avoid buffer starvation. •Associate the metadata buffer with the data buffer without adding any pipeline delay in waiting for each other. This is applicable both at the hardware side (the processing end) and client side (the receiving end). •Low latency usecases like WFD/split rendering/game streaming/IMS have sub-50ms e2e latency requirements, and it is not practical to stall the pipeline due to inherent framework latencies. High performance usecase like high-frame rate playback/record can lead to frame loss during any pipeline latency. To address all above requirements, we used v4l2 Request API as interlace. As an experiment, We have introduced new control V4L2_CID_MPEG_VIDEO_VENUS_METADATA to contain the METADATA info. Exact controls can be finalized once the interface is discussed. For setting metadata from userspace to kernel, let say on encode output plane, following code sequence was followed 1. Video driver is registering for media device and creating a media node in /dev 2. Request fd is allocated by calling MEDIA_IOC_REQUEST_ALLOC IOCTL on media fd. 3. METADATA configuration is being applied on request fd using VIDIOC_S_EXT_CTRLS IOCTL and the same request fd is added to buf structure structure before calling VIDIOC_QBUF on video fd. 4. The same request is queued through MEDIA_REQUEST_IOC_QUEUE IOCTL to driver then, as a result to which METADATA control will be applied to buffer through S_CTRL. 5. Once control is applied and request is completed, MEDIA_REQUEST_IOC_REINIT IOCTL is called to re-initialize the request. We could achieve the same on capture plane as well by removing few checks present currently in v4l2 core which restrict the implementation to only output plane. We profiled below data with this implementation : 1. Total time taken ( round trip ) for setting up control data on video driver with VIDIOC_S_EXT_CTRLS, QBUF and Queue Request: 737us 2. Time taken for first QBUF on Output plane to reach driver with REQUEST API enabled (One way): 723us 3. Time taken for first QBUF on Output plane to reach driver without REQUEST API (One way) : 250us 4. Time taken by each IOCTL to complete ( round trip ) with REQUEST API enabled : a. VIDIOC_S_EXT_CTRLS : 201us b. VIDIOC_QBUF : 92us c. MEDIA_REQUEST_IOC_QUEUE: 386us Kindly share your feedback/comments on the design/call sequence. Also as we experimented and enabled the metadata on capture plane as well, please comment if any issue in allowing the metadata exchange on capture plane as well. Reference for client side implementation can be found at [1]. Thanks, Dikshita [1] https://git.linaro.org/people/stanimir.varbanov/v4l2-encode.git/log/?h=dikshita/request-api Dikshita Agarwal (3): Register for media device - Initialize and register for media device - define venus_m2m_media_ops - Implement APIs to register/unregister media controller. Enable Request API for output buffers - Add dependency on MEDIA_CONTROLLER_REQUEST_API in Kconfig. - Initialize vb2 ops buf_out_validate and buf_request_complete. - Add support for custom Metadata control V4L2_CID_MPEG_VIDEO_VENUS_METADATA - Implemeted/Integrated APIs for Request setup/complete. Enable Request API for Capture Buffers drivers/media/common/videobuf2/videobuf2-v4l2.c | 4 +- drivers/media/platform/Kconfig | 2 +- drivers/media/platform/qcom/venus/core.h| 36 drivers/media/platform/qcom/venus/helpers.c | 247 +++- drivers/media/platform/qcom/venus/helpers.h | 15 ++ drivers/media/platform/qcom/venus/venc.c| 63 +- drivers/media/platform/qcom/venus/venc_ctrls.c | 61 +- drivers/media/v4l2-core/v4l2-ctrls.c| 10 + drivers/media/v4l2-core/v4l2-mem2mem.c | 17 +- include/media/v4l2-ctrls.h
Re: [PATCH v4 1/3] dmaengine: ptdma: Initial driver for the AMD PTDMA controller
On Tue, May 26, 2020 at 11:35:02AM +0530, Sanjay R Mehta wrote:
> Apologies for my delayed response.
>
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "ptdma.h"
> >> +
> >> +static int cmd_queue_length = 32;
> >> +module_param(cmd_queue_length, uint, 0644);
> >> +MODULE_PARM_DESC(cmd_queue_length,
> >> + " length of the command queue, a power of 2 (2 <= val <=
> >> 128)");
> >
> > Any reason for this as module param? who will configure this and how?
> >
> The command queue length can be from 2 to 64K command.
> Therefore added as module parameter to allow the length of the queue to be
> specified at load time.
Please no, this is not the 1990's. No one can use them easily, make
this configurable on a per-device basis if you really need to be able to
change this.
But step back, why do you need to change this at all? Why do you have a
limit and why can you not just do this dynamically? The goal here
should not have any user-changable options at all, it should "just
work".
> >> + * List of PTDMAs, PTDMA count, read-write access lock, and access
> >> functions
> >> + *
> >> + * Lock structure: get pt_unit_lock for reading whenever we need to
> >> + * examine the PTDMA list. While holding it for reading we can acquire
> >> + * the RR lock to update the round-robin next-PTDMA pointer. The unit lock
> >> + * must be acquired before the RR lock.
> >> + *
> >> + * If the unit-lock is acquired for writing, we have total control over
> >> + * the list, so there's no value in getting the RR lock.
> >> + */
> >> +static DEFINE_RWLOCK(pt_unit_lock);
> >> +static LIST_HEAD(pt_units);
> >> +
> >> +static struct pt_device *pt_rr;
> >
> > why do we need these globals and not in driver context?
> >
> The AMD SOC has multiple PT controller's with the same PCI device ID and
> hence the same driver is probed for each instance.
> The driver stores the pt_device context of each PT controller in this global
> list.
That's horrid and not needed at all. No driver should have a static
list anymore, again, this isn't the 1990's :)
> >> +static void pt_add_device(struct pt_device *pt)
> >> +{
> >> + unsigned long flags;
> >> +
> >> + write_lock_irqsave(&pt_unit_lock, flags);
> >> + list_add_tail(&pt->entry, &pt_units);
> >> + if (!pt_rr)
> >> + /*
> >> + * We already have the list lock (we're first) so this
> >> + * pointer can't change on us. Set its initial value.
> >> + */
> >> + pt_rr = pt;
> >> + write_unlock_irqrestore(&pt_unit_lock, flags);
> >> +}
> >
> > Can you please explain what do you mean by having a list of devices and
> > why are we adding/removing dynamically?
> >
> Since AMD SOC has many PT controller's with the same PCI device ID and
> hence the same driver probed for initialization of each PT controller device
> instance.
That's fine, PCI drivers should all work on a per-device basis and not
care if there are 1, or 1000 of the same device in the system.
> Also, the number of PT controller varies for different AMD SOC's.
Again, that's fine.
> Therefore the dynamic adding/removing of each PT controller context to global
> device list implemented.
Such a list should never be needed, unless you are doing something
really wrong. Please remove it and use the proper PCI device driver
apis for your individual instances instead.
thanks,
greg k-h
[PATCH] ALSA: usb: mixer: volume quirk for ESS Technology Asus USB DAC
The Asus USB DAC is a USB type-C audio dongle for connecting to
the headset and headphone. The volume minimum value -23040 which
is 0xa600 in hexadecimal with the resolution value 1 indicates
this should be endianness issue caused by the firmware bug. Add
a volume quirk to fix the volume control problem.
Also fixes this warning:
Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
[5] FU [Headset Capture Volume] ch = 1, val = -23040/0/1
Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
[7] FU [Headset Playback Volume] ch = 1, val = -23040/0/1
Signed-off-by: Chris Chiu
---
sound/usb/mixer.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 81b2db0edd5f..0b568a9fdab3 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1171,6 +1171,14 @@ static void volume_control_quirks(struct
usb_mixer_elem_info *cval,
cval->res = 384;
}
break;
+ case USB_ID(0x0495, 0x3042): /* ESS Technology Asus USB DAC */
+ if ((strstr(kctl->id.name, "Playback Volume") != NULL) ||
+ strstr(kctl->id.name, "Capture Volume") != NULL) {
+ cval->min >>= 8;
+ cval->max = 0;
+ cval->res = 1;
+ }
+ break;
}
}
--
2.20.1
RE: [PATCH] scsi: ufs-qcom: Fix scheduling while atomic issue
> ufs_qcom_dump_dbg_regs() uses usleep_range, a sleeping function, but can
> be called from atomic context in the following flow:
>
> ufshcd_intr -> ufshcd_sl_intr -> ufshcd_check_errors ->
> ufshcd_print_host_regs -> ufshcd_vops_dbg_register_dump ->
> ufs_qcom_dump_dbg_regs
>
> This causes a boot crash on the Lenovo Miix 630 when the interrupt is
> handled on the idle thread.
>
> Fix the issue by switching to udelay().
>
> Fixes: 9c46b8676271 ("scsi: ufs-qcom: dump additional testbus registers")
> Signed-off-by: Jeffrey Hugo
Reviewed-by: Avri Altman
[PATCH 2/2] KVM: SVM: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Paolo Bonzini
Cc: Sean Christopherson
Cc: Vitaly Kuznetsov
Cc: Wanpeng Li
Cc: Jim Mattson
Cc: Joerg Roedel
Cc: H. Peter Anvin
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: John Hubbard
---
arch/x86/kvm/svm/sev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 9693db1af57c..a83f2e73bcbb 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -349,7 +349,7 @@ static struct page **sev_pin_memory(struct kvm *kvm,
unsigned long uaddr,
return NULL;
/* Pin the user virtual address. */
- npinned = get_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0,
pages);
+ npinned = pin_user_pages_fast(uaddr, npages, write ? FOLL_WRITE : 0,
pages);
if (npinned != npages) {
pr_err("SEV: Failure locking %lu pages.\n", npages);
goto err;
@@ -362,7 +362,7 @@ static struct page **sev_pin_memory(struct kvm *kvm,
unsigned long uaddr,
err:
if (npinned > 0)
- release_pages(pages, npinned);
+ unpin_user_pages(pages, npinned);
kvfree(pages);
return NULL;
@@ -373,7 +373,7 @@ static void sev_unpin_memory(struct kvm *kvm, struct page
**pages,
{
struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
- release_pages(pages, npages);
+ unpin_user_pages(pages, npages);
kvfree(pages);
sev->pages_locked -= npages;
}
--
2.26.2
[PATCH 0/2] KVM: SVM: convert get_user_pages() --> pin_user_pages(), bug fixes
Hi, This is just for the SEV (Secure Encrypted Virtualization) part of KVM. It converts the get_user_pages_fast() call, after fixing a couple of small bugs in the vicinity. Note that I have only compile-tested these two patches, so any run-time testing coverage would be greatly appreciated. Cc: Ingo Molnar Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Paolo Bonzini Cc: Sean Christopherson Cc: Vitaly Kuznetsov Cc: Wanpeng Li Cc: Jim Mattson Cc: Joerg Roedel Cc: H. Peter Anvin Cc: x...@kernel.org Cc: k...@vger.kernel.org John Hubbard (2): KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast() KVM: SVM: convert get_user_pages() --> pin_user_pages() arch/x86/kvm/svm/sev.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) base-commit: 9cb1fd0efd195590b828b9b865421ad345a4a145 -- 2.26.2
[PATCH 1/2] KVM: SVM: fix svn_pin_memory()'s use of get_user_pages_fast()
There are two problems in svn_pin_memory():
1) The return value of get_user_pages_fast() is stored in an
unsigned long, although the declared return value is of type int.
This will not cause any symptoms, but it is misleading.
Fix this by changing the type of npinned to "int".
2) The number of pages passed into get_user_pages_fast() is stored
in an unsigned long, even though get_user_pages_fast() accepts an
int. This means that it is possible to silently overflow the number
of pages.
Fix this by adding a WARN_ON_ONCE() and an early error return. The
npages variable is left as an unsigned long for convenience in
checking for overflow.
Fixes: 89c505809052 ("KVM: SVM: Add support for KVM_SEV_LAUNCH_UPDATE_DATA
command")
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Paolo Bonzini
Cc: Sean Christopherson
Cc: Vitaly Kuznetsov
Cc: Wanpeng Li
Cc: Jim Mattson
Cc: Joerg Roedel
Cc: H. Peter Anvin
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: John Hubbard
---
arch/x86/kvm/svm/sev.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 89f7f3aebd31..9693db1af57c 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -313,7 +313,8 @@ static struct page **sev_pin_memory(struct kvm *kvm,
unsigned long uaddr,
int write)
{
struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info;
- unsigned long npages, npinned, size;
+ unsigned long npages, size;
+ int npinned;
unsigned long locked, lock_limit;
struct page **pages;
unsigned long first, last;
@@ -333,6 +334,9 @@ static struct page **sev_pin_memory(struct kvm *kvm,
unsigned long uaddr,
return NULL;
}
+ if (WARN_ON_ONCE(npages > INT_MAX))
+ return NULL;
+
/* Avoid using vmalloc for smaller buffers. */
size = npages * sizeof(struct page *);
if (size > PAGE_SIZE)
--
2.26.2
Re: [PATCH v9 0/8] KVM: Add virtualization support of split lock detection
Hi Thomas, On 5/18/2020 9:27 AM, Xiaoyao Li wrote: On 5/9/2020 7:05 PM, Xiaoyao Li wrote: This series aims to add the virtualization of split lock detection in KVM. Due to the fact that split lock detection is tightly coupled with CPU model and CPU model is configurable by host VMM, we elect to use paravirt method to expose and enumerate it for guest. Thomas and Paolo, Do you have time to have a look at this version? Does this series have any chance to meet 5.8? If not, do you plan to take a look at it after merge window? Thanks, -Xiaoyao
[PATCH v4] thermal: qoriq: Update the settings for TMUv2
For TMU v2, TMSAR registers need to be set properly to get the
accurate temperature values.
Also the temperature read needs to be converted to degree Celsius
since it is in degrees Kelvin.
Signed-off-by: Yuantian Tang
---
v4:
- replace the hard-coded number with constant variables
- update some comments as needed
drivers/thermal/qoriq_thermal.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 028a6bbf75dc..73049f9bea25 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "thermal_core.h"
#include "thermal_hwmon.h"
@@ -23,6 +24,7 @@
#define TMTMIR_DEFAULT 0x000f
#define TIER_DISABLE 0x0
#define TEUMR0_V2 0x51009c00
+#define TMSARA_V2 0xe
#define TMU_VER1 0x1
#define TMU_VER2 0x2
@@ -50,6 +52,9 @@
* Site Register
*/
#define TRITSR_V BIT(31)
+#define REGS_V2_TMSAR(n) (0x304 + 16 * (n)) /* TMU monitoring
+ * site adjustment register
+ */
#define REGS_TTRnCR(n) (0xf10 + 4 * (n)) /* Temperature Range n
* Control Register
*/
@@ -85,12 +90,21 @@ static int tmu_get_temp(void *p, int *temp)
/*
* REGS_TRITSR(id) has the following layout:
*
+* For TMU Rev1:
* 31 ... 7 6 5 4 3 2 1 0
* V TEMP
*
* Where V bit signifies if the measurement is ready and is
* within sensor range. TEMP is an 8 bit value representing
-* temperature in C.
+* temperature in Celsius.
+
+* For TMU Rev2:
+* 31 ... 8 7 6 5 4 3 2 1 0
+* V TEMP
+*
+* Where V bit signifies if the measurement is ready and is
+* within sensor range. TEMP is an 9 bit value representing
+* temperature in KelVin.
*/
if (regmap_read_poll_timeout(qdata->regmap,
REGS_TRITSR(qsensor->id),
@@ -100,7 +114,10 @@ static int tmu_get_temp(void *p, int *temp)
10 * USEC_PER_MSEC))
return -ENODATA;
- *temp = (val & 0xff) * 1000;
+ if (qdata->ver == TMU_VER1)
+ *temp = (val & GENMASK(7, 0)) * MILLIDEGREE_PER_DEGREE;
+ else
+ *temp = kelvin_to_millicelsius(val & GENMASK(8, 0));
return 0;
}
@@ -192,6 +209,8 @@ static int qoriq_tmu_calibration(struct device *dev,
static void qoriq_tmu_init_device(struct qoriq_tmu_data *data)
{
+ int i;
+
/* Disable interrupt, using polling instead */
regmap_write(data->regmap, REGS_TIER, TIER_DISABLE);
@@ -202,6 +221,8 @@ static void qoriq_tmu_init_device(struct qoriq_tmu_data
*data)
} else {
regmap_write(data->regmap, REGS_V2_TMTMIR, TMTMIR_DEFAULT);
regmap_write(data->regmap, REGS_V2_TEUMR(0), TEUMR0_V2);
+ for (i = 0; i < SITES_MAX; i++)
+ regmap_write(data->regmap, REGS_V2_TMSAR(i), TMSARA_V2);
}
/* Disable monitoring */
@@ -212,6 +233,7 @@ static const struct regmap_range qoriq_yes_ranges[] = {
regmap_reg_range(REGS_TMR, REGS_TSCFGR),
regmap_reg_range(REGS_TTRnCR(0), REGS_TTRnCR(3)),
regmap_reg_range(REGS_V2_TEUMR(0), REGS_V2_TEUMR(2)),
+ regmap_reg_range(REGS_V2_TMSAR(0), REGS_V2_TMSAR(15)),
regmap_reg_range(REGS_IPBRR(0), REGS_IPBRR(1)),
/* Read only registers below */
regmap_reg_range(REGS_TRITSR(0), REGS_TRITSR(15)),
--
2.17.1
Re: [RFC 00/16] KVM protected memory extension
On Mon, May 25, 2020 at 04:47:18PM +0300, Liran Alon wrote: > > On 22/05/2020 15:51, Kirill A. Shutemov wrote: > > Furthermore, I would like to point out that just unmapping guest data from > kernel direct-map is not sufficient to prevent all > guest-to-guest info-leaks via a kernel memory info-leak vulnerability. This > is because host kernel VA space have other regions > which contains guest sensitive data. For example, KVM per-vCPU struct (which > holds vCPU state) is allocated on slab and therefore > still leakable. Objects allocated from slab use the direct map, vmalloc() is another story. > > - Touching direct mapping leads to fragmentation. We need to be able to > > recover from it. I have a buggy patch that aims at recovering 2M/1G > > page. > > It has to be fixed and tested properly > > As I've mentioned above, not mapping all guest memory from 1GB hugetlbfs > will lead to holes in kernel direct-map which force it to not be mapped > anymore as a series of 1GB huge-pages. > This have non-trivial performance cost. Thus, I am not sure addressing this > use-case is valuable. Out of curiosity, do we actually have some numbers for the "non-trivial performance cost"? For instance for KVM usecase? -- Sincerely yours, Mike.
Re: [RFC 16/16] KVM: Unmap protected pages from direct mapping
On Fri, May 22, 2020 at 03:52:14PM +0300, Kirill A. Shutemov wrote:
> If the protected memory feature enabled, unmap guest memory from
> kernel's direct mappings.
>
> Migration and KSM is disabled for protected memory as it would require a
> special treatment.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> arch/x86/mm/pat/set_memory.c | 1 +
> include/linux/kvm_host.h | 3 ++
> mm/huge_memory.c | 9 +
> mm/ksm.c | 3 ++
> mm/memory.c | 13 +++
> mm/rmap.c| 4 ++
> virt/kvm/kvm_main.c | 74
> 7 files changed, 107 insertions(+)
>
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index 6f075766bb94..13988413af40 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2227,6 +2227,7 @@ void __kernel_map_pages(struct page *page, int
> numpages, int enable)
>
> arch_flush_lazy_mmu_mode();
> }
> +EXPORT_SYMBOL_GPL(__kernel_map_pages);
>
> #ifdef CONFIG_HIBERNATION
> bool kernel_page_present(struct page *page)
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index b6944f88033d..e1d7762b615c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -705,6 +705,9 @@ int kvm_protect_all_memory(struct kvm *kvm);
> int kvm_protect_memory(struct kvm *kvm,
> unsigned long gfn, unsigned long npages, bool protect);
>
> +void kvm_map_page(struct page *page, int nr_pages);
> +void kvm_unmap_page(struct page *page, int nr_pages);
> +
> int gfn_to_page_many_atomic(struct kvm_memory_slot *slot, gfn_t gfn,
> struct page **pages, int nr_pages);
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index c3562648a4ef..d8a444a401cc 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
This does not seem right...
> #include
> #include
> @@ -650,6 +651,10 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
> vm_fault *vmf,
> spin_unlock(vmf->ptl);
> count_vm_event(THP_FAULT_ALLOC);
> count_memcg_events(memcg, THP_FAULT_ALLOC, 1);
> +
> + /* Unmap page from direct mapping */
> + if (vma_is_kvm_protected(vma))
> + kvm_unmap_page(page, HPAGE_PMD_NR);
... and neither does this.
I think the map/unmap primitives shoud be a part of the generic mm and
not burried inside KVM.
> }
>
> return 0;
> @@ -1886,6 +1891,10 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct
> vm_area_struct *vma,
> page_remove_rmap(page, true);
> VM_BUG_ON_PAGE(page_mapcount(page) < 0, page);
> VM_BUG_ON_PAGE(!PageHead(page), page);
> +
> + /* Map the page back to the direct mapping */
> + if (vma_is_kvm_protected(vma))
> + kvm_map_page(page, HPAGE_PMD_NR);
> } else if (thp_migration_supported()) {
> swp_entry_t entry;
>
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 281c00129a2e..942b88782ac2 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -527,6 +527,9 @@ static struct vm_area_struct *find_mergeable_vma(struct
> mm_struct *mm,
> return NULL;
> if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
> return NULL;
> + /* TODO */
Probably this is not something that should be done. For a security
sensitive environment that wants protected memory, KSM woudn't be
relevant anyway...
> + if (vma_is_kvm_protected(vma))
> + return NULL;
> return vma;
> }
>
> diff --git a/mm/memory.c b/mm/memory.c
> index d7228db6e4bf..74773229b854 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -71,6 +71,7 @@
> #include
> #include
> #include
> +#include
The same comment as in mm/huge_memory.c. I don't think that generic mm
should depend on KVM.
> #include
>
> @@ -1088,6 +1089,11 @@ static unsigned long zap_pte_range(struct mmu_gather
> *tlb,
> likely(!(vma->vm_flags & VM_SEQ_READ)))
> mark_page_accessed(page);
> }
> +
> + /* Map the page back to the direct mapping */
> + if (vma_is_anonymous(vma) && vma_is_kvm_protected(vma))
> + kvm_map_page(page, 1);
> +
> rss[mm_counter(page)]--;
> page_remove_rmap(page, false);
> if (unlikely(page_mapcount(page) < 0))
> @@ -3312,6 +3318,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault
> *vmf)
> struct page *page;
> vm_fault_t ret = 0;
> pte_t entry;
> + bool set = false;
>
> /* File mapping without ->vm_ops ? */
> if (vma->vm_flags & VM_SHARED)
> @@ -3397,6
Re: [RFC 07/16] KVM: mm: Introduce VM_KVM_PROTECTED
On Fri, May 22, 2020 at 03:52:05PM +0300, Kirill A. Shutemov wrote:
> The new VMA flag that indicate a VMA that is not accessible to userspace
> but usable by kernel with GUP if FOLL_KVM is specified.
>
> The FOLL_KVM is only used in the KVM code. The code has to know how to
> deal with such pages.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> include/linux/mm.h | 8
> mm/gup.c| 20
> mm/huge_memory.c| 20
> mm/memory.c | 3 +++
> mm/mmap.c | 3 +++
> virt/kvm/async_pf.c | 4 ++--
> virt/kvm/kvm_main.c | 9 +
> 7 files changed, 53 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index e1882eec1752..4f7195365cc0 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -329,6 +329,8 @@ extern unsigned int kobjsize(const void *objp);
> # define VM_MAPPED_COPY VM_ARCH_1 /* T if mapped copy of data
> (nommu mmap) */
> #endif
>
> +#define VM_KVM_PROTECTED 0
With all the ideas about removing pages from the direct mapi floating
around I wouldn't limit this to KVM.
VM_NOT_IN_DIRECT_MAP would describe such areas better, but I realise
it's very far from perfect and nothing better does not comes to mind :)
> #ifndef VM_GROWSUP
> # define VM_GROWSUP VM_NONE
> #endif
> @@ -646,6 +648,11 @@ static inline bool vma_is_accessible(struct
> vm_area_struct *vma)
> return vma->vm_flags & VM_ACCESS_FLAGS;
> }
>
> +static inline bool vma_is_kvm_protected(struct vm_area_struct *vma)
Ditto
> +{
> + return vma->vm_flags & VM_KVM_PROTECTED;
> +}
> +
> #ifdef CONFIG_SHMEM
> /*
> * The vma_is_shmem is not inline because it is used only by slow
> @@ -2773,6 +2780,7 @@ struct page *follow_page(struct vm_area_struct *vma,
> unsigned long address,
> #define FOLL_LONGTERM0x1 /* mapping lifetime is indefinite: see
> below */
> #define FOLL_SPLIT_PMD 0x2 /* split huge pmd before returning */
> #define FOLL_PIN 0x4 /* pages must be released via unpin_user_page */
> +#define FOLL_KVM 0x8 /* access to VM_KVM_PROTECTED VMAs */
Maybe
FOLL_DM 0x8 /* access memory dropped from the direct map */
> /*
> * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
> diff --git a/mm/gup.c b/mm/gup.c
> index 87a6a59fe667..bd7b9484b35a 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
...
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f609e9ec4a25..d56c3f6efc99 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -112,6 +112,9 @@ pgprot_t vm_get_page_prot(unsigned long vm_flags)
> (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
> pgprot_val(arch_vm_get_page_prot(vm_flags)));
>
> + if (vm_flags & VM_KVM_PROTECTED)
> + ret = PAGE_NONE;
Nit: vma_is_kvm_protected()?
> +
> return arch_filter_pgprot(ret);
> }
> EXPORT_SYMBOL(vm_get_page_prot);
> diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> index 15e5b037f92d..7663e962510a 100644
> --- a/virt/kvm/async_pf.c
> +++ b/virt/kvm/async_pf.c
> @@ -60,8 +60,8 @@ static void async_pf_execute(struct work_struct *work)
>* access remotely.
>*/
> down_read(&mm->mmap_sem);
> - get_user_pages_remote(NULL, mm, addr, 1, FOLL_WRITE, NULL, NULL,
> - &locked);
> + get_user_pages_remote(NULL, mm, addr, 1, FOLL_WRITE | FOLL_KVM, NULL,
> + NULL, &locked);
> if (locked)
> up_read(&mm->mmap_sem);
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 033471f71dae..530af95efdf3 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1727,7 +1727,7 @@ unsigned long kvm_vcpu_gfn_to_hva_prot(struct kvm_vcpu
> *vcpu, gfn_t gfn, bool *w
>
> static inline int check_user_page_hwpoison(unsigned long addr)
> {
> - int rc, flags = FOLL_HWPOISON | FOLL_WRITE;
> + int rc, flags = FOLL_HWPOISON | FOLL_WRITE | FOLL_KVM;
>
> rc = get_user_pages(addr, 1, flags, NULL, NULL);
> return rc == -EHWPOISON;
> @@ -1771,7 +1771,7 @@ static bool hva_to_pfn_fast(unsigned long addr, bool
> write_fault,
> static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault,
> bool *writable, kvm_pfn_t *pfn)
> {
> - unsigned int flags = FOLL_HWPOISON;
> + unsigned int flags = FOLL_HWPOISON | FOLL_KVM;
> struct page *page;
> int npages = 0;
>
> @@ -2255,7 +2255,7 @@ int copy_from_guest(void *data, unsigned long hva, int
> len)
> int npages, seg;
>
> while ((seg = next_segment(len, offset)) != 0) {
> - npages = get_user_pages_unlocked(hva, 1, &page, 0);
> + npages = get_user_pages_unlocked(hva, 1, &page, FOLL_KVM);
> if (npages != 1)
> return -EFAULT;
> memcpy(data, page_address(page) + offset, seg);
> @@ -2275,7 +2275,8 @@ int copy_to_gu
Re: [RFC 10/16] KVM: x86: Enabled protected memory extension
On Fri, May 22, 2020 at 03:52:08PM +0300, Kirill A. Shutemov wrote: > Wire up hypercalls for the feature and define VM_KVM_PROTECTED. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/Kconfig | 1 + > arch/x86/kvm/cpuid.c | 3 +++ > arch/x86/kvm/x86.c | 9 + > include/linux/mm.h | 4 > 4 files changed, 17 insertions(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 58dd44a1b92f..420e3947f0c6 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -801,6 +801,7 @@ config KVM_GUEST > select ARCH_CPUIDLE_HALTPOLL > select X86_MEM_ENCRYPT_COMMON > select SWIOTLB > + select ARCH_USES_HIGH_VMA_FLAGS > default y > ---help--- > This option enables various optimizations for running under the KVM > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 901cd1fdecd9..94cc5e45467e 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -714,6 +714,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array > *array, u32 function) >(1 << KVM_FEATURE_POLL_CONTROL) | >(1 << KVM_FEATURE_PV_SCHED_YIELD); > > + if (VM_KVM_PROTECTED) > + entry->eax |=(1 << KVM_FEATURE_MEM_PROTECTED); > + > if (sched_info_on()) > entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index c17e6eb9ad43..acba0ac07f61 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -7598,6 +7598,15 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > kvm_sched_yield(vcpu->kvm, a0); > ret = 0; > break; > + case KVM_HC_ENABLE_MEM_PROTECTED: > + ret = kvm_protect_all_memory(vcpu->kvm); > + break; > + case KVM_HC_MEM_SHARE: > + ret = kvm_protect_memory(vcpu->kvm, a0, a1, false); > + break; > + case KVM_HC_MEM_UNSHARE: > + ret = kvm_protect_memory(vcpu->kvm, a0, a1, true); > + break; > default: > ret = -KVM_ENOSYS; > break; > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 4f7195365cc0..6eb771c14968 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -329,7 +329,11 @@ extern unsigned int kobjsize(const void *objp); > # define VM_MAPPED_COPY VM_ARCH_1 /* T if mapped copy of data > (nommu mmap) */ > #endif > > +#if defined(CONFIG_X86_64) && defined(CONFIG_KVM) This would be better spelled as ARCH_WANTS_PROTECTED_MEMORY, IMHO. > +#define VM_KVM_PROTECTED VM_HIGH_ARCH_4 Maybe this should be VM_HIGH_ARCH_5 so that powerpc could enable this feature eventually? > +#else > #define VM_KVM_PROTECTED 0 > +#endif > > #ifndef VM_GROWSUP > # define VM_GROWSUP VM_NONE > -- > 2.26.2 > > -- Sincerely yours, Mike.
RE: Another approach of UFSHPB
> On 2020-05-24 22:40, Daejun Park wrote: > > The HPB driver is close to the UFS core function, but it is not essential > > for operating UFS device. With reference to this article > > (https://lwn.net/Articles/645810/), we implemented extended UFS-feature > > as bus model. Because the HPB driver consumes the user's main memory, it > should > > support bind / unbind functionality as needed. We implemented the HPB > driver > > can be unbind / unload on runtime. > > I do not agree that the bus model is the best choice for freeing cache > memory if it is no longer needed. A shrinker is probably a much better > choice because the callback functions in a shrinker get invoked when a > system is under memory pressure. See also register_shrinker(), > unregister_shrinker() and struct shrinker in include/linux/shrinker.h. Since this discussion is closely related to cache allocation, What is your opinion about allocating the pages dynamically as the regions Are being activated/deactivated, in oppose of how it is done today - Statically on init for the entire max-active-subregions?
Re: [RFC 06/16] KVM: Use GUP instead of copy_from/to_user() to access guest memory
On Fri, May 22, 2020 at 03:52:04PM +0300, Kirill A. Shutemov wrote:
> New helpers copy_from_guest()/copy_to_guest() to be used if KVM memory
> protection feature is enabled.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> include/linux/kvm_host.h | 4 +++
> virt/kvm/kvm_main.c | 78 ++--
> 2 files changed, 72 insertions(+), 10 deletions(-)
>
> static int __kvm_read_guest_page(struct kvm_memory_slot *slot, gfn_t gfn,
> - void *data, int offset, int len)
> + void *data, int offset, int len,
> + bool protected)
> {
> int r;
> unsigned long addr;
> @@ -2257,7 +2297,10 @@ static int __kvm_read_guest_page(struct
> kvm_memory_slot *slot, gfn_t gfn,
> addr = gfn_to_hva_memslot_prot(slot, gfn, NULL);
> if (kvm_is_error_hva(addr))
> return -EFAULT;
> - r = __copy_from_user(data, (void __user *)addr + offset, len);
> + if (protected)
> + r = copy_from_guest(data, addr + offset, len);
> + else
> + r = __copy_from_user(data, (void __user *)addr + offset, len);
Maybe always use copy_{from,to}_guest() and move the 'if (protected)'
there?
If kvm is added to memory slot, it cab be the passed to copy_{to,from}_guest.
> if (r)
> return -EFAULT;
> return 0;
> @@ -2268,7 +2311,8 @@ int kvm_read_guest_page(struct kvm *kvm, gfn_t gfn,
> void *data, int offset,
> {
> struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
>
> - return __kvm_read_guest_page(slot, gfn, data, offset, len);
> + return __kvm_read_guest_page(slot, gfn, data, offset, len,
> + kvm->mem_protected);
> }
> EXPORT_SYMBOL_GPL(kvm_read_guest_page);
>
> @@ -2277,7 +2321,8 @@ int kvm_vcpu_read_guest_page(struct kvm_vcpu *vcpu,
> gfn_t gfn, void *data,
> {
> struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
>
> - return __kvm_read_guest_page(slot, gfn, data, offset, len);
> + return __kvm_read_guest_page(slot, gfn, data, offset, len,
> + vcpu->kvm->mem_protected);
> }
> EXPORT_SYMBOL_GPL(kvm_vcpu_read_guest_page);
>
--
Sincerely yours,
Mike.
Re: clean up and streamline probe_kernel_* and friends v4
On Mon, May 25, 2020 at 03:19:12PM -0700, Andrew Morton wrote: > hm. Applying linux-next to this series generates a lot of rejects against > powerpc: > > -rw-rw-r-- 1 akpm akpm 493 May 25 15:06 arch/powerpc/kernel/kgdb.c.rej > -rw-rw-r-- 1 akpm akpm 6461 May 25 15:06 > arch/powerpc/kernel/trace/ftrace.c.rej > -rw-rw-r-- 1 akpm akpm 447 May 25 15:06 arch/powerpc/mm/fault.c.rej > -rw-rw-r-- 1 akpm akpm 623 May 25 15:06 arch/powerpc/perf/core-book3s.c.rej > -rw-rw-r-- 1 akpm akpm 1408 May 25 15:06 arch/riscv/kernel/patch.c.rej > > the arch/powerpc/kernel/trace/ftrace.c ones aren't very trivial. > > It's -rc7. Perhaps we should park all this until 5.8-rc1? As this is a pre-condition for the set_fs removal I'd really like to get the actual changes in. All these conflicts seem to be about the last three cleanup patches just doing renaming, so can we just skip those three for now? Then we can do the rename right after 5.8-rc1 when we have the least chances for conflicts.
Re: [PATCH v2 4/4] x86/boot: Check that there are no runtime relocations
On Tue, 26 May 2020 at 00:59, Arvind Sankar wrote:
>
> Add a linker script check that there are no runtime relocations, and
> remove the old one that tries to check via looking for specially-named
> sections in the object files.
>
> Drop the tests for -fPIE compiler option and -pie linker option, as they
> are available in all supported gcc and binutils versions (as well as
> clang and lld).
>
> Signed-off-by: Arvind Sankar
> ---
> arch/x86/boot/compressed/Makefile | 28 +++---
> arch/x86/boot/compressed/vmlinux.lds.S | 8
> 2 files changed, 11 insertions(+), 25 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/Makefile
> b/arch/x86/boot/compressed/Makefile
> index d3e882e855ee..679a2b383bfe 100644
> --- a/arch/x86/boot/compressed/Makefile
> +++ b/arch/x86/boot/compressed/Makefile
> @@ -27,7 +27,7 @@ targets := vmlinux vmlinux.bin vmlinux.bin.gz
> vmlinux.bin.bz2 vmlinux.bin.lzma \
> vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4
>
> KBUILD_CFLAGS := -m$(BITS) -O2
> -KBUILD_CFLAGS += -fno-strict-aliasing $(call cc-option, -fPIE, -fPIC)
> +KBUILD_CFLAGS += -fno-strict-aliasing -fPIE
> KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
> cflags-$(CONFIG_X86_32) := -march=i386
> cflags-$(CONFIG_X86_64) := -mcmodel=small
> @@ -49,7 +49,7 @@ UBSAN_SANITIZE :=n
> KBUILD_LDFLAGS := -m elf_$(UTS_MACHINE)
> # Compressed kernel should be built as PIE since it may be loaded at any
> # address by the bootloader.
> -KBUILD_LDFLAGS += $(call ld-option, -pie) $(call ld-option,
> --no-dynamic-linker)
> +KBUILD_LDFLAGS += -pie $(call ld-option, --no-dynamic-linker)
Do we still need -pie linking with these changes applied?
> LDFLAGS_vmlinux := -T
>
> hostprogs := mkpiggy
> @@ -84,30 +84,8 @@ vmlinux-objs-$(CONFIG_ACPI) += $(obj)/acpi.o
> vmlinux-objs-$(CONFIG_EFI_STUB) +=
> $(objtree)/drivers/firmware/efi/libstub/lib.a
> vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
>
> -# The compressed kernel is built with -fPIC/-fPIE so that a boot loader
> -# can place it anywhere in memory and it will still run. However, since
> -# it is executed as-is without any ELF relocation processing performed
> -# (and has already had all relocation sections stripped from the binary),
> -# none of the code can use data relocations (e.g. static assignments of
> -# pointer values), since they will be meaningless at runtime. This check
> -# will refuse to link the vmlinux if any of these relocations are found.
> -quiet_cmd_check_data_rel = DATAREL $@
> -define cmd_check_data_rel
> - for obj in $(filter %.o,$^); do \
> - $(READELF) -S $$obj | grep -qF .rel.local && { \
> - echo "error: $$obj has data relocations!" >&2; \
> - exit 1; \
> - } || true; \
> - done
> -endef
> -
> -# We need to run two commands under "if_changed", so merge them into a
> -# single invocation.
> -quiet_cmd_check-and-link-vmlinux = LD $@
> - cmd_check-and-link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)
> -
> $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
> - $(call if_changed,check-and-link-vmlinux)
> + $(call if_changed,ld)
>
> OBJCOPYFLAGS_vmlinux.bin := -R .comment -S
> $(obj)/vmlinux.bin: vmlinux FORCE
> diff --git a/arch/x86/boot/compressed/vmlinux.lds.S
> b/arch/x86/boot/compressed/vmlinux.lds.S
> index d826ab38a8f9..f9902c6ffe29 100644
> --- a/arch/x86/boot/compressed/vmlinux.lds.S
> +++ b/arch/x86/boot/compressed/vmlinux.lds.S
> @@ -42,6 +42,12 @@ SECTIONS
> *(.rodata.*)
> _erodata = . ;
> }
> + .rel.dyn : {
> + *(.rel.*)
> + }
> + .rela.dyn : {
> + *(.rela.*)
> + }
> .got : {
> *(.got)
> }
> @@ -83,3 +89,5 @@ ASSERT(SIZEOF(.got.plt) == 0 || SIZEOF(.got.plt) == 0x18,
> "Unexpected GOT/PLT en
> #else
> ASSERT(SIZEOF(.got.plt) == 0 || SIZEOF(.got.plt) == 0xc, "Unexpected GOT/PLT
> entries detected!")
> #endif
> +
> +ASSERT(SIZEOF(.rel.dyn) == 0 && SIZEOF(.rela.dyn) == 0, "Unexpected runtime
> relocations detected!")
> --
> 2.26.2
>
[PATCH v4 7/7] perf diff: Support hot streams comparison
This patch enables perf-diff with "--stream" option. "--stream": Enable hot streams comparison Now let's see examples. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 hot chain 2: cycles: 29, hits: 2.78% -- compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:39 [ Hot streams in new perf data only ] hot chain 1: cycles: 4, hits: 4.54% -- main div.c:42 compute_flag div.c:28 hot chain 2: cycles: 5, hits: 3.51% -- main div.c:39 main div.c:44 main div.c:42 compute_flag div.c:28 Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-diff.txt | 4 + tools/perf/builtin-diff.c | 133 ++--- 2 files changed, 124 insertions(+), 13 deletions(-) diff --git a/tools/perf/Documentation/perf-diff.txt b/tools/perf/Documentation/perf-diff.txt index f50ca0fef0a4..be65bd55ab2a 100644 --- a/tools/perf/Documentation/perf-diff.txt +++ b/to
[PATCH v4 2/7] perf util: Get the evsel_streams by evsel_idx
In previous patch, we have created evsel_streams array
This patch returns the specified evsel_streams according to the
evsel_idx.
Signed-off-by: Jin Yao
---
tools/perf/util/stream.c | 11 +++
tools/perf/util/stream.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 327a00c27ae2..7f538d1085ef 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -150,3 +150,14 @@ struct evsel_streams *perf_evlist__create_streams(struct
evlist *evlist,
return es;
}
+
+struct evsel_streams *evsel_streams_get(struct evsel_streams *es,
+ int nr_evsel, int evsel_idx)
+{
+ for (int i = 0; i < nr_evsel; i++) {
+ if (es[i].evsel_idx == evsel_idx)
+ return &es[i];
+ }
+
+ return NULL;
+}
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index a8a0172b4d13..705aa7cde3de 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -27,4 +27,7 @@ struct evsel_streams *perf_evlist__create_streams(struct
evlist *evlist,
int nr_streams_max,
enum stream_type type);
+struct evsel_streams *evsel_streams_get(struct evsel_streams *es,
+ int nr_evsel, int evsel_idx);
+
#endif /* __PERF_STREAM_H */
--
2.17.1
[PATCH v4 6/7] perf util: Report hot streams
We show the streams separately. They are divided into different sections.
1. "Matched hot streams"
2. "Hot streams in old perf data only"
3. "Hot streams in new perf data only".
For each stream, we report the cycles and hot percent (hits%).
For example,
cycles: 2, hits: 4.08%
--
main div.c:42
compute_flag div.c:28
Signed-off-by: Jin Yao
---
tools/perf/util/callchain.c | 13
tools/perf/util/callchain.h | 2 +
tools/perf/util/stream.c| 125
tools/perf/util/stream.h| 4 ++
4 files changed, 144 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 4f824bfcc072..1b60985690bb 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1699,3 +1699,16 @@ u64 callchain_total_hits(struct hists *hists)
return chain_hits;
}
+
+s64 callchain_avg_cycles(struct callchain_node *cnode)
+{
+ struct callchain_list *chain;
+ s64 cycles = 0;
+
+ list_for_each_entry(chain, &cnode->val, list) {
+ if (chain->srcline && chain->branch_count)
+ cycles += chain->cycles_count / chain->branch_count;
+ }
+
+ return cycles;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index ac5bea9c1eb7..5824134f983b 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -305,4 +305,6 @@ bool callchain_cnode_matched(struct callchain_node
*base_cnode,
u64 callchain_total_hits(struct hists *hists);
+s64 callchain_avg_cycles(struct callchain_node *cnode);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index d42fad3fff7e..b5cbddaf88d3 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -216,3 +216,128 @@ void match_evsel_streams(struct evsel_streams *es_base,
}
}
}
+
+static void print_callchain_pair(struct stream *base_stream, int idx,
+struct evsel_streams *es_base,
+struct evsel_streams *es_pair)
+{
+ struct callchain_node *base_cnode = base_stream->cnode;
+ struct callchain_node *pair_cnode = base_stream->pair_cnode;
+ struct callchain_list *base_chain, *pair_chain;
+ char buf1[512], buf2[512], cbuf1[256], cbuf2[256];
+ char *s1, *s2;
+ double pct;
+
+ printf("\nhot chain pair %d:\n", idx);
+
+ pct = (double)base_cnode->hit / (double)es_base->streams_hits;
+ scnprintf(buf1, sizeof(buf1), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(base_cnode), pct * 100.0);
+
+ pct = (double)pair_cnode->hit / (double)es_pair->streams_hits;
+ scnprintf(buf2, sizeof(buf2), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(pair_cnode), pct * 100.0);
+
+ printf("%35s\t%35s\n", buf1, buf2);
+
+ printf("%35s\t%35s\n",
+ "---",
+ "--");
+
+ pair_chain = list_first_entry(&pair_cnode->val,
+ struct callchain_list,
+ list);
+
+ list_for_each_entry(base_chain, &base_cnode->val, list) {
+ if (&pair_chain->list == &pair_cnode->val)
+ return;
+
+ s1 = callchain_list__sym_name(base_chain, cbuf1, sizeof(cbuf1),
+ false);
+ s2 = callchain_list__sym_name(pair_chain, cbuf2, sizeof(cbuf2),
+ false);
+
+ scnprintf(buf1, sizeof(buf1), "%35s\t%35s", s1, s2);
+ printf("%s\n", buf1);
+ pair_chain = list_next_entry(pair_chain, list);
+ }
+}
+
+static void print_stream_callchain(struct stream *stream, int idx,
+ struct evsel_streams *es, bool pair)
+{
+ struct callchain_node *cnode = stream->cnode;
+ struct callchain_list *chain;
+ char buf[512], cbuf[256], *s;
+ double pct;
+
+ printf("\nhot chain %d:\n", idx);
+
+ pct = (double)cnode->hit / (double)es->streams_hits;
+ scnprintf(buf, sizeof(buf), "cycles: %ld, hits: %.2f%%",
+ callchain_avg_cycles(cnode), pct * 100.0);
+
+ if (pair) {
+ printf("%35s\t%35s\n", "", buf);
+ printf("%35s\t%35s\n",
+ "", "--");
+ } else {
+ printf("%35s\n", buf);
+ printf("%35s\n", "--");
+ }
+
+ list_for_each_entry(chain, &cnode->val, list) {
+ s = callchain_list__sym_name(chain, cbuf, sizeof(cbuf), false);
+
+ if (pair)
+ scnprintf(buf, sizeof(buf), "%35s\t%35s", "", s);
+ else
+ scnprintf(buf, sizeof(buf), "%35s", s)
[PATCH v4 0/7] perf: Stream comparison
Sometimes, a small change in a hot function reducing the cycles of this function, but the overall workload doesn't get faster. It is interesting where the cycles are moved to. What it would like is to diff before/after streams. The stream is the branch history which is aggregated by the branch records from perf samples. For example, the callchains aggregated from the branch records. By browsing the hot stream, we can understand the hot code path. By browsing the hot streams, we can understand the hot code path. By comparing the cycles variation of same streams between old perf data and new perf data, we can understand if the cycles are moved to other codes. The before stream is the stream in perf.data.old. The after stream is the stream in perf.data. Diffing before/after streams compares top N hottest streams between two perf data files. If all entries of one stream in perf.data.old are fully matched with all entries of another stream in perf.data, we think two streams are matched, otherwise the streams are not matched. For example, cycles: 1, hits: 26.80% cycles: 1, hits: 27.30% -- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 The above streams are matched and we can see for the same streams the cycles (1) are equal and the callchain hit percents are slightly changed (26.80% vs. 27.30%). That's expected. Now let's see examples. perf record -b ... Generate perf.data.old with branch data perf record -b ... Generate perf.data with branch data perf diff --stream [ Matched hot streams ] hot chain pair 1: cycles: 1, hits: 27.77% cycles: 1, hits: 9.24% --- -- main div.c:39 main div.c:39 main div.c:44 main div.c:44 hot chain pair 2: cycles: 34, hits: 20.06%cycles: 27, hits: 16.98% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 __random_r random_r.c:357 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 __random random.c:288 rand rand.c:27 rand rand.c:27 rand rand.c:26 rand rand.c:26 rand@pltrand@plt rand@pltrand@plt compute_flag div.c:25 compute_flag div.c:25 compute_flag div.c:22 compute_flag div.c:22 main div.c:40 main div.c:40 main div.c:40 main div.c:40 main div.c:39 main div.c:39 hot chain pair 3: cycles: 9, hits: 4.48% cycles: 6, hits: 4.51% --- -- __random_r random_r.c:360 __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:380 [ Hot streams in old perf data only ] hot chain 1: cycles: 18, hits: 6.75% -- __random_r random_r.c:360 __random_r random_r.c:388 __random_r random_r.c:388 __random_r random_r.c:380 __random_r random_r.c:357 __random random.c:293 __random random.c:293 __random random.c:291 __random random.c:291 __random random.c:291 __random random.c:288 rand rand.c:27 rand rand.c:26 rand@plt rand@plt compute_flag div.c:25 compute_flag div.c:22 main div.c:40 hot chain 2: cycles: 29,
[PATCH v4 3/7] perf util: Compare two streams
Stream is the branch history which is aggregated by the branch
records from perf samples. Now we only support the callchain as
stream.
If the callchain entries of one stream are fully matched with
the callchain entries of another stream, we think two streams
are matched.
For example,
cycles: 1, hits: 26.80% cycles: 1, hits: 27.30%
--- ---
main div.c:39 main div.c:39
main div.c:44 main div.c:44
Above two streams are matched (we don't consider the case that
source code is changed).
The matching logic is, compare the chain string first. If it's not
matched, fallback to dso address comparison.
Signed-off-by: Jin Yao
---
tools/perf/util/callchain.c | 54 +
tools/perf/util/callchain.h | 4 +++
2 files changed, 58 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 2775b752f2fa..d356e73c5622 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1613,3 +1613,57 @@ void callchain_param_setup(u64 sample_type)
callchain_param.record_mode = CALLCHAIN_FP;
}
}
+
+static bool chain_match(struct callchain_list *base_chain,
+ struct callchain_list *pair_chain)
+{
+ enum match_result match;
+
+ match = match_chain_strings(base_chain->srcline,
+ pair_chain->srcline);
+ if (match != MATCH_ERROR)
+ return match == MATCH_EQ;
+
+ match = match_chain_dso_addresses(base_chain->ms.map,
+ base_chain->ip,
+ pair_chain->ms.map,
+ pair_chain->ip);
+
+ return match == MATCH_EQ;
+}
+
+bool callchain_cnode_matched(struct callchain_node *base_cnode,
+struct callchain_node *pair_cnode)
+{
+ struct callchain_list *base_chain, *pair_chain;
+ bool match = false;
+
+ pair_chain = list_first_entry(&pair_cnode->val,
+ struct callchain_list,
+ list);
+
+ list_for_each_entry(base_chain, &base_cnode->val, list) {
+ if (&pair_chain->list == &pair_cnode->val)
+ return false;
+
+ if (!base_chain->srcline || !pair_chain->srcline) {
+ pair_chain = list_next_entry(pair_chain, list);
+ continue;
+ }
+
+ match = chain_match(base_chain, pair_chain);
+ if (!match)
+ return false;
+
+ pair_chain = list_next_entry(pair_chain, list);
+ }
+
+ /*
+* Say chain1 is ABC, chain2 is ABCD, we consider they are
+* not fully matched.
+*/
+ if (pair_chain && (&pair_chain->list != &pair_cnode->val))
+ return false;
+
+ return match;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index fe36a9e5ccd1..ad27fc8c7948 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -298,4 +298,8 @@ int callchain_branch_counts(struct callchain_root *root,
u64 *abort_count, u64 *cycles_count);
void callchain_param_setup(u64 sample_type);
+
+bool callchain_cnode_matched(struct callchain_node *base_cnode,
+struct callchain_node *pair_cnode);
+
#endif /* __PERF_CALLCHAIN_H */
--
2.17.1
[PATCH v4 5/7] perf util: Calculate the sum of total streams hits
We have used callchain_node->hit to measure the hot level of one
stream. This patch calculates the sum of hits of total streams.
Then in next patch, we can use following formula to report hot
percent for one stream.
hot percent = callchain_node->hit / sum of total hits
Signed-off-by: Jin Yao
---
tools/perf/util/callchain.c | 32
tools/perf/util/callchain.h | 3 +++
tools/perf/util/stream.c| 2 ++
tools/perf/util/stream.h| 1 +
4 files changed, 38 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index d356e73c5622..4f824bfcc072 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -1667,3 +1667,35 @@ bool callchain_cnode_matched(struct callchain_node
*base_cnode,
return match;
}
+
+static u64 count_callchain_hits(struct hist_entry *he)
+{
+ struct rb_root *root = &he->sorted_chain;
+ struct rb_node *rb_node = rb_first(root);
+ struct callchain_node *node;
+ u64 chain_hits = 0;
+
+ while (rb_node) {
+ node = rb_entry(rb_node, struct callchain_node, rb_node);
+ chain_hits += node->hit;
+ rb_node = rb_next(rb_node);
+ }
+
+ return chain_hits;
+}
+
+u64 callchain_total_hits(struct hists *hists)
+{
+ struct rb_node *next = rb_first_cached(&hists->entries);
+ u64 chain_hits = 0;
+
+ while (next) {
+ struct hist_entry *he = rb_entry(next, struct hist_entry,
+rb_node);
+
+ chain_hits += count_callchain_hits(he);
+ next = rb_next(&he->rb_node);
+ }
+
+ return chain_hits;
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index ad27fc8c7948..ac5bea9c1eb7 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -13,6 +13,7 @@ struct ip_callchain;
struct map;
struct perf_sample;
struct thread;
+struct hists;
#define HELP_PAD "\t\t\t\t"
@@ -302,4 +303,6 @@ void callchain_param_setup(u64 sample_type);
bool callchain_cnode_matched(struct callchain_node *base_cnode,
struct callchain_node *pair_cnode);
+u64 callchain_total_hits(struct hists *hists);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 76896a790798..d42fad3fff7e 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -106,6 +106,8 @@ static void init_hot_callchain(struct hists *hists, struct
evsel_streams *es)
update_hot_callchain(he, es);
next = rb_next(&he->rb_node);
}
+
+ es->streams_hits = callchain_total_hits(hists);
}
static int evlist_init_callchain_streams(struct evlist *evlist,
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index 53f34e63f8fb..c34806e50980 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -20,6 +20,7 @@ struct evsel_streams {
int nr_streams_max;
int nr_streams;
int evsel_idx;
+ u64 streams_hits;
};
struct evlist;
--
2.17.1
[PATCH v4 4/7] perf util: Link stream pair
In previous patch, we have created an evsel_streams for one event,
and top N hottest streams will be saved in a stream array in
evsel_streams.
This patch compares total streams among two evsel_streams.
Once two streams are fully matched, they will be linked as
a pair. From the pair, we can know which streams are matched.
Signed-off-by: Jin Yao
---
tools/perf/util/stream.c | 53
tools/perf/util/stream.h | 4 +++
2 files changed, 57 insertions(+)
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
index 7f538d1085ef..76896a790798 100644
--- a/tools/perf/util/stream.c
+++ b/tools/perf/util/stream.c
@@ -161,3 +161,56 @@ struct evsel_streams *evsel_streams_get(struct
evsel_streams *es,
return NULL;
}
+
+static struct stream *stream_callchain_match(struct stream *base_stream,
+struct evsel_streams *es_pair)
+{
+ for (int i = 0; i < es_pair->nr_streams; i++) {
+ struct stream *pair_stream = &es_pair->streams[i];
+
+ if (callchain_cnode_matched(base_stream->cnode,
+ pair_stream->cnode)) {
+ return pair_stream;
+ }
+ }
+
+ return NULL;
+}
+
+static struct stream *stream_match(struct stream *base_stream,
+ struct evsel_streams *es_pair,
+ enum stream_type stream_type)
+{
+ if (stream_type == STREAM_CALLCHAIN)
+ return stream_callchain_match(base_stream, es_pair);
+
+ return NULL;
+}
+
+static void stream_link(struct stream *base_stream, struct stream *pair_stream,
+ enum stream_type stream_type)
+{
+ if (stream_type == STREAM_CALLCHAIN) {
+ base_stream->pair_cnode = pair_stream->cnode;
+ pair_stream->pair_cnode = base_stream->cnode;
+ }
+}
+
+void match_evsel_streams(struct evsel_streams *es_base,
+struct evsel_streams *es_pair)
+{
+ if (es_base->stream_type != es_pair->stream_type)
+ return;
+
+ for (int i = 0; i < es_base->nr_streams; i++) {
+ struct stream *base_stream = &es_base->streams[i];
+ struct stream *pair_stream;
+
+ pair_stream = stream_match(base_stream, es_pair,
+ es_base->stream_type);
+ if (pair_stream) {
+ stream_link(base_stream, pair_stream,
+ es_base->stream_type);
+ }
+ }
+}
diff --git a/tools/perf/util/stream.h b/tools/perf/util/stream.h
index 705aa7cde3de..53f34e63f8fb 100644
--- a/tools/perf/util/stream.h
+++ b/tools/perf/util/stream.h
@@ -11,6 +11,7 @@ enum stream_type {
struct stream {
struct callchain_node *cnode;
+ struct callchain_node *pair_cnode;
};
struct evsel_streams {
@@ -30,4 +31,7 @@ struct evsel_streams *perf_evlist__create_streams(struct
evlist *evlist,
struct evsel_streams *evsel_streams_get(struct evsel_streams *es,
int nr_evsel, int evsel_idx);
+void match_evsel_streams(struct evsel_streams *es_base,
+struct evsel_streams *es_pair);
+
#endif /* __PERF_STREAM_H */
--
2.17.1
[PATCH v4 1/7] perf util: Create streams
We define the stream is the branch history which is aggregated by
the branch records from perf samples. For example, the callchains
aggregated from the branch records. By browsing the hot stream,
we can understand the hot code path.
Now we only support the callchain. So for measuring the hot level
for a stream, we use the callchain_node->hit, higher is hotter.
There may be many callchains sampled so we only focus on top N
hottest callchains. N is a user defined parameter or predefined
default value (nr_streams_max).
This patch creates an evsel_streams array per event, and saves
top N hottest streams in a stream array.
So now we can get the per-event top N hottest streams.
Signed-off-by: Jin Yao
---
tools/perf/util/Build| 1 +
tools/perf/util/stream.c | 152 +++
tools/perf/util/stream.h | 30
3 files changed, 183 insertions(+)
create mode 100644 tools/perf/util/stream.c
create mode 100644 tools/perf/util/stream.h
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 880fcdd1ab11..3bfcdcb3fed2 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -101,6 +101,7 @@ perf-y += call-path.o
perf-y += rwsem.o
perf-y += thread-stack.o
perf-y += spark.o
+perf-y += stream.o
perf-$(CONFIG_AUXTRACE) += auxtrace.o
perf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
perf-$(CONFIG_AUXTRACE) += intel-pt.o
diff --git a/tools/perf/util/stream.c b/tools/perf/util/stream.c
new file mode 100644
index ..327a00c27ae2
--- /dev/null
+++ b/tools/perf/util/stream.c
@@ -0,0 +1,152 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Compare and figure out the top N hottest streams
+ * Copyright (c) 2020, Intel Corporation.
+ * Author: Jin Yao
+ */
+
+#include
+#include
+#include
+#include "debug.h"
+#include "hist.h"
+#include "sort.h"
+#include "stream.h"
+#include "evlist.h"
+
+static void free_evsel_streams(struct evsel_streams *es, int nr_evsel)
+{
+ for (int i = 0; i < nr_evsel; i++)
+ zfree(&es[i].streams);
+
+ free(es);
+}
+
+static struct evsel_streams *create_evsel_streams(int nr_evsel,
+ int nr_streams_max)
+{
+ struct evsel_streams *es;
+
+ es = calloc(nr_evsel, sizeof(struct evsel_streams));
+ if (!es)
+ return NULL;
+
+ for (int i = 0; i < nr_evsel; i++) {
+ struct evsel_streams *s = &es[i];
+
+ s->streams = calloc(nr_streams_max, sizeof(struct stream));
+ if (!s->streams)
+ goto err;
+
+ s->nr_streams_max = nr_streams_max;
+ s->evsel_idx = -1;
+ }
+
+ return es;
+
+err:
+ free_evsel_streams(es, nr_evsel);
+ return NULL;
+}
+
+/*
+ * The cnodes with high hit number are hot callchains.
+ */
+static void set_hot_cnode(struct evsel_streams *es,
+ struct callchain_node *cnode)
+{
+ int i, idx = 0;
+ u64 hit;
+
+ if (es->nr_streams < es->nr_streams_max) {
+ i = es->nr_streams;
+ es->streams[i].cnode = cnode;
+ es->nr_streams++;
+ return;
+ }
+
+ /*
+* Considering a few number of hot streams, only use simple
+* way to find the cnode with smallest hit number and replace.
+*/
+ hit = (es->streams[0].cnode)->hit;
+ for (i = 1; i < es->nr_streams; i++) {
+ if ((es->streams[i].cnode)->hit < hit) {
+ hit = (es->streams[i].cnode)->hit;
+ idx = i;
+ }
+ }
+
+ if (cnode->hit > hit)
+ es->streams[idx].cnode = cnode;
+}
+
+static void update_hot_callchain(struct hist_entry *he,
+struct evsel_streams *es)
+{
+ struct rb_root *root = &he->sorted_chain;
+ struct rb_node *rb_node = rb_first(root);
+ struct callchain_node *cnode;
+
+ while (rb_node) {
+ cnode = rb_entry(rb_node, struct callchain_node, rb_node);
+ set_hot_cnode(es, cnode);
+ rb_node = rb_next(rb_node);
+ }
+}
+
+static void init_hot_callchain(struct hists *hists, struct evsel_streams *es)
+{
+ struct rb_node *next = rb_first_cached(&hists->entries);
+
+ while (next) {
+ struct hist_entry *he;
+
+ he = rb_entry(next, struct hist_entry, rb_node);
+ update_hot_callchain(he, es);
+ next = rb_next(&he->rb_node);
+ }
+}
+
+static int evlist_init_callchain_streams(struct evlist *evlist,
+struct evsel_streams *es, int nr_es)
+{
+ struct evsel *pos;
+ int i = 0;
+
+ BUG_ON(nr_es < evlist->core.nr_entries);
+
+ evlist__for_each_entry(evlist, pos) {
+ struct hists *hists = evsel__hists(pos);
+
+ hists__output_resort(hists, NULL);
+ init_hot_callchain(hists
Re: [PATCH v4 3/3] dmaengine: ptdma: Add debugfs entries for PTDMA information
>> +static const struct file_operations pt_debugfs_info_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_info_read,
>> + .write = NULL,
>> +};
>> +
>> +static const struct file_operations pt_debugfs_queue_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_queue_read,
>> + .write = ptdma_debugfs_queue_write,
>> +};
>> +
>> +static const struct file_operations pt_debugfs_stats_ops = {
>> + .owner = THIS_MODULE,
>> + .open = simple_open,
>> + .read = ptdma_debugfs_stats_read,
>> + .write = ptdma_debugfs_stats_write,
>> +};
>
> pls convert to use DEFINE_SHOW_ATTRIBUTE()
>
Sure, will incorporate the changes in next version of patch.
>> +void ptdma_debugfs_setup(struct pt_device *pt)
>> +{
>> + struct pt_cmd_queue *cmd_q;
>> + char name[MAX_NAME_LEN + 1];
>> + struct dentry *debugfs_q_instance;
>> +
>> + if (!debugfs_initialized())
>> + return;
>> +
>> + mutex_lock(&pt_debugfs_lock);
>> + if (!pt_debugfs_dir)
>> + pt_debugfs_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
>> + mutex_unlock(&pt_debugfs_lock);
>> +
>> + pt->debugfs_instance = debugfs_create_dir(pt->name, pt_debugfs_dir);
>> +
>> + debugfs_create_file("info", 0400, pt->debugfs_instance, pt,
>> + &pt_debugfs_info_ops);
>> +
>> + debugfs_create_file("stats", 0600, pt->debugfs_instance, pt,
>> + &pt_debugfs_stats_ops);
>> +
>> + cmd_q = &pt->cmd_q;
>> +
>> + snprintf(name, MAX_NAME_LEN - 1, "q");
>> +
>> + debugfs_q_instance =
>> + debugfs_create_dir(name, pt->debugfs_instance);
>> +
>> + debugfs_create_file("stats", 0600, debugfs_q_instance, cmd_q,
>> + &pt_debugfs_queue_ops);
>
> Pls use dbg_dev_root in struct dma_device as root for your own debugfs
>
Sure, will incorporate the changes in next version of patch.
> Thanks
> --
> ~Vinod
>
Re: [PATCH 4/5] seccomp: Add SECCOMP_ADDFD_FLAG_MOVE flag to add fd ioctl
> > + * they are created in. Specifcally, sockets, and their interactions with > > the > > + * net_cls and net_prio cgroup v1 controllers. This "moves" the file > > descriptor > > + * so that it takes on the cgroup controller's configuration in the process > > + * that the file descriptor is being added to. > > + */ > > +#define SECCOMP_ADDFD_FLAG_MOVE (1UL << 1) > > I'm not happy about the name because "moving" has much more to do with > transferring ownership than what we are doing here. After a "move" the > fd shouldn't be valid anymore. But that might just be my thinking. > > But why make this opt-in and not do it exactly like when you send around > fds and make this mandatory? Based upon Tycho's comments in an offline thread, I'm going to make this the default (setting the cgroup metadata) to mirror what SCM_RIGHTS does, and then if we come up with a good use case where we need to preserve *cgroup v1* metadata, then we can add an opt-out flag in the future.
[PATCH] Replace HTTP links with HTTPS ones: documentation
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov --- Documentation/COPYING-logo | 2 +- Documentation/admin-guide/LSM/tomoyo.rst | 16 .../admin-guide/acpi/initrd_table_override.rst | 2 +- Documentation/admin-guide/bcache.rst | 4 ++-- Documentation/admin-guide/devices.rst| 2 +- Documentation/admin-guide/initrd.rst | 2 +- Documentation/admin-guide/md.rst | 2 +- Documentation/admin-guide/mono.rst | 4 ++-- Documentation/admin-guide/reporting-bugs.rst | 2 +- Documentation/admin-guide/unicode.rst| 4 ++-- Documentation/conf.py| 2 +- Documentation/dev-tools/gdb-kernel-debugging.rst | 2 +- Documentation/doc-guide/parse-headers.rst| 2 +- .../driver-api/acpi/linuxized-acpica.rst | 6 +++--- Documentation/driver-api/usb/bulk-streams.rst| 4 ++-- .../driver-api/usb/writing_musb_glue_layer.rst | 6 +++--- Documentation/filesystems/path-lookup.txt| 2 +- Documentation/filesystems/seq_file.txt | 4 ++-- Documentation/misc-devices/c2port.txt| 6 +++--- Documentation/process/3.Early-stage.rst | 2 +- Documentation/process/7.AdvancedTopics.rst | 8 Documentation/process/8.Conclusion.rst | 14 +++--- Documentation/process/adding-syscalls.rst| 4 ++-- Documentation/process/applying-patches.rst | 4 ++-- .../process/volatile-considered-harmful.rst | 4 ++-- Documentation/rbtree.txt | 4 ++-- Documentation/security/SCTP.rst | 2 +- Documentation/sphinx/kfigure.py | 6 +++--- Documentation/static-keys.txt| 2 +- Documentation/trace/events-msr.rst | 2 +- Documentation/trace/mmiotrace.rst| 2 +- Documentation/vm/ksm.rst | 2 +- Documentation/xz.txt | 6 +++--- scripts/kernel-doc | 2 +- 34 files changed, 69 insertions(+), 69 deletions(-) diff --git a/Documentation/COPYING-logo b/Documentation/COPYING-logo index 296f0f7f67eb..b21c7cf7d9f6 100644 --- a/Documentation/COPYING-logo +++ b/Documentation/COPYING-logo @@ -9,5 +9,5 @@ scale down to smaller sizes and are better for letterheads or whatever you want to use it for: for the full range of logos take a look at Larry's web-page: - http://www.isc.tamu.edu/~lewing/linux/ + https://www.isc.tamu.edu/~lewing/linux/ diff --git a/Documentation/admin-guide/LSM/tomoyo.rst b/Documentation/admin-guide/LSM/tomoyo.rst index e2d6b6e15082..4bc9c2b4da6f 100644 --- a/Documentation/admin-guide/LSM/tomoyo.rst +++ b/Documentation/admin-guide/LSM/tomoyo.rst @@ -27,29 +27,29 @@ Where is documentation? === User <-> Kernel interface documentation is available at -http://tomoyo.osdn.jp/2.5/policy-specification/index.html . +https://tomoyo.osdn.jp/2.5/policy-specification/index.html . Materials we prepared for seminars and symposiums are available at -http://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . +https://osdn.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . Below lists are chosen from three aspects. What is TOMOYO? TOMOYO Linux Overview -http://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf +https://osdn.jp/projects/tomoyo/docs/lca2009-takeda.pdf TOMOYO Linux: pragmatic and manageable security for Linux -http://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf +https://osdn.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box -http://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf +https://osdn.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf What can TOMOYO do? Deep inside TOMOYO Linux -http://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf +https://osdn.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf The role of "pathname based access control" in security. -http://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf +https://osdn.jp/projects/tomoyo/docs/lfj2008-bof.pdf History of TOMOYO? Realities of Mainlining -http://osdn.jp/projects/tomoyo/docs/lfj2008.pdf +https://osdn.jp/projects/tomoyo/docs/lfj2008.pdf What is future plan? diff --git a/Documentation/admin-guide/acpi/initrd_table_override.rst b/Documentation/admin-guide/acpi/initrd_table_override.rst index cbd76
Re: [PATCH v4 1/3] dmaengine: ptdma: Initial driver for the AMD PTDMA controller
Apologies for my delayed response.
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "ptdma.h"
>> +
>> +static int cmd_queue_length = 32;
>> +module_param(cmd_queue_length, uint, 0644);
>> +MODULE_PARM_DESC(cmd_queue_length,
>> + " length of the command queue, a power of 2 (2 <= val <=
>> 128)");
>
> Any reason for this as module param? who will configure this and how?
>
The command queue length can be from 2 to 64K command.
Therefore added as module parameter to allow the length of the queue to be
specified at load time.
>> + * List of PTDMAs, PTDMA count, read-write access lock, and access functions
>> + *
>> + * Lock structure: get pt_unit_lock for reading whenever we need to
>> + * examine the PTDMA list. While holding it for reading we can acquire
>> + * the RR lock to update the round-robin next-PTDMA pointer. The unit lock
>> + * must be acquired before the RR lock.
>> + *
>> + * If the unit-lock is acquired for writing, we have total control over
>> + * the list, so there's no value in getting the RR lock.
>> + */
>> +static DEFINE_RWLOCK(pt_unit_lock);
>> +static LIST_HEAD(pt_units);
>> +
>> +static struct pt_device *pt_rr;
>
> why do we need these globals and not in driver context?
>
The AMD SOC has multiple PT controller's with the same PCI device ID and hence
the same driver is probed for each instance.
The driver stores the pt_device context of each PT controller in this global
list.
>> +static void pt_add_device(struct pt_device *pt)
>> +{
>> + unsigned long flags;
>> +
>> + write_lock_irqsave(&pt_unit_lock, flags);
>> + list_add_tail(&pt->entry, &pt_units);
>> + if (!pt_rr)
>> + /*
>> + * We already have the list lock (we're first) so this
>> + * pointer can't change on us. Set its initial value.
>> + */
>> + pt_rr = pt;
>> + write_unlock_irqrestore(&pt_unit_lock, flags);
>> +}
>
> Can you please explain what do you mean by having a list of devices and
> why are we adding/removing dynamically?
>
Since AMD SOC has many PT controller's with the same PCI device ID and
hence the same driver probed for initialization of each PT controller device
instance.
Also, the number of PT controller varies for different AMD SOC's.
Therefore the dynamic adding/removing of each PT controller context to global
device list implemented.
> --
> ~Vinod
>
Re: [PATCH v4 4/7] KVM: PPC: clean up redundant 'kvm_run' parameters
On Mon, Apr 27, 2020 at 12:35:11PM +0800, Tianjia Zhang wrote: > In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu' > structure. For historical reasons, many kvm-related function parameters > retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This > patch does a unified cleanup of these remaining redundant parameters. > > Signed-off-by: Tianjia Zhang This looks OK, though possibly a little larger than it needs to be because of variable name changes (kvm_run -> run) that aren't strictly necessary. Reviewed-by: Paul Mackerras
Re: [PATCH v4 5/7] KVM: PPC: clean up redundant kvm_run parameters in assembly
On Mon, Apr 27, 2020 at 12:35:12PM +0800, Tianjia Zhang wrote: > In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu' > structure. For historical reasons, many kvm-related function parameters > retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time. This > patch does a unified cleanup of these remaining redundant parameters. Some of these changes don't look completely correct to me, see below. If you're expecting these patches to go through my tree, I can fix up the patch and commit it (with you as author), noting the changes I made in the commit message. Do you want me to do that? > diff --git a/arch/powerpc/kvm/book3s_interrupts.S > b/arch/powerpc/kvm/book3s_interrupts.S > index f7ad99d972ce..0eff749d8027 100644 > --- a/arch/powerpc/kvm/book3s_interrupts.S > +++ b/arch/powerpc/kvm/book3s_interrupts.S > @@ -55,8 +55,7 @@ > > / > > /* Registers: > - * r3: kvm_run pointer > - * r4: vcpu pointer > + * r3: vcpu pointer > */ > _GLOBAL(__kvmppc_vcpu_run) > > @@ -68,8 +67,8 @@ kvm_start_entry: > /* Save host state to the stack */ > PPC_STLU r1, -SWITCH_FRAME_SIZE(r1) > > - /* Save r3 (kvm_run) and r4 (vcpu) */ > - SAVE_2GPRS(3, r1) > + /* Save r3 (vcpu) */ > + SAVE_GPR(3, r1) > > /* Save non-volatile registers (r14 - r31) */ > SAVE_NVGPRS(r1) > @@ -82,11 +81,11 @@ kvm_start_entry: > PPC_STL r0, _LINK(r1) > > /* Load non-volatile guest state from the vcpu */ > - VCPU_LOAD_NVGPRS(r4) > + VCPU_LOAD_NVGPRS(r3) > > kvm_start_lightweight: > /* Copy registers into shadow vcpu so we can access them in real mode */ > - mr r3, r4 > + mr r4, r3 This mr doesn't seem necessary. > bl FUNC(kvmppc_copy_to_svcpu) > nop > REST_GPR(4, r1) This should be loading r4 from GPR3(r1), not GPR4(r1) - which is what REST_GPR(4, r1) will do. Then, in the file but not in the patch context, there is this line: PPC_LL r3, GPR4(r1)/* vcpu pointer */ where once again GPR4 needs to be GPR3. > @@ -191,10 +190,10 @@ after_sprg3_load: > PPC_STL r31, VCPU_GPR(R31)(r7) > > /* Pass the exit number as 3rd argument to kvmppc_handle_exit */ The comment should be modified to say "2nd" instead of "3rd", otherwise it is confusing. The rest of the patch looks OK. Paul.
Re: [PATCH 2/2] kobject: send KOBJ_REMOVE uevent when the object is removed from sysfs
On Mon, May 25, 2020 at 03:49:01PM -0700, Dmitry Torokhov wrote: > On Sun, May 24, 2020 at 8:34 AM Greg Kroah-Hartman > wrote: > > > > It is possible for a KOBJ_REMOVE uevent to be sent to userspace way > > after the files are actually gone from sysfs, due to how reference > > counting for kobjects work. This should not be a problem, but it would > > be good to properly send the information when things are going away, not > > at some later point in time in the future. > > > > Before this move, if a kobject's parent was torn down before the child, > > And this is the root of the problem and what has to be fixed. I fixed that in patch one of this series. Turns out the user of the kobject was not even expecting that to happen. > > when the call to kobject_uevent() happened, the parent walk to try to > > reconstruct the full path of the kobject could be a total mess and cause > > crashes. It's not good to try to tear down a kobject tree from top > > down, but let's at least try to not to crash if a user does so. > > One can try, but if we keep proper reference counting then kobject > core should take care of actually releasing objects in the right > order. I do not think you should keep this patch, and instead see if > we can push call to kobject_put(kobj->parent) into kobject_cleanup(). I tried that, but there was a _lot_ of underflow errors reported, so there's something else happening. Or my attempt was incorrect :) thanks, greg k-h
[PATCH] coresight: Use devm_kcalloc() in coresight_alloc_conns()
A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
Signed-off-by: Xu Wang
---
drivers/hwtracing/coresight/coresight-platform.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-platform.c
b/drivers/hwtracing/coresight/coresight-platform.c
index 43418a2126ff..6720049409f3 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -27,9 +27,8 @@ static int coresight_alloc_conns(struct device *dev,
struct coresight_platform_data *pdata)
{
if (pdata->nr_outport) {
- pdata->conns = devm_kzalloc(dev, pdata->nr_outport *
- sizeof(*pdata->conns),
- GFP_KERNEL);
+ pdata->conns = devm_kcalloc(dev, pdata->nr_outport,
+ sizeof(*pdata->conns), GFP_KERNEL);
if (!pdata->conns)
return -ENOMEM;
}
--
2.17.1
Re: [RFC PATCH V2 4/7] x86/hw_breakpoint: Prevent data breakpoints on user_pcid_flush_mask
On Tue, May 26, 2020 at 12:39 PM Andy Lutomirski wrote: > > On Mon, May 25, 2020 at 9:31 PM Lai Jiangshan > wrote: > > > > On Tue, May 26, 2020 at 12:21 PM Andy Lutomirski wrote: > > > > > > On Mon, May 25, 2020 at 6:42 PM Lai Jiangshan > > > wrote: > > > > > > > > The percpu user_pcid_flush_mask is used for CPU entry > > > > If a data breakpoint on it, it will cause an unwanted #DB. > > > > Protect the full cpu_tlbstate structure to be sure. > > > > > > > > There are some other percpu data used in CPU entry, but they are > > > > either in already-protected cpu_tss_rw or are safe to trigger #DB > > > > (espfix_waddr, espfix_stack). > > > > > > How hard would it be to rework this to have DECLARE_PERCPU_NODEBUG() > > > and DEFINE_PERCPU_NODEBUG() or similar? > > > > > > I don't know, but it is an excellent idea. Although the patchset > > protects only 2 or 3 portions of percpu data, but there is many > > percpu data used in tracing or kprobe code. They are needed to be > > protected too. > > > > Adds CC: > > Steven Rostedt > > Masami Hiramatsu > > PeterZ is moving things in the direction of more aggressively > disabling hardware breakpoints in the nasty paths where we won't > survive a hardware breakpoint. Does the tracing code have portions > that won't survive a limited amount of recursion? Agree, after "aggressively disabling hardware breakpoints in the nasty paths", only percpu data used by entry code needs to be protected, even non-instrumentable percpu data used by nmi_enter() doesn't need to be marked protected, because #DB is disabled. Only percpu data used by entry code in ranges that #DB is not disabled needs to be protected, there are only a small number of portions, I don't think we need DECLARE_PERCPU_NODEBUG() or so for merely 2 or 3 portions of data. This patchset is sufficient. (espfix_waddr, espfix_stack are not counted into, which needs more review besides me) > > I'm hoping that we can keep the number of no-breakpoint-here percpu > variables low. Maybe we could recruit objtool to help make sure we > got all of them, but that would be a much larger project. > > Would we currently survive a breakpoint on the thread stack? I don't > see any extremely obvious reason that we wouldn't. Blocking such a > breakpoint would be annoying.
Re: linux-next: manual merge of the net-next tree with the bpf tree
On 2020-05-26 05:12, Stephen Rothwell wrote: I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. The fix looks good! I'll keep this is mind, and try not to repeat similar conflicts for future patches. Thanks for the fixup, and for the clarification! Cheers, Björn
Re: [PATCH v4 3/7] KVM: PPC: Remove redundant kvm_run from vcpu_arch
On Mon, Apr 27, 2020 at 12:35:10PM +0800, Tianjia Zhang wrote: > The 'kvm_run' field already exists in the 'vcpu' structure, which > is the same structure as the 'kvm_run' in the 'vcpu_arch' and > should be deleted. > > Signed-off-by: Tianjia Zhang This looks fine. I assume each architecture sub-maintainer is taking the relevant patches from this series via their tree - is that right? Reviewed-by: Paul Mackerras
Re: [PATCH] power: reset: vexpress: fix build issue
On Mon, May 25, 2020 at 07:37:45PM -0400, Valdis Klētnieks wrote: > On Sun, 24 May 2020 15:20:25 -0700, Nathan Chancellor said: > > > arm-linux-gnueabi-ld: drivers/power/reset/vexpress-poweroff.o: in function > > `vexpress_reset_probe': > > vexpress-poweroff.c:(.text+0x36c): undefined reference to > > `devm_regmap_init_vexpress_config' > > The part I can't figure out is that git blame tells me there's already an > export: > > 3b9334ac835bb (Pawel Moll 2014-04-30 16:46:29 +0100 154) return regmap; > 3b9334ac835bb (Pawel Moll 2014-04-30 16:46:29 +0100 155) } > b33cdd283bd91 (Arnd Bergmann 2014-05-26 17:25:22 +0200 156) > EXPORT_SYMBOL_GPL(devm_regmap_init_vexpress_config); > 3b9334ac835bb (Pawel Moll 2014-04-30 16:46:29 +0100 157) > > but I can't figure out where or if drivers/power/reset/vexpress-poweroff.c > gets > a MODULE_LICENSE from... Correct, it is exported but that file is being built as a module whereas the file requiring it is beign builtin. As far as I understand, that will not work, hence the error. The issue with this patch is that ARCH_VEXPRESS still just selects POWER_RESET_VEXPRESS, which ignores "depends on", hence the Kconfig warning and not fixing the error. I am not that much of a Kconfig guru to come up with a solution. I am just reporting it because arm allmodconfig is broken on -next due to this. Cheers, Nathan
[PATCH] vdpa: bypass waking up vhost_woker for vdpa vq kick
Standard vhost devices rely on waking up a vhost_worker to kick
a virtquque. However vdpa devices have hardware backends, so it
does not need this waking up routin. In this commit, vdpa device
will kick a virtqueue directly, reduce the performance overhead
caused by waking up a vhost_woker.
Signed-off-by: Zhu Lingshan
Suggested-by: Jason Wang
---
drivers/vhost/vdpa.c | 100 +++
1 file changed, 100 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 0968361..d3a2aca 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -287,6 +287,66 @@ static long vhost_vdpa_get_vring_num(struct vhost_vdpa *v,
u16 __user *argp)
return 0;
}
+void vhost_vdpa_poll_stop(struct vhost_virtqueue *vq)
+{
+ vhost_poll_stop(&vq->poll);
+}
+
+int vhost_vdpa_poll_start(struct vhost_virtqueue *vq)
+{
+ struct vhost_poll *poll = &vq->poll;
+ struct file *file = vq->kick;
+ __poll_t mask;
+
+
+ if (poll->wqh)
+ return 0;
+
+ mask = vfs_poll(file, &poll->table);
+ if (mask)
+ vq->handle_kick(&vq->poll.work);
+ if (mask & EPOLLERR) {
+ vhost_poll_stop(poll);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static long vhost_vdpa_set_vring_kick(struct vhost_virtqueue *vq,
+ void __user *argp)
+{
+ bool pollstart = false, pollstop = false;
+ struct file *eventfp, *filep = NULL;
+ struct vhost_vring_file f;
+ long r;
+
+ if (copy_from_user(&f, argp, sizeof(f)))
+ return -EFAULT;
+
+ eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
+ if (IS_ERR(eventfp)) {
+ r = PTR_ERR(eventfp);
+ return r;
+ }
+
+ if (eventfp != vq->kick) {
+ pollstop = (filep = vq->kick) != NULL;
+ pollstart = (vq->kick = eventfp) != NULL;
+ } else
+ filep = eventfp;
+
+ if (pollstop && vq->handle_kick)
+ vhost_vdpa_poll_stop(vq);
+
+ if (filep)
+ fput(filep);
+
+ if (pollstart && vq->handle_kick)
+ r = vhost_vdpa_poll_start(vq);
+
+ return r;
+}
static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int cmd,
void __user *argp)
@@ -316,6 +376,11 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v,
unsigned int cmd,
return 0;
}
+ if (cmd == VHOST_SET_VRING_KICK) {
+ r = vhost_vdpa_set_vring_kick(vq, argp);
+ return r;
+ }
+
if (cmd == VHOST_GET_VRING_BASE)
vq->last_avail_idx = ops->get_vq_state(v->vdpa, idx);
@@ -667,6 +732,39 @@ static void vhost_vdpa_free_domain(struct vhost_vdpa *v)
v->domain = NULL;
}
+static int vhost_vdpa_poll_worker(wait_queue_entry_t *wait, unsigned int mode,
+ int sync, void *key)
+{
+ struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait);
+ struct vhost_virtqueue *vq = container_of(poll, struct vhost_virtqueue,
+ poll);
+
+ if (!(key_to_poll(key) & poll->mask))
+ return 0;
+
+ vq->handle_kick(&vq->poll.work);
+
+ return 0;
+}
+
+void vhost_vdpa_poll_init(struct vhost_dev *dev)
+{
+ struct vhost_virtqueue *vq;
+ struct vhost_poll *poll;
+ int i;
+
+ for (i = 0; i < dev->nvqs; i++) {
+ vq = dev->vqs[i];
+ poll = &vq->poll;
+ if (vq->handle_kick) {
+ init_waitqueue_func_entry(&poll->wait,
+ vhost_vdpa_poll_worker);
+ poll->work.fn = vq->handle_kick;
+ }
+
+ }
+}
+
static int vhost_vdpa_open(struct inode *inode, struct file *filep)
{
struct vhost_vdpa *v;
@@ -697,6 +795,8 @@ static int vhost_vdpa_open(struct inode *inode, struct file
*filep)
vhost_dev_init(dev, vqs, nvqs, 0, 0, 0,
vhost_vdpa_process_iotlb_msg);
+ vhost_vdpa_poll_init(dev);
+
dev->iotlb = vhost_iotlb_alloc(0, 0);
if (!dev->iotlb) {
r = -ENOMEM;
--
1.8.3.1
[PATCH v1] x86: Pin cr4 FSGSBASE
From: Andi Kleen
Since there seem to be kernel modules floating around that set
FSGSBASE incorrectly, prevent this in the CR4 pinning. Currently
CR4 pinning just checks that bits are set, this also checks
that the FSGSBASE bit is not set, and if it is clears it again.
Note this patch will need to be undone when the full FSGSBASE
patches are merged. But it's a reasonable solution for v5.2+
stable at least. Sadly the older kernels don't have the necessary
infrastructure for this (although a simpler version of this
could be added there too)
Cc: sta...@vger.kernel.org # v5.2+
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/common.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index bed0cb83fe24..1f5b7871ae9a 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -385,6 +385,11 @@ void native_write_cr4(unsigned long val)
/* Warn after we've set the missing bits. */
WARN_ONCE(bits_missing, "CR4 bits went missing: %lx!?\n",
bits_missing);
+ if (val & X86_CR4_FSGSBASE) {
+ WARN_ONCE(1, "CR4 unexpectedly set FSGSBASE!?\n");
+ val &= ~X86_CR4_FSGSBASE;
+ goto set_register;
+ }
}
}
EXPORT_SYMBOL(native_write_cr4);
--
2.25.4
linux-next: manual merge of the devicetree tree with the watchdog tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/watchdog/renesas,wdt.txt
between commit:
ff1ee6fb276c ("dt-bindings: watchdog: renesas,wdt: Document r8a7742 support")
from the watchdog tree and commit:
d0941cfb9fa8 ("dt-bindings: watchdog: renesas-wdt: Convert to json-schema")
from the devicetree tree.
I fixed it up (I removed the file and added the patch below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Tue, 26 May 2020 15:15:51 +1000
Subject: [PATCH] dt-bindings: watchdog: renesas-wdt: fix up for yaml conversion
Signed-off-by: Stephen Rothwell
---
Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
index 27e8c4accd67..572f4c912fef 100644
--- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml
@@ -24,6 +24,7 @@ properties:
- items:
- enum:
+ - renesas,r8a7742-wdt # RZ/G1H
- renesas,r8a7743-wdt # RZ/G1M
- renesas,r8a7744-wdt # RZ/G1N
- renesas,r8a7745-wdt # RZ/G1E
--
2.26.2
--
Cheers,
Stephen Rothwell
pgpNAauURmcjD.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] iommu/iova: Retry from last rb tree node if iova search fails
On 5/11/2020 4:34 PM, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> When ever a new iova alloc request comes iova is always searched
> from the cached node and the nodes which are previous to cached
> node. So, even if there is free iova space available in the nodes
> which are next to the cached node iova allocation can still fail
> because of this approach.
>
> Consider the following sequence of iova alloc and frees on
> 1GB of iova space
>
> 1) alloc - 500MB
> 2) alloc - 12MB
> 3) alloc - 499MB
> 4) free - 12MB which was allocated in step 2
> 5) alloc - 13MB
>
> After the above sequence we will have 12MB of free iova space and
> cached node will be pointing to the iova pfn of last alloc of 13MB
> which will be the lowest iova pfn of that iova space. Now if we get an
> alloc request of 2MB we just search from cached node and then look
> for lower iova pfn's for free iova and as they aren't any, iova alloc
> fails though there is 12MB of free iova space.
>
> To avoid such iova search failures do a retry from the last rb tree node
> when iova search fails, this will search the entire tree and get an iova
> if its available
>
> Signed-off-by: Vijayanand Jitta
> ---
> drivers/iommu/iova.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 0e6a953..7d82afc 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -184,8 +184,9 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> struct rb_node *curr, *prev;
> struct iova *curr_iova;
> unsigned long flags;
> - unsigned long new_pfn;
> + unsigned long new_pfn, alloc_lo_new;
> unsigned long align_mask = ~0UL;
> + unsigned long alloc_hi = limit_pfn, alloc_lo = iovad->start_pfn;
>
> if (size_aligned)
> align_mask <<= fls_long(size - 1);
> @@ -198,15 +199,25 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
>
> curr = __get_cached_rbnode(iovad, limit_pfn);
> curr_iova = rb_entry(curr, struct iova, node);
> + alloc_lo_new = curr_iova->pfn_hi;
> +
> +retry:
> do {
> - limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
> - new_pfn = (limit_pfn - size) & align_mask;
> + alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
> + new_pfn = (alloc_hi - size) & align_mask;
> prev = curr;
> curr = rb_prev(curr);
> curr_iova = rb_entry(curr, struct iova, node);
> } while (curr && new_pfn <= curr_iova->pfn_hi);
>
> - if (limit_pfn < size || new_pfn < iovad->start_pfn) {
> + if (alloc_hi < size || new_pfn < alloc_lo) {
> + if (alloc_lo == iovad->start_pfn && alloc_lo_new < limit_pfn) {
> + alloc_hi = limit_pfn;
> + alloc_lo = alloc_lo_new;
> + curr = &iovad->anchor.node;
> + curr_iova = rb_entry(curr, struct iova, node);
> + goto retry;
> + }
> iovad->max32_alloc_size = size;
> goto iova32_full;
> }
>
ping?
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 3/3] hwrng: ba431-rng: add support for BA431 hwrng
On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> wrote:
> >
> > Silex insight BA431 is an IP designed to generate random numbers that
> > can be integrated in various FPGA.
> > This driver adds support for it through the hwrng interface.
> >
> > This driver is used in Silex Insight Viper OEM boards.
> >
> > Signed-off-by: Olivier Sobrie
> > Signed-off-by: Waleed Ziad
>
> The driver looks good to me.
>
> Acked-by: Arnd Bergmann
>
> > drivers/char/hw_random/Kconfig | 10 ++
> > drivers/char/hw_random/Makefile| 1 +
> > drivers/char/hw_random/ba431-rng.c | 240 +
>
> I wonder if we should move drivers/char/hw_random to its own top-level drivers
> subsystem outside of drivers/char. It seems to be growing steadily and is
> larger
> than a lot of other subsystems with currently 34 drivers in there.
>
> Not your problem though.
>
> > + /* Wait until the state changed */
> > + for (i = 0; i < BA431_RESET_READ_STATUS_RETRIES; ++i) {
> > + state = ba431_trng_get_state(ba431);
> > + if (state >= BA431_STATE_STARTUP)
> > + break;
> > +
> > + udelay(BA431_RESET_READ_STATUS_INTERVAL);
> > + }
>
> Looking for something to improve, I noticed that this loop can take over
> a millisecond to time out, and it always runs in non-atomic context.
> It may be better to use usleep_range() than udelay().
Ok I'll change that and send a v2 later this week.
Thank you,
Olivier
Re: [PATCH v3 0/3] Add Qualcomm IPCC driver support
Hi Jassi, On Wed, May 20, 2020 at 02:18:51PM +0530, Manivannan Sadhasivam wrote: > Hello, > > This series adds mailbox driver support for Qualcomm Inter Processor > Communications Controller (IPCC) block found in MSM chipsets. This block > is used to route interrupts between modems, DSPs and APSS (Application > Processor Subsystem). > > The driver is modeled as a mailbox+irqchip driver. The irqchip part helps > in receiving the interrupts from the IPCC clients such as modems, DSPs, > PCI-E etc... and forwards them to respective entities in APSS. > > On the other hand, the mailbox part is used to send interrupts to the IPCC > clients from the entities of APSS. > > This series is tested on SM8250-MTP board. > Any update on this series? Thanks, Mani > Thanks, > Mani > > Changes in v3: > > * Added Bjorn's review tags > * Few changes to DT binding as suggested by Rob > > Changes in v2: > > * Moved from soc/ to mailbox/ > * Switched to static mbox channels > * Some misc cleanups > > Manivannan Sadhasivam (3): > dt-bindings: mailbox: Add devicetree binding for Qcom IPCC > mailbox: Add support for Qualcomm IPCC > MAINTAINERS: Add entry for Qualcomm IPCC driver > > .../bindings/mailbox/qcom-ipcc.yaml | 80 + > MAINTAINERS | 8 + > drivers/mailbox/Kconfig | 10 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/qcom-ipcc.c | 286 ++ > include/dt-bindings/mailbox/qcom-ipcc.h | 33 ++ > 6 files changed, 419 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml > create mode 100644 drivers/mailbox/qcom-ipcc.c > create mode 100644 include/dt-bindings/mailbox/qcom-ipcc.h > > -- > 2.26.GIT >
Re: [PATCH] drivers/virt/fsl_hypervisor: Correcting error handling path
On Fri, May 22, 2020 at 6:24 PM Dan Carpenter wrote:
>
> On Thu, May 14, 2020 at 01:53:16AM +0530, Souptick Joarder wrote:
> > First, when memory allocation for sg_list_unaligned failed, there
> > is no point of calling put_pages() as we haven't pinned any pages.
> >
> > Second, if get_user_pages_fast() failed we should unpinned num_pinned
> > pages, no point of checking till num_pages.
> >
> > This will address both.
> >
> > Signed-off-by: Souptick Joarder
>
> If gup_flags were | FOLL_LONGTERM then this patch would fix a double
> free because of the put_page() in __gup_longterm_locked().
>
> mm/gup.c
> 1786 if (check_dax_vmas(vmas_tmp, rc)) {
> 1787 for (i = 0; i < rc; i++)
> 1788 put_page(pages[i]);
> ^^^
> put_page() here and also in the caller.
>
> 1789 rc = -EOPNOTSUPP;
> 1790 goto out;
> 1791 }
>
> But since this isn't FOLL_LONGTERM the patch is a nice cleanup which
> doesn't affect run time.
>
> Reviewed-by: Dan Carpenter
Hi Andrew,
Is it fine to take it through mm tree ?
Re: Re: [PATCH] iio: magnetometer: ak8974: Fix runtime PM imbalance on error
Hi, Linus
> On Sun, May 24, 2020 at 4:51 AM Dinghao Liu wrote:
>
> > When devm_regmap_init_i2c() returns an error code, a pairing
> > runtime PM usage counter decrement is needed to keep the
> > counter balanced. For error paths after ak8974_set_power(),
> > ak8974_detect() and ak8974_reset(), things are the same.
> >
> > However, When iio_triggered_buffer_setup() returns an error
> > code, we don't need such a decrement because there is already
> > one before this call. Things are the same for other error paths
> > after it.
> >
> > Signed-off-by: Dinghao Liu
>
> > ak8974->map = devm_regmap_init_i2c(i2c, &ak8974_regmap_config);
> > if (IS_ERR(ak8974->map)) {
> > dev_err(&i2c->dev, "failed to allocate register map\n");
> > + pm_runtime_put_noidle(&i2c->dev);
> > + pm_runtime_disable(&i2c->dev);
> > return PTR_ERR(ak8974->map);
>
> This is correct.
>
> > ret = ak8974_set_power(ak8974, AK8974_PWR_ON);
> > if (ret) {
> > dev_err(&i2c->dev, "could not power on\n");
> > + pm_runtime_put_noidle(&i2c->dev);
> > + pm_runtime_disable(&i2c->dev);
> > goto power_off;
>
> What about just changing this to goto disable_pm;
>
> > ret = ak8974_detect(ak8974);
> > if (ret) {
> > dev_err(&i2c->dev, "neither AK8974 nor AMI30x found\n");
> > + pm_runtime_put_noidle(&i2c->dev);
> > + pm_runtime_disable(&i2c->dev);
> > goto power_off;
>
> goto disable_pm;
>
> > @@ -786,6 +792,8 @@ static int ak8974_probe(struct i2c_client *i2c,
> > ret = ak8974_reset(ak8974);
> > if (ret) {
> > dev_err(&i2c->dev, "AK8974 reset failed\n");
> > + pm_runtime_put_noidle(&i2c->dev);
> > + pm_runtime_disable(&i2c->dev);
>
> goto disable_pm;
>
> > disable_pm:
> > - pm_runtime_put_noidle(&i2c->dev);
> > pm_runtime_disable(&i2c->dev);
> > ak8974_set_power(ak8974, AK8974_PWR_OFF);
>
> Keep the top pm_runtime_put_noidle().
I found that there was already a pm_runtime_put() before
iio_triggered_buffer_setup() (just after pm_runtime_use_autosuspend).
So if we keep the pm_runtime_put_noidle() here, we will have
two pmusage counter decrement. Do you think this is a bug?
Regards,
Dinghao
>
> The ak8974_set_power() call is fine, the power on call does not
> need to happen in balance. Sure it will attempt to write a register
> but so will the power on call.
>
> Yours,
> Linus Walleij
[PATCH v2 2/2] phy: intel: Add Keem Bay eMMC PHY support
Add support for eMMC PHY on Intel Keem Bay SoC.
Signed-off-by: Wan Ahmad Zainie
---
drivers/phy/intel/Kconfig| 8 +
drivers/phy/intel/Makefile | 1 +
drivers/phy/intel/phy-keembay-emmc.c | 321 +++
3 files changed, 330 insertions(+)
create mode 100644 drivers/phy/intel/phy-keembay-emmc.c
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index 7b47682a4e0e..5f5497d1624a 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -22,3 +22,11 @@ config PHY_INTEL_EMMC
select GENERIC_PHY
help
Enable this to support the Intel EMMC PHY
+
+config PHY_KEEMBAY_EMMC
+ tristate "Intel Keem Bay EMMC PHY Driver"
+ depends on OF
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Enable this to support the Keem Bay EMMC PHY.
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index 233d530dadde..6566334e7b77 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_PHY_INTEL_COMBO) += phy-intel-combo.o
obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
+obj-$(CONFIG_PHY_KEEMBAY_EMMC) += phy-keembay-emmc.o
diff --git a/drivers/phy/intel/phy-keembay-emmc.c
b/drivers/phy/intel/phy-keembay-emmc.c
new file mode 100644
index ..546854cdbb0c
--- /dev/null
+++ b/drivers/phy/intel/phy-keembay-emmc.c
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay eMMC PHY driver
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* eMMC/SD/SDIO core/phy configuration registers */
+#define PHY_CFG_0 0x24
+#define SEL_DLY_TXCLK_MASKBIT(29)
+#define SEL_DLY_TXCLK(x) (((x) << 29) & SEL_DLY_TXCLK_MASK)
+#define OTAP_DLY_ENA_MASK BIT(27)
+#define OTAP_DLY_ENA(x) (((x) << 27) & OTAP_DLY_ENA_MASK)
+#define OTAP_DLY_SEL_MASK GENMASK(26, 23)
+#define OTAP_DLY_SEL(x) (((x) << 23) & OTAP_DLY_SEL_MASK)
+#define DLL_EN_MASK BIT(10)
+#define DLL_EN(x) (((x) << 10) & DLL_EN_MASK)
+#define PWR_DOWN_MASK BIT(0)
+#define PWR_DOWN(x) (((x) << 0) & PWR_DOWN_MASK)
+
+#define PHY_CFG_2 0x2c
+#define SEL_FREQ_MASK GENMASK(12, 10)
+#define SEL_FREQ(x) (((x) << 10) & SEL_FREQ_MASK)
+
+#define PHY_STAT 0x40
+#define CAL_DONE_MASK BIT(6)
+#define IS_CALDONE(x) ((x) & CAL_DONE_MASK)
+#define DLL_RDY_MASK BIT(5)
+#define IS_DLLRDY(x) ((x) & DLL_RDY_MASK)
+
+/* From ACS_eMMC51_16nFFC_RO1100_Userguide_v1p0.pdf p17 */
+#define FREQSEL_200M_170M 0x0
+#define FREQSEL_170M_140M 0x1
+#define FREQSEL_140M_110M 0x2
+#define FREQSEL_110M_80M 0x3
+#define FREQSEL_80M_50M0x4
+
+struct keembay_emmc_phy {
+ struct regmap *syscfg;
+ struct clk *emmcclk;
+};
+
+static const struct regmap_config keembay_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static int keembay_emmc_phy_power(struct phy *phy, bool on_off)
+{
+ struct keembay_emmc_phy *priv = phy_get_drvdata(phy);
+ unsigned int caldone;
+ unsigned int dllrdy;
+ unsigned int freqsel;
+ unsigned int mhz;
+ int ret;
+
+ /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+ ret = regmap_update_bits(priv->syscfg, PHY_CFG_0, PWR_DOWN_MASK,
+PWR_DOWN(0));
+ if (ret) {
+ dev_err(&phy->dev, "CALIO power down bar failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_update_bits(priv->syscfg, PHY_CFG_0, DLL_EN_MASK,
+DLL_EN(0));
+ if (ret) {
+ dev_err(&phy->dev, "turn off the dll failed: %d\n", ret);
+ return ret;
+ }
+
+ /* Already finish power off above */
+ if (!on_off)
+ return 0;
+
+ mhz = DIV_ROUND_CLOSEST(clk_get_rate(priv->emmcclk), 100);
+ if (mhz <= 200 && mhz >= 170)
+ freqsel = FREQSEL_200M_170M;
+ else if (mhz <= 170 && mhz >= 140)
+ freqsel = FREQSEL_170M_140M;
+ else if (mhz <= 140 && mhz >= 110)
+ freqsel = FREQSEL_140M_110M;
+ else if (mhz <= 110 && mhz >= 80)
+ freqsel = FREQSEL_110M_80M;
+ else if (mhz <= 80 && mhz >= 50)
+ freqsel = FREQSEL_80M_50M;
+ else
+ freqsel = 0x0;
+
+ if (mhz < 50 || mhz > 200)
+ dev_warn(&phy->dev, "Unsupported rate: %d MHz\n", mhz);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+
[PATCH 2/2] arm64: tegra: Add pwm-fan profile settings
Add support for profiles in device tree to allow
different fan settings for trip point temp/hyst/pwm.
Signed-off-by: Sandipan Patra
---
arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
index e15d1ea..ff2b980 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
@@ -219,10 +219,19 @@
fan: fan {
compatible = "pwm-fan";
- pwms = <&pwm4 0 45334>;
-
- cooling-levels = <0 64 128 255>;
#cooling-cells = <2>;
+ pwms = <&pwm4 0 45334>;
+ profiles {
+ default = "quiet";
+ quiet {
+ state_cap = <4>;
+ cooling-levels = <0 77 120 160 255 255 255 255
255 255>;
+ };
+ cool {
+ state_cap = <4>;
+ cooling-levels = <0 77 120 160 255 255 255 255
255 255>;
+ };
+ };
};
gpio-keys {
--
2.7.4
[PATCH v2 1/2] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
Binding description for Intel Keem Bay eMMC PHY.
Signed-off-by: Wan Ahmad Zainie
---
.../bindings/phy/intel,keembay-emmc-phy.yaml | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
new file mode 100644
index ..d3e0f169eb0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 Intel Corporation
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-phy.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Intel Keem Bay eMMC PHY bindings
+
+maintainers:
+ - Wan Ahmad Zainie
+
+properties:
+ compatible:
+const: intel,keembay-emmc-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: emmcclk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+phy@2029 {
+ compatible = "intel,keembay-emmc-phy";
+ reg = <0x0 0x2029 0x0 0x54>;
+ clocks = <&emmc>;
+ clock-names = "emmcclk";
+ #phy-cells = <0>;
+};
--
2.17.1
[PATCH v2 0/2] phy: intel: Add Keem Bay eMMC PHY support
Hi. The first part is to document DT bindings for Keem Bay eMMC PHY. The second is the driver file, loosely based on phy-rockchip-emmc.c and phy-intel-emmc.c. The latter is not being reused as there are quite a number of differences i.e. registers offset, supported clock rates, bitfield to set. The patch was tested with Keem Bay evaluation module board. Thank you. Best regards, Zainie Changes since v1: - Rework phy-keembay-emmc.c to make it similar to phy-intel-emmc.c. - Use regmap_mmio, and remove reference to intel,syscon. - Use node name phy@ - Update license i.e. use dual license. Wan Ahmad Zainie (2): dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings phy: intel: Add Keem Bay eMMC PHY support .../bindings/phy/intel,keembay-emmc-phy.yaml | 45 +++ drivers/phy/intel/Kconfig | 8 + drivers/phy/intel/Makefile| 1 + drivers/phy/intel/phy-keembay-emmc.c | 321 ++ 4 files changed, 375 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml create mode 100644 drivers/phy/intel/phy-keembay-emmc.c -- 2.17.1
[PATCH 1/2] hwmon: pwm-fan: Add profile support and add remove module support
This change has 2 parts:
1. Add support for profiles mode settings.
This allows different fan settings for trip point temp/hyst/pwm.
T194 has multiple fan-profiles support.
2. Add pwm-fan remove support. This is essential since the config is
tristate capable.
Signed-off-by: Sandipan Patra
---
drivers/hwmon/pwm-fan.c | 112 ++--
1 file changed, 100 insertions(+), 12 deletions(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 30b7b3e..26db589 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -3,8 +3,10 @@
* pwm-fan.c - Hwmon driver for fans connected to PWM lines.
*
* Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2020, NVIDIA Corporation.
*
* Author: Kamil Debski
+ * Author: Sandipan Patra
*/
#include
@@ -21,6 +23,8 @@
#include
#define MAX_PWM 255
+/* Based on OF max device tree node name length */
+#define MAX_PROFILE_NAME_LENGTH31
struct pwm_fan_ctx {
struct mutex lock;
@@ -38,6 +42,12 @@ struct pwm_fan_ctx {
unsigned int pwm_fan_state;
unsigned int pwm_fan_max_state;
unsigned int *pwm_fan_cooling_levels;
+
+ unsigned int pwm_fan_profiles;
+ const char **fan_profile_names;
+ unsigned int **fan_profile_cooling_levels;
+ unsigned int fan_current_profile;
+
struct thermal_cooling_device *cdev;
};
@@ -227,28 +237,86 @@ static int pwm_fan_of_get_cooling_data(struct device *dev,
struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev->of_node;
+ struct device_node *base_profile = NULL;
+ struct device_node *profile_np = NULL;
+ const char *default_profile = NULL;
int num, i, ret;
- if (!of_find_property(np, "cooling-levels", NULL))
- return 0;
+ num = of_property_count_u32_elems(np, "cooling-levels");
+ if (num <= 0) {
+ base_profile = of_get_child_by_name(np, "profiles");
+ if (!base_profile) {
+ dev_err(dev, "Wrong Data\n");
+ return -EINVAL;
+ }
+ }
+
+ if (base_profile) {
+ ctx->pwm_fan_profiles =
+ of_get_available_child_count(base_profile);
+
+ if (ctx->pwm_fan_profiles <= 0) {
+ dev_err(dev, "Profiles used but not defined\n");
+ return -EINVAL;
+ }
- ret = of_property_count_u32_elems(np, "cooling-levels");
- if (ret <= 0) {
- dev_err(dev, "Wrong data!\n");
- return ret ? : -EINVAL;
+ ctx->fan_profile_names = devm_kzalloc(dev,
+ sizeof(const char *) * ctx->pwm_fan_profiles,
+ GFP_KERNEL);
+ ctx->fan_profile_cooling_levels = devm_kzalloc(dev,
+ sizeof(int *) * ctx->pwm_fan_profiles,
+ GFP_KERNEL);
+
+ if (!ctx->fan_profile_names
+ || !ctx->fan_profile_cooling_levels)
+ return -ENOMEM;
+
+ ctx->fan_current_profile = 0;
+ i = 0;
+ for_each_available_child_of_node(base_profile, profile_np) {
+ num = of_property_count_u32_elems(profile_np,
+ "cooling-levels");
+ if (num <= 0) {
+ dev_err(dev, "No data in cooling-levels inside
profile node!\n");
+ return -EINVAL;
+ }
+
+ of_property_read_string(profile_np, "name",
+ &ctx->fan_profile_names[i]);
+ if (default_profile &&
+ !strncmp(default_profile,
+ ctx->fan_profile_names[i],
+ MAX_PROFILE_NAME_LENGTH))
+ ctx->fan_current_profile = i;
+
+ ctx->fan_profile_cooling_levels[i] =
+ devm_kzalloc(dev, sizeof(int) * num,
+ GFP_KERNEL);
+ if (!ctx->fan_profile_cooling_levels[i])
+ return -ENOMEM;
+
+ of_property_read_u32_array(profile_np, "cooling-levels",
+ ctx->fan_profile_cooling_levels[i], num);
+ i++;
+ }
}
- num = ret;
ctx->pwm_fan_cooling_levels = devm_kcalloc(dev, num, sizeof(u32),
GFP_KERNEL);
if (!ctx->pwm_fan_cooling_levels)
return -ENOMEM;
- ret = of_property_read_u32_array(np,
Re: [PATCH] kexec: Do not verify the signature without the lockdown or mandatory signature
On 05/25/20 at 01:23pm, Lianbo Jiang wrote:
> Signature verification is an important security feature, to protect
> system from being attacked with a kernel of unknown origin. Kexec
> rebooting is a way to replace the running kernel, hence need be
> secured carefully.
>
> In the current code of handling signature verification of kexec kernel,
> the logic is very twisted. It mixes signature verification, IMA signature
> appraising and kexec lockdown.
>
> If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of
> signature, the supported crypto, and key, we don't think this is wrong,
> Unless kexec lockdown is executed. IMA is considered as another kind of
> signature appraising method.
>
> If kexec kernel image has signature/crypto/key, it has to go through the
> signature verification and pass. Otherwise it's seen as verification
> failure, and won't be loaded.
>
> Seems kexec kernel image with an unqualified signature is even worse than
> those w/o signature at all, this sounds very unreasonable. E.g. If people
> get a unsigned kernel to load, or a kernel signed with expired key, which
> one is more dangerous?
>
> So, here, let's simplify the logic to improve code readability. If the
> KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification
> is mandated. Otherwise, we lift the bar for any kernel image.
>
> Signed-off-by: Lianbo Jiang
> ---
> kernel/kexec_file.c | 37 ++---
> 1 file changed, 6 insertions(+), 31 deletions(-)
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index faa74d5f6941..e4bdf0c42f35 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -181,52 +181,27 @@ void kimage_file_post_load_cleanup(struct kimage *image)
> static int
> kimage_validate_signature(struct kimage *image)
> {
> - const char *reason;
> int ret;
>
> ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
> image->kernel_buf_len);
> - switch (ret) {
> - case 0:
> - break;
> + if (ret) {
> + pr_debug("kernel signature verification failed (%d).\n", ret);
>
> - /* Certain verification errors are non-fatal if we're not
> - * checking errors, provided we aren't mandating that there
> - * must be a valid signature.
> - */
> - case -ENODATA:
> - reason = "kexec of unsigned image";
> - goto decide;
> - case -ENOPKG:
> - reason = "kexec of image with unsupported crypto";
> - goto decide;
> - case -ENOKEY:
> - reason = "kexec of image with unavailable key";
> - decide:
> - if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
> - pr_notice("%s rejected\n", reason);
> + if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE))
> return ret;
> - }
>
> - /* If IMA is guaranteed to appraise a signature on the kexec
> + /*
> + * If IMA is guaranteed to appraise a signature on the kexec
>* image, permit it even if the kernel is otherwise locked
>* down.
>*/
> if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
> security_locked_down(LOCKDOWN_KEXEC))
> return -EPERM;
> -
> - return 0;
> -
> - /* All other errors are fatal, including nomem, unparseable
> - * signatures and signature check failures - even if signatures
> - * aren't required.
> - */
> - default:
> - pr_notice("kernel signature verification failed (%d).\n", ret);
> }
>
> - return ret;
> + return 0;
> }
> #endif
>
> --
> 2.17.1
>
Acked-by: Dave Young
Thanks
Dave
drivers/mfd/sprd-sc27xx-spi.c:59:23: warning: no previous prototype for 'sprd_pmic_detect_charger_type'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 9cb1fd0efd195590b828b9b865421ad345a4a145
commit: 2a7e7274f3d43d2a072cab25c0035dc994903bb9 mfd: sc27xx: Add USB charger
type detection support
date: 8 weeks ago
config: h8300-randconfig-r006-20200526 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 2a7e7274f3d43d2a072cab25c0035dc994903bb9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/mfd/sprd-sc27xx-spi.c:59:23: warning: no previous prototype for
>> 'sprd_pmic_detect_charger_type' [-Wmissing-prototypes]
59 | enum usb_charger_type sprd_pmic_detect_charger_type(struct device *dev)
| ^
vim +/sprd_pmic_detect_charger_type +59 drivers/mfd/sprd-sc27xx-spi.c
58
> 59 enum usb_charger_type sprd_pmic_detect_charger_type(struct device *dev)
60 {
61 struct spi_device *spi = to_spi_device(dev);
62 struct sprd_pmic *ddata = spi_get_drvdata(spi);
63 const struct sprd_pmic_data *pdata = ddata->pdata;
64 enum usb_charger_type type;
65 u32 val;
66 int ret;
67
68 ret = regmap_read_poll_timeout(ddata->regmap,
pdata->charger_det, val,
69 (val & SPRD_PMIC_CHG_DET_DONE),
70 SPRD_PMIC_CHG_DET_DELAY_US,
71 SPRD_PMIC_CHG_DET_TIMEOUT);
72 if (ret) {
73 dev_err(&spi->dev, "failed to detect charger type\n");
74 return UNKNOWN_TYPE;
75 }
76
77 switch (val & SPRD_PMIC_CHG_TYPE_MASK) {
78 case SPRD_PMIC_CDP_TYPE:
79 type = CDP_TYPE;
80 break;
81 case SPRD_PMIC_DCP_TYPE:
82 type = DCP_TYPE;
83 break;
84 case SPRD_PMIC_SDP_TYPE:
85 type = SDP_TYPE;
86 break;
87 default:
88 type = UNKNOWN_TYPE;
89 break;
90 }
91
92 return type;
93 }
94 EXPORT_SYMBOL_GPL(sprd_pmic_detect_charger_type);
95
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 1/4] gpio: gpiolib: Allow GPIO IRQs to lazy disable
Hi,
On 5/25/2020 5:52 PM, Hans Verkuil wrote:
On 25/05/2020 13:55, Linus Walleij wrote:
On Sat, May 23, 2020 at 7:11 PM Maulik Shah wrote:
With 'commit 461c1a7d4733 ("gpiolib: override irq_enable/disable")' gpiolib
overrides irqchip's irq_enable and irq_disable callbacks. If irq_disable
callback is implemented then genirq takes unlazy path to disable irq.
Underlying irqchip may not want to implement irq_disable callback to lazy
disable irq when client drivers invokes disable_irq(). By overriding
irq_disable callback, gpiolib ends up always unlazy disabling IRQ.
Allow gpiolib to lazy disable IRQs by overriding irq_disable callback only
if irqchip implemented irq_disable. In cases where irq_disable is not
implemented irq_mask is overridden. Similarly override irq_enable callback
only if irqchip implemented irq_enable otherwise irq_unmask is overridden.
Fixes: 461c1a7d47 (gpiolib: override irq_enable/disable)
Signed-off-by: Maulik Shah
I definitely want Hans Verkuils test and review on this, since it
is a usecase that he is really dependent on.
Maulik, since I am no longer subscribed to linux-gpio, can you mail the
series to me?
I have two use-cases, but I can only test one (I don't have access to the
SBC I need to test the other use-case for the next few months).
Once I have the whole series I'll try to test the first use-case and at
least look into the code if this series could affect the second use-case.
Regards,
Hans
Hi Hans,
Mailed you the entire series.
Thanks,
Maulik
Also the irqchip people preferredly.
But it does seem to mop up my mistakes and fix this up properly!
So with some testing I'll be happy to merge it, even this one
patch separately if Hans can verify that it works.
Yours,
Linus Walleij
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of
Code Aurora Forum, hosted by The Linux Foundation
Re: linux-next: manual merge of the akpm-current tree with the tip tree
On Mon, 2020-05-25 at 21:04 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/x86/mm/tlb.c
>
> between commit:
>
> 83ce56f712af ("x86/mm: Refactor cond_ibpb() to support other use cases")
>
> from the tip tree and commit:
>
> 36c8e34d03a1 ("x86/mm: remove vmalloc faulting")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
The changes look reasonable to me (in terms of the merge resolution).
Acked-by: Balbir Singh
Re: [RFC PATCH V2 4/7] x86/hw_breakpoint: Prevent data breakpoints on user_pcid_flush_mask
On Mon, May 25, 2020 at 9:31 PM Lai Jiangshan wrote: > > On Tue, May 26, 2020 at 12:21 PM Andy Lutomirski wrote: > > > > On Mon, May 25, 2020 at 6:42 PM Lai Jiangshan > > wrote: > > > > > > The percpu user_pcid_flush_mask is used for CPU entry > > > If a data breakpoint on it, it will cause an unwanted #DB. > > > Protect the full cpu_tlbstate structure to be sure. > > > > > > There are some other percpu data used in CPU entry, but they are > > > either in already-protected cpu_tss_rw or are safe to trigger #DB > > > (espfix_waddr, espfix_stack). > > > > How hard would it be to rework this to have DECLARE_PERCPU_NODEBUG() > > and DEFINE_PERCPU_NODEBUG() or similar? > > > I don't know, but it is an excellent idea. Although the patchset > protects only 2 or 3 portions of percpu data, but there is many > percpu data used in tracing or kprobe code. They are needed to be > protected too. > > Adds CC: > Steven Rostedt > Masami Hiramatsu PeterZ is moving things in the direction of more aggressively disabling hardware breakpoints in the nasty paths where we won't survive a hardware breakpoint. Does the tracing code have portions that won't survive a limited amount of recursion? I'm hoping that we can keep the number of no-breakpoint-here percpu variables low. Maybe we could recruit objtool to help make sure we got all of them, but that would be a much larger project. Would we currently survive a breakpoint on the thread stack? I don't see any extremely obvious reason that we wouldn't. Blocking such a breakpoint would be annoying.
Re: linux-next: build failure after merge of the block tree
Hi all,
On Mon, 25 May 2020 13:03:44 -0600 Jens Axboe wrote:
>
> On 5/24/20 11:08 PM, Stephen Rothwell wrote:
> >
> > After merging the block tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > mm/filemap.c: In function 'generic_file_buffered_read':
> > mm/filemap.c:2075:9: error: 'written' undeclared (first use in this
> > function); did you mean 'writeb'?
> > 2075 | if (written) {
> > | ^~~
> > | writeb
> >
> > Caused by commit
> >
> > 23d513106fd8 ("mm: support async buffered reads in
> > generic_file_buffered_read()")
> >
> > from the block tree interacting with commit
> >
> > 6e66f10f2cac ("fs: export generic_file_buffered_read()")
> >
> > from the btrfs tree.
> >
> > [Aside: that btrfs tree commit talks about "correct the comments and
> > variable
> > names", but changes "written" to "copied" in the function definition
> > but to "already_read" in the header file declaration ...]
> >
> > I ave applied the following merge fix patch:
>
> Looks like a frivolous change... Thanks for fixing this up Stephen.
The variable name change has been removed from the btrfs tree.
--
Cheers,
Stephen Rothwell
pgpmwOAytud2n.pgp
Description: OpenPGP digital signature
[PATCH 0/2] x86/entry: simplify RESTORE_CR3
When I searched percpu data touched by entry code for #DB
protection[1], it seems to me RESTORE_CR3() does too much work,
this patchset simplifies it.
Patch 1 enhances 21e944591102("x86/mm: Optimize RESTORE_CR3") for
kernel CR3.
Patch 2 *reverts* 21e944591102("x86/mm: Optimize RESTORE_CR3") for
User CR3.
Cc: Andy Lutomirski
Cc: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
Cc: x...@kernel.org
Link:
https://lore.kernel.org/lkml/20200525145102.122557-1-la...@linux.alibaba.com
Lai Jiangshan (2):
x86/entry: Don't write to CR3 when restoring to kernel CR3
x86/entry: always flush user CR3 in RESTORE_CR3
arch/x86/entry/calling.h | 36
arch/x86/entry/entry_64.S | 6 +++---
2 files changed, 11 insertions(+), 31 deletions(-)
--
2.20.1
[PATCH 2/2] x86/entry: always flush user CR3 in RESTORE_CR3
RESTORE_CR3 is called when CPL==0 or #DF, it is unlikely CPL==0&cr3==userCR3 and #DF itself is unlikely case. There is no much overhead to always flush userCR3. Signed-off-by: Lai Jiangshan --- arch/x86/entry/calling.h | 27 ++- arch/x86/entry/entry_64.S | 6 +++--- 2 files changed, 9 insertions(+), 24 deletions(-) diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index 505246185624..ff26e4eb7063 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -265,33 +265,18 @@ For 32-bit we have the following conventions - kernel is built with .Ldone_\@: .endm -.macro RESTORE_CR3 scratch_reg:req save_reg:req +.macro RESTORE_CR3 save_reg:req ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI /* * Skip resuming KERNEL pages since it is already KERNEL CR3. +* +* RESTORE_CR3 is called when CPL==0 or #DF, it is unlikely +* CPL==0&cr3==userCR3 and #DF itself is unlikely case. +* There is no much overhead to always flush userCR3. */ bt $PTI_USER_PGTABLE_BIT, \save_reg jnc .Lend_\@ - - ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID - - /* -* Check if there's a pending flush for the user ASID we're -* about to set. -*/ - movq\save_reg, \scratch_reg - andq$(0x7FF), \scratch_reg - bt \scratch_reg, THIS_CPU_user_pcid_flush_mask - jnc .Lnoflush_\@ - - btr \scratch_reg, THIS_CPU_user_pcid_flush_mask - jmp .Lwrcr3_\@ - -.Lnoflush_\@: - SET_NOFLUSH_BIT \save_reg - -.Lwrcr3_\@: movq\save_reg, %cr3 .Lend_\@: .endm @@ -306,7 +291,7 @@ For 32-bit we have the following conventions - kernel is built with .endm .macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req .endm -.macro RESTORE_CR3 scratch_reg:req save_reg:req +.macro RESTORE_CR3 save_reg:req .endm #endif diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index d983a0d4bc73..46efa842a45e 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -1283,13 +1283,13 @@ SYM_CODE_START_LOCAL(paranoid_exit) jnz .Lparanoid_exit_no_swapgs TRACE_IRQS_IRETQ /* Always restore stashed CR3 value (see paranoid_entry) */ - RESTORE_CR3 scratch_reg=%rbx save_reg=%r14 + RESTORE_CR3 save_reg=%r14 SWAPGS_UNSAFE_STACK jmp restore_regs_and_return_to_kernel .Lparanoid_exit_no_swapgs: TRACE_IRQS_IRETQ_DEBUG /* Always restore stashed CR3 value (see paranoid_entry) */ - RESTORE_CR3 scratch_reg=%rbx save_reg=%r14 + RESTORE_CR3 save_reg=%r14 jmp restore_regs_and_return_to_kernel SYM_CODE_END(paranoid_exit) @@ -1703,7 +1703,7 @@ end_repeat_nmi: callexc_nmi /* Always restore stashed CR3 value (see paranoid_entry) */ - RESTORE_CR3 scratch_reg=%r15 save_reg=%r14 + RESTORE_CR3 save_reg=%r14 testl %ebx, %ebx /* swapgs needed? */ jnz nmi_restore -- 2.20.1
[PATCH 1/2] x86/entry: Don't write to CR3 when restoring to kernel CR3
Skip resuming KERNEL pages since it is already KERNEL CR3 Signed-off-by: Lai Jiangshan --- arch/x86/entry/calling.h | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index 1c7f13bb6728..505246185624 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -268,14 +268,13 @@ For 32-bit we have the following conventions - kernel is built with .macro RESTORE_CR3 scratch_reg:req save_reg:req ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI - ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID - /* -* KERNEL pages can always resume with NOFLUSH as we do -* explicit flushes. +* Skip resuming KERNEL pages since it is already KERNEL CR3. */ bt $PTI_USER_PGTABLE_BIT, \save_reg - jnc .Lnoflush_\@ + jnc .Lend_\@ + + ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID /* * Check if there's a pending flush for the user ASID we're @@ -293,10 +292,6 @@ For 32-bit we have the following conventions - kernel is built with SET_NOFLUSH_BIT \save_reg .Lwrcr3_\@: - /* -* The CR3 write could be avoided when not changing its value, -* but would require a CR3 read *and* a scratch register. -*/ movq\save_reg, %cr3 .Lend_\@: .endm -- 2.20.1
drivers/usb/cdns3/drd.c:43:31: sparse: expected void const volatile [noderef] *
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 9cb1fd0efd195590b828b9b865421ad345a4a145 commit: 70d8b9e5e63d212019ba3f6823c8ec3d2df87645 usb: cdns3: make signed 1 bit bitfields unsigned date: 9 weeks ago config: sh-randconfig-s032-20200526 (attached as .config) compiler: sh4-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-240-gf0fe1cd9-dirty git checkout 70d8b9e5e63d212019ba3f6823c8ec3d2df87645 # save the attached .config to linux build tree make W=1 C=1 ARCH=sh CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) ./arch/sh/include/generated/uapi/asm/unistd_32.h:411:37: sparse: sparse: no newline at end of file drivers/usb/cdns3/drd.c:43:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ >> drivers/usb/cdns3/drd.c:43:31: sparse:expected void const volatile >> [noderef] * drivers/usb/cdns3/drd.c:43:31: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:45:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:45:25: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:45:25: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:47:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:47:31: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:47:31: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:49:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:49:25: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:49:25: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:71:14: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:71:14: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:71:14: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:81:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:81:19: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:81:19: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:114:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:114:9: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:114:9: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:123:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:123:9: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:123:9: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:141:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:141:17: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:141:17: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:144:23: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:144:23: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:144:23: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:144:23: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:144:23: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:144:23: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:152:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@expected void const volatile [noderef] * @@got [noderef] * @@ drivers/usb/cdns3/drd.c:152:17: sparse:expected void const volatile [noderef] * drivers/usb/cdns3/drd.c:152:17: sparse:got restricted __le32 * drivers/usb/cdns3/drd.c:156:17: spar
Re: [patch V9 00/39] x86/entry: Rework leftovers (was part V)
On Thu, May 21, 2020 at 1:31 PM Thomas Gleixner wrote: > > Folks! > > This is V9 of the rework series. V7 and V8 were never posted but I used the > version numbers for tags while fixing up 0day complaints. The last posted > version was V6 which can be found here: The whole pile is Acked-by: Andy Lutomirski Go test on Linus' new AMD laptop! --Andy
drivers/spi/spi-meson-spicc.c:363:6: warning: variable 'data' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 9cb1fd0efd195590b828b9b865421ad345a4a145
commit: 0eb707ac7dd7a4329d93d47feada6c9bb5ea8ee9 spi: meson-spicc: adapt burst
handling for G12A support
date: 2 months ago
config: h8300-randconfig-r006-20200526 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0eb707ac7dd7a4329d93d47feada6c9bb5ea8ee9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/spi/spi-meson-spicc.c: In function 'meson_spicc_reset_fifo':
>> drivers/spi/spi-meson-spicc.c:363:6: warning: variable 'data' set but not
>> used [-Wunused-but-set-variable]
363 | u32 data;
| ^~~~
vim +/data +363 drivers/spi/spi-meson-spicc.c
360
361 static void meson_spicc_reset_fifo(struct meson_spicc_device *spicc)
362 {
> 363 u32 data;
364
365 if (spicc->data->has_oen)
366 writel_bits_relaxed(SPICC_ENH_MAIN_CLK_AO,
367 SPICC_ENH_MAIN_CLK_AO,
368 spicc->base + SPICC_ENH_CTL0);
369
370 writel_bits_relaxed(SPICC_FIFORST_W1_MASK,
SPICC_FIFORST_W1_MASK,
371 spicc->base + SPICC_TESTREG);
372
373 while (meson_spicc_rxready(spicc))
374 data = readl_relaxed(spicc->base + SPICC_RXDATA);
375
376 if (spicc->data->has_oen)
377 writel_bits_relaxed(SPICC_ENH_MAIN_CLK_AO, 0,
378 spicc->base + SPICC_ENH_CTL0);
379 }
380
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [RFC PATCH V2 4/7] x86/hw_breakpoint: Prevent data breakpoints on user_pcid_flush_mask
On Tue, May 26, 2020 at 12:21 PM Andy Lutomirski wrote: > > On Mon, May 25, 2020 at 6:42 PM Lai Jiangshan wrote: > > > > The percpu user_pcid_flush_mask is used for CPU entry > > If a data breakpoint on it, it will cause an unwanted #DB. > > Protect the full cpu_tlbstate structure to be sure. > > > > There are some other percpu data used in CPU entry, but they are > > either in already-protected cpu_tss_rw or are safe to trigger #DB > > (espfix_waddr, espfix_stack). > > How hard would it be to rework this to have DECLARE_PERCPU_NODEBUG() > and DEFINE_PERCPU_NODEBUG() or similar? I don't know, but it is an excellent idea. Although the patchset protects only 2 or 3 portions of percpu data, but there is many percpu data used in tracing or kprobe code. They are needed to be protected too. Adds CC: Steven Rostedt Masami Hiramatsu
Re: mmotm 2020-05-25-16-56 uploaded (drm/nouveau)
On 5/25/20 9:23 PM, Dave Airlie wrote: > On Tue, 26 May 2020 at 13:50, Randy Dunlap wrote: >> >> On 5/25/20 4:57 PM, Andrew Morton wrote: >>> The mm-of-the-moment snapshot 2020-05-25-16-56 has been uploaded to >>> >>>http://www.ozlabs.org/~akpm/mmotm/ >>> >>> mmotm-readme.txt says >>> >>> README for mm-of-the-moment: >>> >>> http://www.ozlabs.org/~akpm/mmotm/ >>> >>> This is a snapshot of my -mm patch queue. Uploaded at random hopefully >>> more than once a week. >>> >>> You will need quilt to apply these patches to the latest Linus release (5.x >>> or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in >>> http://ozlabs.org/~akpm/mmotm/series >>> >>> The file broken-out.tar.gz contains two datestamp files: .DATE and >>> .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, >>> followed by the base kernel version against which this patch series is to >>> be applied. >>> >> >> on x86_64: >> >> when CONFIG_DRM_NOUVEAU=y and CONFIG_FB=m: >> >> ld: drivers/gpu/drm/nouveau/nouveau_drm.o: in function `nouveau_drm_probe': >> nouveau_drm.c:(.text+0x1d67): undefined reference to >> `remove_conflicting_pci_framebuffers' > > I've pushed the fix for this to drm-next. > > Ben just used the wrong API. That patch is Acked-by: Randy Dunlap # build-tested thanks. -- ~Randy
[PATCH 1/1] nvme-fcloop: verify wwnn and wwpn format
The nvme host and target verify the wwnn and wwpn format via
nvme_fc_parse_traddr(). For instance, it is required that the length of
wwnn to be either 21 ("nn-0x") or 19 (nn-).
Add this verification to nvme-fcloop so that the input should always be in
hex and the length of input should always be 18.
Otherwise, the user may use e.g. 0x2 to create fcloop local port, while
0x0002 is required for nvme host and target. This makes the
requirement of format confusing.
Signed-off-by: Dongli Zhang
---
drivers/nvme/target/fcloop.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/nvme/target/fcloop.c b/drivers/nvme/target/fcloop.c
index f69ce66e2d44..14124e6d4bf2 100644
--- a/drivers/nvme/target/fcloop.c
+++ b/drivers/nvme/target/fcloop.c
@@ -43,6 +43,17 @@ static const match_table_t opt_tokens = {
{ NVMF_OPT_ERR, NULL}
};
+static int fcloop_verify_addr(substring_t *s)
+{
+ size_t blen = s->to - s->from + 1;
+
+ if (strnlen(s->from, blen) != NVME_FC_TRADDR_HEXNAMELEN + 2 ||
+ strncmp(s->from, "0x", 2))
+ return -EINVAL;
+
+ return 0;
+}
+
static int
fcloop_parse_options(struct fcloop_ctrl_options *opts,
const char *buf)
@@ -64,14 +75,16 @@ fcloop_parse_options(struct fcloop_ctrl_options *opts,
opts->mask |= token;
switch (token) {
case NVMF_OPT_WWNN:
- if (match_u64(args, &token64)) {
+ if (fcloop_verify_addr(args) ||
+ match_u64(args, &token64)) {
ret = -EINVAL;
goto out_free_options;
}
opts->wwnn = token64;
break;
case NVMF_OPT_WWPN:
- if (match_u64(args, &token64)) {
+ if (fcloop_verify_addr(args) ||
+ match_u64(args, &token64)) {
ret = -EINVAL;
goto out_free_options;
}
@@ -92,14 +105,16 @@ fcloop_parse_options(struct fcloop_ctrl_options *opts,
opts->fcaddr = token;
break;
case NVMF_OPT_LPWWNN:
- if (match_u64(args, &token64)) {
+ if (fcloop_verify_addr(args) ||
+ match_u64(args, &token64)) {
ret = -EINVAL;
goto out_free_options;
}
opts->lpwwnn = token64;
break;
case NVMF_OPT_LPWWPN:
- if (match_u64(args, &token64)) {
+ if (fcloop_verify_addr(args) ||
+ match_u64(args, &token64)) {
ret = -EINVAL;
goto out_free_options;
}
@@ -141,14 +156,16 @@ fcloop_parse_nm_options(struct device *dev, u64 *nname,
u64 *pname,
token = match_token(p, opt_tokens, args);
switch (token) {
case NVMF_OPT_WWNN:
- if (match_u64(args, &token64)) {
+ if (fcloop_verify_addr(args) ||
+ match_u64(args, &token64)) {
ret = -EINVAL;
goto out_free_options;
}
*nname = token64;
break;
case NVMF_OPT_WWPN:
- if (match_u64(args, &token64)) {
+ if (fcloop_verify_addr(args) ||
+ match_u64(args, &token64)) {
ret = -EINVAL;
goto out_free_options;
}
--
2.17.1
Re: mmotm 2020-05-25-16-56 uploaded (drm/nouveau)
On Tue, 26 May 2020 at 13:50, Randy Dunlap wrote: > > On 5/25/20 4:57 PM, Andrew Morton wrote: > > The mm-of-the-moment snapshot 2020-05-25-16-56 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > more than once a week. > > > > You will need quilt to apply these patches to the latest Linus release (5.x > > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > > http://ozlabs.org/~akpm/mmotm/series > > > > The file broken-out.tar.gz contains two datestamp files: .DATE and > > .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, > > followed by the base kernel version against which this patch series is to > > be applied. > > > > on x86_64: > > when CONFIG_DRM_NOUVEAU=y and CONFIG_FB=m: > > ld: drivers/gpu/drm/nouveau/nouveau_drm.o: in function `nouveau_drm_probe': > nouveau_drm.c:(.text+0x1d67): undefined reference to > `remove_conflicting_pci_framebuffers' I've pushed the fix for this to drm-next. Ben just used the wrong API. Dave.
Re: [RFC PATCH V2 4/7] x86/hw_breakpoint: Prevent data breakpoints on user_pcid_flush_mask
On Mon, May 25, 2020 at 6:42 PM Lai Jiangshan wrote: > > The percpu user_pcid_flush_mask is used for CPU entry > If a data breakpoint on it, it will cause an unwanted #DB. > Protect the full cpu_tlbstate structure to be sure. > > There are some other percpu data used in CPU entry, but they are > either in already-protected cpu_tss_rw or are safe to trigger #DB > (espfix_waddr, espfix_stack). How hard would it be to rework this to have DECLARE_PERCPU_NODEBUG() and DEFINE_PERCPU_NODEBUG() or similar?
Re: [PATCH] Input: elantech - Remove read/write registers in attr.
Hi Jingle, On Tue, May 26, 2020 at 10:22:46AM +0800, Jingle.Wu wrote: > New Elan IC would not be accessed with the specific regiters. What about older Elaan parts? We can't simply drop compatibility with older chips in newer kernels. Thanks. -- Dmitry
Re: inux-next: build failure after merge of the drm-msm tree
Hi all,
On Tue, 19 May 2020 15:09:55 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-msm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
>
> Caused by commit
>
> 04d9044f6c57 ("drm/msm/dpu: add support for clk and bw scaling for display")
>
> I applied the following patch for today (this is mechanical, there may
> be a better way):
>
> From: Stephen Rothwell
> Date: Tue, 19 May 2020 14:12:39 +1000
> Subject: [PATCH] drm/msm/dpu: fix up u64/u32 division for 32 bit architectures
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 23 ++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15
> 2 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index 9697abcbec3f..85c2a4190840 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dpu_kms.h"
> #include "dpu_trace.h"
> @@ -53,8 +54,11 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
> }
>
> bw_factor = kms->catalog->perf.bw_inefficiency_factor;
> - if (bw_factor)
> - crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
> + if (bw_factor) {
> + u64 quot = crtc_plane_bw;
> + u32 rem = do_div(quot, 100);
> + crtc_plane_bw = (quot * bw_factor) + ((rem * bw_factor) / 100);
> + }
>
> return crtc_plane_bw;
> }
> @@ -89,8 +93,11 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
> }
>
> clk_factor = kms->catalog->perf.clk_inefficiency_factor;
> - if (clk_factor)
> - crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
> + if (clk_factor) {
> + u64 quot = crtc_clk;
> + u32 rem = do_div(quot, 100);
> + crtc_clk = (quot * clk_factor) + ((rem * clk_factor) / 100);
> + }
>
> return crtc_clk;
> }
> @@ -234,8 +241,12 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms
> *kms,
> }
> }
>
> - avg_bw = kms->num_paths ?
> - perf.bw_ctl / kms->num_paths : 0;
> + if (kms->num_paths) {
> + avg_bw = perf.bw_ctl;
> + do_div(avg_bw, kms->num_paths);
> + } else {
> + avg_bw = 0;
> + }
>
> for (i = 0; i < kms->num_paths; i++)
> icc_set_bw(kms->path[i],
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index c2a6e3dacd68..ad95f32eac13 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -174,7 +175,11 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
> plane_prefill_bw =
> src_width * hw_latency_lines * fps * fmt->bpp * scale_factor;
>
> - plane_prefill_bw = mult_frac(plane_prefill_bw, mode->vtotal, (vbp+vpw));
> + {
> + u64 quot = plane_prefill_bw;
> + u32 rem = do_div(plane_prefill_bw, vbp + vpw);
> + plane_prefill_bw = quot * mode->vtotal + rem * mode->vtotal /
> (vbp + vpw);
> + }
>
> pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
> }
> @@ -204,9 +209,11 @@ static void _dpu_plane_calc_clk(struct drm_plane *plane)
> pstate->plane_clk =
> dst_width * mode->vtotal * fps;
>
> - if (src_height > dst_height)
> - pstate->plane_clk = mult_frac(pstate->plane_clk,
> - src_height, dst_height);
> + if (src_height > dst_height) {
> + u64 quot = pstate->plane_clk;
> + u32 rem = do_div(quot, dst_height);
> + pstate->plane_clk = quot * src_height + rem * src_height /
> dst_height;
> + }
> }
>
> /**
> --
> 2.26.2
I am still applying the above ...
--
Cheers,
Stephen Rothwell
pgpEs4IDl0HRd.pgp
Description: OpenPGP digital signature
WARNING: suspicious RCU usage in idtentry_exit
Hello, syzbot found the following crash on: HEAD commit:7b4cb0a4 Add linux-next specific files for 20200525 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1335601610 kernel config: https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10 dashboard link: https://syzkaller.appspot.com/bug?extid=3ae5eaae0809ee311e75 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+3ae5eaae0809ee311...@syzkaller.appspotmail.com = WARNING: suspicious RCU usage 5.7.0-rc7-next-20200525-syzkaller #0 Not tainted - kernel/rcu/tree.c:715 RCU dynticks_nesting counter underflow/zero!! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 2, debug_locks = 1 RCU used illegally from extended quiescent state! no locks held by syz-executor.5/24641. stack backtrace: CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 rcu_irq_exit_preempt+0x1fa/0x250 kernel/rcu/tree.c:715 idtentry_exit+0x9e/0xc0 arch/x86/entry/common.c:583 exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506 asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353 RIP: 0010:kvm_fastop_exception+0xb68/0xfe8 Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31 RSP: 0018:c90004a87a30 EFLAGS: 00010212 RAX: 0004 RBX: 88809cca4080 RCX: 0122 RDX: 63ff RSI: c90004a87a98 RDI: 0122 RBP: 0122 R08: 888058486480 R09: fbfff131f481 R10: 898fa403 R11: fbfff131f480 R12: 0122 R13: 0078 R14: 0006 R15: 88244b5c paravirt_read_msr_safe arch/x86/include/asm/paravirt.h:178 [inline] vmx_create_vcpu+0x184/0x2b40 arch/x86/kvm/vmx/vmx.c:6827 kvm_arch_vcpu_create+0x6a8/0xb30 arch/x86/kvm/x86.c:9427 kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3043 [inline] kvm_vm_ioctl+0x15b7/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603 vfs_ioctl fs/ioctl.c:48 [inline] ksys_ioctl+0x11a/0x180 fs/ioctl.c:753 __do_sys_ioctl fs/ioctl.c:762 [inline] __se_sys_ioctl fs/ioctl.c:760 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:353 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45ca29 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f2c93b11c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 004e73c0 RCX: 0045ca29 RDX: RSI: ae41 RDI: 0004 RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: R13: 0396 R14: 004c62c6 R15: 7f2c93b126d4 = WARNING: suspicious RCU usage 5.7.0-rc7-next-20200525-syzkaller #0 Not tainted - kernel/rcu/tree.c:717 RCU in extended quiescent state!! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 2, debug_locks = 1 RCU used illegally from extended quiescent state! no locks held by syz-executor.5/24641. stack backtrace: CPU: 1 PID: 24641 Comm: syz-executor.5 Not tainted 5.7.0-rc7-next-20200525-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 idtentry_exit+0x9e/0xc0 arch/x86/entry/common.c:583 exc_general_protection+0x23d/0x520 arch/x86/kernel/traps.c:506 asm_exc_general_protection+0x1e/0x30 arch/x86/include/asm/idtentry.h:353 RIP: 0010:kvm_fastop_exception+0xb68/0xfe8 Code: f2 ff ff ff 48 31 db e9 fb c9 2a f9 b8 f2 ff ff ff 48 31 f6 e9 ff c9 2a f9 31 c0 e9 ec 2c 2b f9 b8 fb ff ff ff e9 13 a9 31 f9 fb ff ff ff 31 c0 31 d2 e9 33 a9 31 f9 31 db e9 2a 0b 42 f9 31 RSP: 0018:c90004a87a30 EFLAGS: 00010212 RAX: 0004 RBX: 88809cca4080 RCX: 0122 RDX: 63ff RSI: c90004a87a98 RDI: 0122 RBP: 0122 R08: 888058486480 R09: fbfff131f481 R10: 898fa403 R11: fbfff131f480 R12: 0122 R13: 0078 R14: 0006 R15: 88244b5c paravirt_re
drivers/soc/fsl/dpio/qbman-portal.c:661:11: warning: variable 'addr_cena' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 9cb1fd0efd195590b828b9b865421ad345a4a145
commit: 3b2abda7d28c69f564c1157b9b9c21ef40092ee9 soc: fsl: dpio: Replace QMAN
array mode with ring mode enqueue
date: 3 months ago
config: i386-randconfig-r004-20200526 (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
git checkout 3b2abda7d28c69f564c1157b9b9c21ef40092ee9
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/soc/fsl/dpio/qbman-portal.c: In function
'qbman_swp_enqueue_multiple_direct':
>> drivers/soc/fsl/dpio/qbman-portal.c:661:11: warning: variable 'addr_cena'
>> set but not used [-Wunused-but-set-variable]
uint64_t addr_cena;
^
drivers/soc/fsl/dpio/qbman-portal.c: In function
'qbman_swp_enqueue_multiple_desc_direct':
drivers/soc/fsl/dpio/qbman-portal.c:869:14: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
addr_cena = (uint64_t)s->addr_cena;
^
drivers/soc/fsl/dpio/qbman-portal.c:825:11: warning: variable 'addr_cena' set
but not used [-Wunused-but-set-variable]
uint64_t addr_cena;
^
vim +/addr_cena +661 drivers/soc/fsl/dpio/qbman-portal.c
638
639 /**
640 * qbman_swp_enqueue_multiple_direct() - Issue a multi enqueue command
641 * using one enqueue descriptor
642 * @s: the software portal used for enqueue
643 * @d: the enqueue descriptor
644 * @fd: table pointer of frame descriptor table to be enqueued
645 * @flags: table pointer of QBMAN_ENQUEUE_FLAG_DCA flags, not used if
NULL
646 * @num_frames: number of fd to be enqueued
647 *
648 * Return the number of fd enqueued, or a negative error number.
649 */
650 static
651 int qbman_swp_enqueue_multiple_direct(struct qbman_swp *s,
652const struct qbman_eq_desc *d,
653const struct dpaa2_fd *fd,
654uint32_t *flags,
655int num_frames)
656 {
657 uint32_t *p = NULL;
658 const uint32_t *cl = (uint32_t *)d;
659 uint32_t eqcr_ci, eqcr_pi, half_mask, full_mask;
660 int i, num_enqueued = 0;
> 661 uint64_t addr_cena;
662
663 spin_lock(&s->access_spinlock);
664 half_mask = (s->eqcr.pi_ci_mask>>1);
665 full_mask = s->eqcr.pi_ci_mask;
666
667 if (!s->eqcr.available) {
668 eqcr_ci = s->eqcr.ci;
669 p = s->addr_cena + QBMAN_CENA_SWP_EQCR_CI;
670 s->eqcr.ci = qbman_read_register(s,
QBMAN_CINH_SWP_EQCR_CI);
671
672 s->eqcr.available = qm_cyc_diff(s->eqcr.pi_ring_size,
673 eqcr_ci, s->eqcr.ci);
674 if (!s->eqcr.available) {
675 spin_unlock(&s->access_spinlock);
676 return 0;
677 }
678 }
679
680 eqcr_pi = s->eqcr.pi;
681 num_enqueued = (s->eqcr.available < num_frames) ?
682 s->eqcr.available : num_frames;
683 s->eqcr.available -= num_enqueued;
684 /* Fill in the EQCR ring */
685 for (i = 0; i < num_enqueued; i++) {
686 p = (s->addr_cena + QBMAN_CENA_SWP_EQCR(eqcr_pi &
half_mask));
687 /* Skip copying the verb */
688 memcpy(&p[1], &cl[1], EQ_DESC_SIZE_WITHOUT_FD - 1);
689 memcpy(&p[EQ_DESC_SIZE_FD_START/sizeof(uint32_t)],
690 &fd[i], sizeof(*fd));
691 eqcr_pi++;
692 }
693
694 dma_wmb();
695
696 /* Set the verb byte, have to substitute in the valid-bit */
697 eqcr_pi = s->eqcr.pi;
698 for (i = 0; i < num_enqueued; i++) {
699 p = (s->addr_cena + QBMAN_CENA_SWP_EQCR(eqcr_pi &
half_mask));
700 p[0] = cl[0] | s->eqcr.pi_vb;
701 if (flags && (flags[i] & QBMAN_ENQUEUE_FLAG_DCA)) {
702 struct qbman_eq_desc *d = (struct qbman_eq_desc
*)p;
703
704 d->dca = (1 << QB_ENQUEUE_CMD_DCA_EN_SHIFT) |
705 ((flags[i]) & QBMAN_EQCR_DCA_IDXMASK);
706 }
707 eqcr_pi++;
708 if (!(eqcr_pi & half_mask))
709 s->eqcr.pi_vb ^= QB_VALID_BIT;
710 }
711
712 /* Flush all the cacheline without load/store in between
general protection fault in tomoyo_check_acl
Hello, syzbot found the following crash on: HEAD commit:d2f8825a Merge tag 'for_linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13c5592210 kernel config: https://syzkaller.appspot.com/x/.config?x=b3368ce0cc5f5ace dashboard link: https://syzkaller.appspot.com/bug?extid=cff8c4c75acd8c6fb842 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+cff8c4c75acd8c6fb...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xe2666003: [#1] PREEMPT SMP KASAN KASAN: probably user-memory-access in range [0x0018-0x001f] CPU: 0 PID: 12489 Comm: systemd-rfkill Not tainted 5.7.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tomoyo_check_acl+0xa9/0x3e0 security/tomoyo/domain.c:173 Code: 00 0f 85 2d 03 00 00 49 8b 1c 24 49 39 dc 0f 84 bd 01 00 00 e8 28 65 14 fe 48 8d 7b 18 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <0f> b6 04 28 38 d0 7f 08 84 c0 0f 85 a7 02 00 00 44 0f b6 73 18 31 RSP: 0018:c90016987bc8 EFLAGS: 00010246 RAX: 0003 RBX: RCX: 835ed028 RDX: RSI: 835ecff8 RDI: 0018 RBP: dc00 R08: 8880a1cce1c0 R09: R10: R11: R12: 8880a72db990 R13: c90016987c80 R14: 0033 R15: 0002 FS: 7f9e4b6ba8c0() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f9e4b399e30 CR3: 4df8d000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: tomoyo_path_number_perm+0x314/0x4d0 security/tomoyo/file.c:733 security_file_ioctl+0x6c/0xb0 security/security.c:1460 ksys_ioctl+0x50/0x180 fs/ioctl.c:765 __do_sys_ioctl fs/ioctl.c:780 [inline] __se_sys_ioctl fs/ioctl.c:778 [inline] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:778 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x7f9e4adab80a Code: ff e9 62 fe ff ff 66 2e 0f 1f 84 00 00 00 00 00 53 49 89 f0 48 63 ff be 01 54 00 00 b8 10 00 00 00 48 83 ec 30 48 89 e2 0f 05 <48> 3d 00 f0 ff ff 77 6e 85 c0 89 c3 75 5c 8b 04 24 8b 54 24 0c 4c RSP: 002b:7fffcc16ea20 EFLAGS: 0202 ORIG_RAX: 0010 RAX: ffda RBX: 0007 RCX: 7f9e4adab80a RDX: 7fffcc16ea20 RSI: 5401 RDI: 0002 RBP: 0007 R08: 7fffcc16ea60 R09: R10: 00020d50 R11: 0202 R12: 56153471ef90 R13: 7fffcc16ec30 R14: R15: Modules linked in: ---[ end trace 1f05c0d7f6671379 ]--- RIP: 0010:tomoyo_check_acl+0xa9/0x3e0 security/tomoyo/domain.c:173 Code: 00 0f 85 2d 03 00 00 49 8b 1c 24 49 39 dc 0f 84 bd 01 00 00 e8 28 65 14 fe 48 8d 7b 18 48 89 f8 48 89 fa 48 c1 e8 03 83 e2 07 <0f> b6 04 28 38 d0 7f 08 84 c0 0f 85 a7 02 00 00 44 0f b6 73 18 31 RSP: 0018:c90016987bc8 EFLAGS: 00010246 RAX: 0003 RBX: RCX: 835ed028 RDX: RSI: 835ecff8 RDI: 0018 RBP: dc00 R08: 8880a1cce1c0 R09: R10: R11: R12: 8880a72db990 R13: c90016987c80 R14: 0033 R15: 0002 FS: 7f9e4b6ba8c0() GS:8880ae60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55f7b8031310 CR3: 4df8d000 CR4: 001426f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH v1] Bluetooth: hci_qca: Improve controller ID info log level
Controller ID info got by VSC EDL_PATCH_GETVER is very
important, so improve its log level from DEBUG to INFO.
Signed-off-by: Zijun Hu
---
drivers/bluetooth/btqca.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index 3ea866d..49e5aeb 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -74,10 +74,10 @@ int qca_read_soc_version(struct hci_dev *hdev, u32
*soc_version,
ver = (struct qca_btsoc_version *)(edl->data);
- BT_DBG("%s: Product:0x%08x", hdev->name, le32_to_cpu(ver->product_id));
- BT_DBG("%s: Patch :0x%08x", hdev->name, le16_to_cpu(ver->patch_ver));
- BT_DBG("%s: ROM:0x%08x", hdev->name, le16_to_cpu(ver->rom_ver));
- BT_DBG("%s: SOC:0x%08x", hdev->name, le32_to_cpu(ver->soc_id));
+ bt_dev_info(hdev, "QCA Product:0x%08x", le32_to_cpu(ver->product_id));
+ bt_dev_info(hdev, "QCA Patch :0x%08x", le16_to_cpu(ver->patch_ver));
+ bt_dev_info(hdev, "QCA ROM:0x%08x", le16_to_cpu(ver->rom_ver));
+ bt_dev_info(hdev, "QCA SOC:0x%08x", le32_to_cpu(ver->soc_id));
/* QCA chipset version can be decided by patch and SoC
* version, combination with upper 2 bytes from SoC
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: [PATCH v2] relay: handle alloc_percpu returning NULL in relay_open
[ + akpm ]
Daniel Axtens writes:
>>> > Check if alloc_percpu returns NULL.
>>> >
>>> > This was found by syzkaller both on x86 and powerpc, and the reproducer
>>> > it found on powerpc is capable of hitting the issue as an unprivileged
>>> > user.
>>> >
>>> > Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel
>>> > buffer pointers")
>>> > Reported-by: syzbot+1e925b4b836afe85a...@syzkaller-ppc64.appspotmail.com
>>> > Reported-by: syzbot+587b2421926808309...@syzkaller-ppc64.appspotmail.com
>>> > Reported-by: syzbot+58320b7171734bf79...@syzkaller.appspotmail.com
>>> > Reported-by: syzbot+d6074fb08bdb2e010...@syzkaller.appspotmail.com
>>> > Cc: Akash Goel
>>> > Cc: Andrew Donnellan # syzkaller-ppc64
>>> > Reviewed-by: Michael Ellerman
>>> > Reviewed-by: Andrew Donnellan
>>> > Cc: sta...@vger.kernel.org # v4.10+
>>> > Signed-off-by: Daniel Axtens
>>>
>>> Acked-by: David Rientjes
>>
>> It looks this one was never applied (which relates to CVE-2019-19462,
>> as pointed by Guenter in 20191223163610.ga32...@roeck-us.net).
>>
>> Whas this lost or are there any issues pending?
>
> I'm not aware of any pending issues.
>
> (But, if anyone does have any objections I'm happy to revise the patch.)
It looks like kernel/relay.c is lacking a maintainer?
Andrew are you able to pick this up for v5.8? It's pretty obviously
correct, and has David's ack.
Original is here if that helps:
https://lore.kernel.org/lkml/20191219121256.26480-1-...@axtens.net/
cheers
[PATCH] drm/msm/a6xx: set ubwc config for A640 and A650
This is required for A640 and A650 to be able to share UBWC-compressed
images with other HW such as display, which expect this configuration.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 ++-
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 6f335ae179c8..aa004a261277 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -289,6 +289,37 @@ static void a6xx_set_hwcg(struct msm_gpu *gpu, bool state)
gpu_write(gpu, REG_A6XX_RBBM_CLOCK_CNTL, state ? 0x8aa8aa02 : 0);
}
+static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ u32 lower_bit = 2;
+ u32 amsbc = 0;
+ u32 rgb565_predicator = 0;
+ u32 uavflagprd_inv = 0;
+
+ /* a618 is using the hw default values */
+ if (adreno_is_a618(adreno_gpu))
+ return;
+
+ if (adreno_is_a640(adreno_gpu))
+ amsbc = 1;
+
+ if (adreno_is_a650(adreno_gpu)) {
+ /* TODO: get ddr type from bootloader and use 2 for LPDDR4 */
+ lower_bit = 3;
+ amsbc = 1;
+ rgb565_predicator = 1;
+ uavflagprd_inv = 2;
+ }
+
+ gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL,
+ rgb565_predicator << 11 | amsbc << 4 | lower_bit << 1);
+ gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, lower_bit << 1);
+ gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL,
+ uavflagprd_inv >> 4 | lower_bit << 1);
+ gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, lower_bit << 21);
+}
+
static int a6xx_cp_init(struct msm_gpu *gpu)
{
struct msm_ringbuffer *ring = gpu->rb[0];
@@ -478,12 +509,7 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
/* Select CP0 to always count cycles */
gpu_write(gpu, REG_A6XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
- if (adreno_is_a630(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
- }
+ a6xx_set_ubwc_config(gpu);
/* Enable fault detection */
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL,
--
2.26.1
[PATCH 6/8] drm/msm/dpu: intf timing path for displayport
Calculate the correct timings for displayport, from downstream driver.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 64f556d693dd..6f0f54588124 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -107,11 +107,6 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
display_v_end = ((vsync_period - p->v_front_porch) * hsync_period) +
p->hsync_skew - 1;
- if (ctx->cap->type == INTF_EDP || ctx->cap->type == INTF_DP) {
- display_v_start += p->hsync_pulse_width + p->h_back_porch;
- display_v_end -= p->h_front_porch;
- }
-
hsync_start_x = p->h_back_porch + p->hsync_pulse_width;
hsync_end_x = hsync_period - p->h_front_porch - 1;
@@ -144,10 +139,25 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
hsync_ctl = (hsync_period << 16) | p->hsync_pulse_width;
display_hctl = (hsync_end_x << 16) | hsync_start_x;
+ if (ctx->cap->type == INTF_EDP || ctx->cap->type == INTF_DP) {
+ active_h_start = hsync_start_x;
+ active_h_end = active_h_start + p->xres - 1;
+ active_v_start = display_v_start;
+ active_v_end = active_v_start + (p->yres * hsync_period) - 1;
+
+ display_v_start += p->hsync_pulse_width + p->h_back_porch;
+
+ active_hctl = (active_h_end << 16) | active_h_start;
+ display_hctl = active_hctl;
+ }
+
den_polarity = 0;
if (ctx->cap->type == INTF_HDMI) {
hsync_polarity = p->yres >= 720 ? 0 : 1;
vsync_polarity = p->yres >= 720 ? 0 : 1;
+ } else if (ctx->cap->type == INTF_DP) {
+ hsync_polarity = p->hsync_polarity;
+ vsync_polarity = p->vsync_polarity;
} else {
hsync_polarity = 0;
vsync_polarity = 0;
--
2.26.1
[PATCH 4/8] drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845
The INTF_INPUT_CTRL feature is not available on sdm845, so don't set it.
This also adds separate feature bits for INTF (based on downstream) instead
of using CTL feature bit for it, and removes the unnecessary NULL check in
the added bind_pingpong_blk function.
Fixes: 73bfb790ac786ca55fa2786a06f59 ("msm:disp:dpu1: setup display datapath
for SC7180 target")
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 20 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 13
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 9 ++---
3 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 496407f1cd08..1e64fa08c219 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -41,6 +41,10 @@
#define PINGPONG_SDM845_SPLIT_MASK \
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
+#define INTF_SDM845_MASK (0)
+
+#define INTF_SC7180_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE)
+
#define DEFAULT_PIXEL_RAM_SIZE (50 * 1024)
#define DEFAULT_DPU_LINE_WIDTH 2048
#define DEFAULT_DPU_OUTPUT_LINE_WIDTH 2560
@@ -376,26 +380,26 @@ static struct dpu_pingpong_cfg sc7180_pp[] = {
/*
* INTF sub blocks config
*/
-#define INTF_BLK(_name, _id, _base, _type, _ctrl_id) \
+#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _features) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0x280, \
- .features = BIT(DPU_CTL_ACTIVE_CFG), \
+ .features = _features, \
.type = _type, \
.controller_id = _ctrl_id, \
.prog_fetch_lines_worst_case = 24 \
}
static const struct dpu_intf_cfg sdm845_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0),
- INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1),
- INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SDM845_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SDM845_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SDM845_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SDM845_MASK),
};
static const struct dpu_intf_cfg sc7180_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
};
/*
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 7a8d1c6658d2..31ddb2be9c57 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -175,6 +175,19 @@ enum {
DPU_CTL_MAX
};
+/**
+ * INTF sub-blocks
+ * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
+ * pixel data arrives to this INTF
+ * @DPU_INTF_TE INTF block has TE configuration support
+ * @DPU_INTF_MAX
+ */
+enum {
+ DPU_INTF_INPUT_CTRL = 0x1,
+ DPU_INTF_TE,
+ DPU_INTF_MAX
+};
+
/**
* VBIF sub-blocks and features
* @DPU_VBIF_QOS_OTLIMVBIF supports OT Limit
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index efe9a5719c6b..64f556d693dd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -225,14 +225,9 @@ static void dpu_hw_intf_bind_pingpong_blk(
bool enable,
const enum dpu_pingpong pp)
{
- struct dpu_hw_blk_reg_map *c;
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
u32 mux_cfg;
- if (!intf)
- return;
-
- c = &intf->hw;
-
mux_cfg = DPU_REG_READ(c, INTF_MUX);
mux_cfg &= ~0xf;
@@ -280,7 +275,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->get_status = dpu_hw_intf_get_status;
ops->enable_timing = dpu_hw_intf_enable_timing_engine;
ops->get_line_count = dpu_hw_intf_get_line_count;
- if (cap & BIT(DPU_CTL_ACTIVE_CFG))
+ if (cap & BIT(DPU_INTF_INPUT_CTRL))
ops->bind_pingpong_blk = dpu_hw_intf_bind_pingpong_blk;
}
--
2.26.1
[PATCH 7/8] drm/msm/dpu: add SM8150 to hw catalog
This brings up basic video mode functionality for SM8150 DPU. Command mode
and dual mixer/intf configurations are not working, future patches will
address this. Scaler functionality and multiple planes is also untested.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 147 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +
2 files changed, 149 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 1e64fa08c219..f99622870676 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -90,6 +90,23 @@ static const struct dpu_caps sc7180_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_caps sm8150_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .max_linewidth = 4096,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2_5,
+ .ubwc_version = DPU_HW_UBWC_VER_30,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 4096,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .max_hdeci_exp = MAX_HORZ_DECIMATION,
+ .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -181,6 +198,39 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
},
};
+static const struct dpu_ctl_cfg sm8150_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_SPLIT_DISPLAY)
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x1200, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG) | BIT(DPU_CTL_SPLIT_DISPLAY)
+ },
+ {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x1400, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+ {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x1600, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+ {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x1800, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+ {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a00, .len = 0x1e0,
+ .features = BIT(DPU_CTL_ACTIVE_CFG)
+ },
+};
+
/*
* SSPP sub blocks config
*/
@@ -335,6 +385,23 @@ static const struct dpu_lm_cfg sc7180_lm[] = {
&sc7180_lm_sblk, PINGPONG_1, LM_0),
};
+/* SM8150 */
+
+static const struct dpu_lm_cfg sm8150_lm[] = {
+ LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_0, LM_1),
+ LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_1, LM_0),
+ LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_2, LM_3),
+ LM_BLK("lm_3", LM_3, 0x47000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_3, LM_2),
+ LM_BLK("lm_4", LM_4, 0x48000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_4, LM_5),
+ LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
+ &sdm845_lm_sblk, PINGPONG_5, LM_4),
+};
+
/*
* PINGPONG sub blocks config
*/
@@ -377,6 +444,15 @@ static struct dpu_pingpong_cfg sc7180_pp[] = {
PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800),
};
+static const struct dpu_pingpong_cfg sm8150_pp[] = {
+ PP_BLK_TE("pingpong_0", PINGPONG_0, 0x7),
+ PP_BLK_TE("pingpong_1", PINGPONG_1, 0x70800),
+ PP_BLK("pingpong_2", PINGPONG_2, 0x71000),
+ PP_BLK("pingpong_3", PINGPONG_3, 0x71800),
+ PP_BLK("pingpong_4", PINGPONG_4, 0x72000),
+ PP_BLK("pingpong_5", PINGPONG_5, 0x72800),
+};
+
/*
* INTF sub blocks config
*/
@@ -402,6 +478,13 @@ static const struct dpu_intf_cfg sc7180_intf[] = {
INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
};
+static const struct dpu_intf_cfg sm8150_intf[] = {
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SC7180_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SC7180_MASK),
+};
+
/*
* VBIF sub blocks config
**
[PATCH 5/8] drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3
This fixes flushing of INTF_2 and INTF_3 on SM8150 and SM8250 hardware.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 831e5f7a9b7f..99afdd66 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -245,30 +245,14 @@ static int dpu_hw_ctl_get_bitmask_intf(struct dpu_hw_ctl
*ctx,
static int dpu_hw_ctl_get_bitmask_intf_v1(struct dpu_hw_ctl *ctx,
u32 *flushbits, enum dpu_intf intf)
{
- switch (intf) {
- case INTF_0:
- case INTF_1:
- *flushbits |= BIT(31);
- break;
- default:
- return 0;
- }
+ *flushbits |= BIT(31);
return 0;
}
static int dpu_hw_ctl_active_get_bitmask_intf(struct dpu_hw_ctl *ctx,
u32 *flushbits, enum dpu_intf intf)
{
- switch (intf) {
- case INTF_0:
- *flushbits |= BIT(0);
- break;
- case INTF_1:
- *flushbits |= BIT(1);
- break;
- default:
- return 0;
- }
+ *flushbits |= BIT(intf - INTF_0);
return 0;
}
--
2.26.1
[PATCH 8/8] drm/msm/dpu: add SM8250 to hw catalog
This brings up basic video mode functionality for SM8250 DPU. Command mode
and dual mixer/intf configurations are not working, future patches will
address this. Scaler functionality and multiple planes is also untested.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 106 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 3 +
2 files changed, 109 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index f99622870676..711ec1e6a543 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -107,6 +107,21 @@ static const struct dpu_caps sm8150_dpu_caps = {
.max_vdeci_exp = MAX_VERT_DECIMATION,
};
+static const struct dpu_caps sm8250_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .max_linewidth = 4096,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3, /* TODO: qseed3 lite */
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V2_5,
+ .ubwc_version = DPU_HW_UBWC_VER_40,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 4096,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -149,6 +164,33 @@ static const struct dpu_mdp_cfg sc7180_mdp[] = {
},
};
+static const struct dpu_mdp_cfg sm8250_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x45C,
+ .features = 0,
+ .highest_bank_bit = 0x3, /* TODO: 2 for LP_DDR4 */
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
+ .reg_off = 0x2B4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
+ .reg_off = 0x2BC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
+ .reg_off = 0x2C4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
+ .reg_off = 0x2B4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .reg_off = 0x2BC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .reg_off = 0x2C4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_REG_DMA] = {
+ .reg_off = 0x2BC, .bit_off = 20},
+ },
+};
+
/*
* CTL sub blocks config
*/
@@ -519,6 +561,14 @@ static const struct dpu_reg_dma_cfg sm8150_regdma = {
.base = 0x0, .version = 0x00010001, .trigger_sel_off = 0x119c
};
+static const struct dpu_reg_dma_cfg sm8250_regdma = {
+ .base = 0x0,
+ .version = 0x00010002,
+ .trigger_sel_off = 0x119c,
+ .xin_id = 7,
+ .clk_ctrl = DPU_CLK_CTRL_REG_DMA,
+};
+
/*
* PERF data config
*/
@@ -656,6 +706,31 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
},
};
+static const struct dpu_perf_cfg sm8250_perf_data = {
+ .max_bw_low = 1370,
+ .max_bw_high = 1660,
+ .min_core_ib = 480,
+ .min_llcc_ib = 0,
+ .min_dram_ib = 80,
+ .danger_lut_tbl = {0xf, 0x, 0x0},
+ .qos_lut_tbl = {
+ {.nentry = ARRAY_SIZE(sc7180_qos_linear),
+ .entries = sc7180_qos_linear
+ },
+ {.nentry = ARRAY_SIZE(sc7180_qos_macrotile),
+ .entries = sc7180_qos_macrotile
+ },
+ {.nentry = ARRAY_SIZE(sc7180_qos_nrt),
+ .entries = sc7180_qos_nrt
+ },
+ /* TODO: macrotile-qseed is different from macrotile */
+ },
+ .cdp_cfg = {
+ {.rd_enable = 1, .wr_enable = 1},
+ {.rd_enable = 1, .wr_enable = 0}
+ },
+};
+
/*
* Hardware catalog init
*/
@@ -747,11 +822,42 @@ static void sm8150_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
};
}
+/*
+ * sm8250_cfg_init(): populate sm8250 dpu sub-blocks reg offsets
+ * and instance counts.
+ */
+static void sm8250_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
+{
+ *dpu_cfg = (struct dpu_mdss_cfg){
+ .caps = &sm8250_dpu_caps,
+ .mdp_count = ARRAY_SIZE(sm8250_mdp),
+ .mdp = sm8250_mdp,
+ .ctl_count = ARRAY_SIZE(sm8150_ctl),
+ .ctl = sm8150_ctl,
+ /* TODO: sspp qs
[PATCH 2/8] drm/msm/dpu: update UBWC config for sm8150 and sm8250
Update the UBWC registers to the right values for sm8150 and sm8250.
This removes broken dpu_hw_reset_ubwc, which doesn't work because the
"force blk offset to zero to access beginning of register region" hack is
copied from downstream, where mapped region starts 0x1000 below what is
used in the upstream driver.
Also simplifies the overly complicated change that was introduced in
e4f9bbe9f8beab9a1ce4 to work around dpu_hw_reset_ubwc being broken.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 --
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 8 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 16 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 18 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h| 7 --
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 75 ++-
6 files changed, 42 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1b960d9d1b33..3b48257886c6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1090,12 +1090,6 @@ static void _dpu_encoder_virt_enable_helper(struct
drm_encoder *drm_enc)
return;
}
- if (dpu_enc->cur_master->hw_mdptop &&
- dpu_enc->cur_master->hw_mdptop->ops.reset_ubwc)
- dpu_enc->cur_master->hw_mdptop->ops.reset_ubwc(
- dpu_enc->cur_master->hw_mdptop,
- dpu_kms->catalog);
-
_dpu_encoder_update_vsync_source(dpu_enc, &dpu_enc->disp_info);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 09df7d87dd43..f45f031a3a05 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -37,7 +37,9 @@
#define DPU_HW_VER_400 DPU_HW_VER(4, 0, 0) /* sdm845 v1.0 */
#define DPU_HW_VER_401 DPU_HW_VER(4, 0, 1) /* sdm845 v2.0 */
#define DPU_HW_VER_410 DPU_HW_VER(4, 1, 0) /* sdm670 v1.0 */
-#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sdm855 v1.0 */
+#define DPU_HW_VER_500 DPU_HW_VER(5, 0, 0) /* sm8150 v1.0 */
+#define DPU_HW_VER_501 DPU_HW_VER(5, 0, 1) /* sm8150 v2.0 */
+#define DPU_HW_VER_600 DPU_HW_VER(6, 0, 0) /* sm8250 */
#define DPU_HW_VER_620 DPU_HW_VER(6, 2, 0) /* sc7180 v1.0 */
@@ -65,10 +67,9 @@ enum {
DPU_HW_UBWC_VER_10 = 0x100,
DPU_HW_UBWC_VER_20 = 0x200,
DPU_HW_UBWC_VER_30 = 0x300,
+ DPU_HW_UBWC_VER_40 = 0x400,
};
-#define IS_UBWC_20_SUPPORTED(rev) ((rev) >= DPU_HW_UBWC_VER_20)
-
/**
* MDP TOP BLOCK features
* @DPU_MDP_PANIC_PER_PIPE Panic configuration needs to be be done per pipe
@@ -426,7 +427,6 @@ struct dpu_clk_ctrl_reg {
struct dpu_mdp_cfg {
DPU_HW_BLK_INFO;
u32 highest_bank_bit;
- u32 ubwc_static;
u32 ubwc_swizzle;
struct dpu_clk_ctrl_reg clk_ctrls[DPU_CLK_CTRL_MAX];
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 82c5dbfdabc7..c940b69435e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -303,11 +303,25 @@ static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(c, SSPP_FETCH_CONFIG,
DPU_FETCH_CONFIG_RESET_VALUE |
ctx->mdp->highest_bank_bit << 18);
- if (IS_UBWC_20_SUPPORTED(ctx->catalog->caps->ubwc_version)) {
+ switch (ctx->catalog->caps->ubwc_version) {
+ case DPU_HW_UBWC_VER_10:
+ /* TODO: UBWC v1 case */
+ break;
+ case DPU_HW_UBWC_VER_20:
fast_clear = fmt->alpha_enable ? BIT(31) : 0;
DPU_REG_WRITE(c, SSPP_UBWC_STATIC_CTRL,
fast_clear | (ctx->mdp->ubwc_swizzle) |
(ctx->mdp->highest_bank_bit << 4));
+ break;
+ case DPU_HW_UBWC_VER_30:
+ DPU_REG_WRITE(c, SSPP_UBWC_STATIC_CTRL,
+ BIT(30) | (ctx->mdp->ubwc_swizzle) |
+ (ctx->mdp->highest_bank_bit << 4));
+ break;
+ case DPU_HW_UBWC_VER_40:
+ DPU_REG_WRITE(c, SSPP_UBWC_STATIC_CTRL,
+ DPU_FORMAT_IS_YUV(fmt) ? 0 : BIT(30));
+ break;
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
index f9af52ae9f3e..01b76766a9a8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
@@ -8,7 +8,6 @@
#include "dpu_kms.h"
#define SSPP_SPARE0x28
-#define
[PATCH 3/8] drm/msm/dpu: move some sspp caps to dpu_caps
This isn't something that ever changes between planes, so move it to
dpu_caps struct. Making this change will allow more re-use in the
"SSPP sub blocks config" part of the catalog, in particular when adding
support for SM8150 and SM8250 which have different max_linewidth.
This also sets max_hdeci_exp/max_vdeci_exp to 0 for sc7180, as decimation
is not supported on the newest DPU versions. (note that decimation is not
implemented, so this changes nothing)
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 14 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 24 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 6 ++---
3 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c567917541e8..496407f1cd08 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -68,6 +68,10 @@ static const struct dpu_caps sdm845_dpu_caps = {
.has_dim_layer = true,
.has_idle_pc = true,
.has_3d_merge = true,
+ .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .max_hdeci_exp = MAX_HORZ_DECIMATION,
+ .max_vdeci_exp = MAX_VERT_DECIMATION,
};
static const struct dpu_caps sc7180_dpu_caps = {
@@ -78,6 +82,8 @@ static const struct dpu_caps sc7180_dpu_caps = {
.ubwc_version = DPU_HW_UBWC_VER_20,
.has_dim_layer = true,
.has_idle_pc = true,
+ .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
static const struct dpu_mdp_cfg sdm845_mdp[] = {
@@ -176,16 +182,9 @@ static const struct dpu_ctl_cfg sc7180_ctl[] = {
*/
/* SSPP common configuration */
-static const struct dpu_sspp_blks_common sdm845_sspp_common = {
- .maxlinewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
- .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
- .maxhdeciexp = MAX_HORZ_DECIMATION,
- .maxvdeciexp = MAX_VERT_DECIMATION,
-};
#define _VIG_SBLK(num, sdma_pri, qseed_ver) \
{ \
- .common = &sdm845_sspp_common, \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
.maxupscale = MAX_UPSCALE_RATIO, \
.smart_dma_priority = sdma_pri, \
@@ -205,7 +204,6 @@ static const struct dpu_sspp_blks_common sdm845_sspp_common
= {
#define _DMA_SBLK(num, sdma_pri) \
{ \
- .common = &sdm845_sspp_common, \
.maxdwnscale = SSPP_UNITY_SCALE, \
.maxupscale = SSPP_UNITY_SCALE, \
.smart_dma_priority = sdma_pri, \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index f45f031a3a05..7a8d1c6658d2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -290,6 +290,10 @@ struct dpu_qos_lut_tbl {
* @has_dim_layer dim layer feature status
* @has_idle_pcindicate if idle power collapse feature is supported
* @has_3d_merge indicate if 3D merge is supported
+ * @max_linewidth max linewidth for sspp
+ * @pixel_ram_size size of latency hiding and de-tiling buffer in bytes
+ * @max_hdeci_exp max horizontal decimation supported (max is 2^value)
+ * @max_vdeci_exp max vertical decimation supported (max is 2^value)
*/
struct dpu_caps {
u32 max_mixer_width;
@@ -301,22 +305,11 @@ struct dpu_caps {
bool has_dim_layer;
bool has_idle_pc;
bool has_3d_merge;
-};
-
-/**
- * struct dpu_sspp_blks_common : SSPP sub-blocks common configuration
- * @maxwidth: max pixelwidth supported by this pipe
- * @pixel_ram_size: size of latency hiding and de-tiling buffer in bytes
- * @maxhdeciexp: max horizontal decimation supported by this pipe
- * (max is 2^value)
- * @maxvdeciexp: max vertical decimation supported by this pipe
- * (max is 2^value)
- */
-struct dpu_sspp_blks_common {
- u32 maxlinewidth;
+ /* SSPP limits */
+ u32 max_linewidth;
u32 pixel_ram_size;
- u32 maxhdeciexp;
- u32 maxvdeciexp;
+ u32 max_hdeci_exp;
+ u32 max_vdeci_exp;
};
/**
@@ -342,7 +335,6 @@ struct dpu_sspp_blks_common {
* @virt_num_formats: Number of supported formats for virtual planes
*/
struct dpu_sspp_sub_blks {
- const struct dpu_sspp_blks_common *common;
u32 creq_vblank;
u32 danger_vblank;
u32 maxdwnscale;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 3b9c33e694bf..33f6c56f01ed 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -153,7 +153,7 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
pdpu = to_dpu_plane(plane);
pstate
[PATCH 1/8] drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250
All DPU versions starting from 4.0 use the sdm845 version, so check for
that instead of checking each version individually. This chooses the right
function for sm8150 and sm8250.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 37becd43bd54..4b8baf71423f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -152,14 +152,13 @@ static void _setup_mixer_ops(const struct dpu_mdss_cfg *m,
unsigned long features)
{
ops->setup_mixer_out = dpu_hw_lm_setup_out;
- if (IS_SDM845_TARGET(m->hwversion) || IS_SDM670_TARGET(m->hwversion)
- || IS_SC7180_TARGET(m->hwversion))
+ if (m->hwversion >= DPU_HW_VER_400)
ops->setup_blend_config = dpu_hw_lm_setup_blend_config_sdm845;
else
ops->setup_blend_config = dpu_hw_lm_setup_blend_config;
ops->setup_alpha_out = dpu_hw_lm_setup_color3;
ops->setup_border_color = dpu_hw_lm_setup_border_color;
-};
+}
static struct dpu_hw_blk_ops dpu_hw_ops;
--
2.26.1
[PATCH 0/8] Initial SM8150 and SM8250 DPU bringup
These patches bring up SM8150 and SM8250 with basic functionality. Tested with displayport output (single mixer, video mode case). I will send patches later to add support for merge3d and dual DSI configurations, and possibly also patches to fix command mode on these SoCs (note it is also currently broken for SC7180). Jonathan Marek (8): drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250 drm/msm/dpu: update UBWC config for sm8150 and sm8250 drm/msm/dpu: move some sspp caps to dpu_caps drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845 drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3 drm/msm/dpu: intf timing path for displayport drm/msm/dpu: add SM8150 to hw catalog drm/msm/dpu: add SM8250 to hw catalog drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 - .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 287 +- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 48 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 29 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 16 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 18 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h| 7 - drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 75 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 6 +- 12 files changed, 363 insertions(+), 156 deletions(-) -- 2.26.1
[PATCH v2 2/2] crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req()
The system'll crash when the users insmod crypto/tcrypto.ko with mode=155
( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory
of request structure.
In crypto_authenc_init_tfm(), the reqsize is set to:
[PART 1] sizeof(authenc_request_ctx) +
[PART 2] ictx->reqoff +
[PART 3] MAX(ahash part, skcipher part)
and the 'PART 3' is used by both ahash and skcipher in turn.
When the virtio_crypto driver finish skcipher req, it'll call ->complete
callback(in crypto_finalize_skcipher_request) and then free its
resources whose pointers are recorded in 'skcipher parts'.
However, the ->complete is 'crypto_authenc_encrypt_done' in this case,
it will use the 'ahash part' of the request and change its content,
so virtio_crypto driver will get the wrong pointer after ->complete
finish and mistakenly free some other's memory. So the system will crash
when these memory will be used again.
The resources which need to be cleaned up are not used any more. But the
pointers of these resources may be changed in the function
"crypto_finalize_skcipher_request". Thus release specific resources before
calling this function.
Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Reported-by: LABBE Corentin
Cc: Gonglei
Cc: Herbert Xu
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: "David S. Miller"
Cc: Markus Elfring
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Message-Id: <20200123101000.GB24255@Red>
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
b/drivers/crypto/virtio/virtio_crypto_algs.c
index 5f8243563009..52261b6c247e 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -582,10 +582,11 @@ static void virtio_crypto_skcipher_finalize_req(
scatterwalk_map_and_copy(req->iv, req->dst,
req->cryptlen - AES_BLOCK_SIZE,
AES_BLOCK_SIZE, 0);
- crypto_finalize_skcipher_request(vc_sym_req->base.dataq->engine,
- req, err);
kzfree(vc_sym_req->iv);
virtcrypto_clear_request(&vc_sym_req->base);
+
+ crypto_finalize_skcipher_request(vc_sym_req->base.dataq->engine,
+ req, err);
}
static struct virtio_crypto_algo virtio_crypto_algs[] = { {
--
2.23.0
[PATCH v2 1/2] crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req()
The system will crash when the users insmod crypto/tcrypt.ko with mode=38
( testing "cts(cbc(aes))" ).
Usually the next entry of one sg will be @sg@ + 1, but if this sg element
is part of a chained scatterlist, it could jump to the start of a new
scatterlist array. Fix it by sg_next() on calculation of src/dst
scatterlist.
Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Reported-by: LABBE Corentin
Cc: Herbert Xu
Cc: "Michael S. Tsirkin"
Cc: Jason Wang
Cc: "David S. Miller"
Cc: Markus Elfring
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Message-Id: <20200123101000.GB24255@Red>
Signed-off-by: Gonglei
Signed-off-by: Longpeng(Mike)
---
drivers/crypto/virtio/virtio_crypto_algs.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
b/drivers/crypto/virtio/virtio_crypto_algs.c
index fd045e64972a..5f8243563009 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -350,13 +350,18 @@ __virtio_crypto_skcipher_do_req(struct
virtio_crypto_sym_request *vc_sym_req,
int err;
unsigned long flags;
struct scatterlist outhdr, iv_sg, status_sg, **sgs;
- int i;
u64 dst_len;
unsigned int num_out = 0, num_in = 0;
int sg_total;
uint8_t *iv;
+ struct scatterlist *sg;
src_nents = sg_nents_for_len(req->src, req->cryptlen);
+ if (src_nents < 0) {
+ pr_err("Invalid number of src SG.\n");
+ return src_nents;
+ }
+
dst_nents = sg_nents(req->dst);
pr_debug("virtio_crypto: Number of sgs (src_nents: %d, dst_nents:
%d)\n",
@@ -442,12 +447,12 @@ __virtio_crypto_skcipher_do_req(struct
virtio_crypto_sym_request *vc_sym_req,
vc_sym_req->iv = iv;
/* Source data */
- for (i = 0; i < src_nents; i++)
- sgs[num_out++] = &req->src[i];
+ for (sg = req->src; src_nents; sg = sg_next(sg), src_nents--)
+ sgs[num_out++] = sg;
/* Destination data */
- for (i = 0; i < dst_nents; i++)
- sgs[num_out + num_in++] = &req->dst[i];
+ for (sg = req->dst; sg; sg = sg_next(sg))
+ sgs[num_out + num_in++] = sg;
/* Status */
sg_init_one(&status_sg, &vc_req->status, sizeof(vc_req->status));
--
2.23.0
