* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Mark Railton @ 2018-07-23 21:58 UTC (permalink / raw)
To: Randy Dunlap; +Cc: boris.ostrovsky, jgross, xen-devel, linux-kernel
In-Reply-To: <e8cab255-eb21-fd08-e62b-3afbbe853b84@infradead.org>
On Mon, Jul 23, 2018 at 02:55:12PM -0700, Randy Dunlap wrote:
> On 07/23/2018 02:48 PM, Mark Railton wrote:
> > On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote:
> >> On 07/23/2018 02:40 PM, Mark Railton wrote:
> >>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
> >>>> On 07/23/2018 02:34 PM, Mark Railton wrote:
> >>>>> Fixed issue with multi line comment
> >>>>
> >>>> Fix [not Fixed]
> >>>>
> >>>>>
> >>>>> Signed-off-by: Mark Railton <mark@markrailton.com>
> >>>>> ---
> >>>>> drivers/xen/xlate_mmu.c | 5 +++--
> >>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> >>>>> index 23f1387b3ef7..3b03bc1641ed 100644
> >>>>> --- a/drivers/xen/xlate_mmu.c
> >>>>> +++ b/drivers/xen/xlate_mmu.c
> >>>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> >>>>> struct remap_data data;
> >>>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> >>>>>
> >>>>> - /* Kept here for the purpose of making sure code doesn't break
> >>>>> - x86 PVOPS */
> >>>>> + /* Kept here for the purpose of making sure code doesn't
> >>>>> + * break x86 PVOPS
> >>>>> + */
> >>>>
> >>>> That is still not the preferred kernel multi-line comment style.
> >>>> Documentation/process/coding-style.rst says:
> >>>>
> >>>> /*
> >>>> * This is the preferred style for multi-line
> >>>> * comments in the Linux kernel source code.
> >>>> * Please use it consistently.
> >>>> *
> >>>> * Description: A column of asterisks on the left side,
> >>>> * with beginning and ending almost-blank lines.
> >>>> */
> >>>>
> >>>> although Networking code has a slightly different preferred style (as in
> >>>> your patch).
> >>>>
> >>>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >>>>>
> >>>>> data.fgfn = gfn;
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> ~Randy
> >>>
> >>> Thank's for the feedback, I'll get that updated now.
> >>>
> >>> I'm still kinda new to this, I assume I need to send the new patch via
> >>> git send-email?
> >>
> >> That is one option. Use whatever works for you.
> >>
> >> There are several email clients that also work well.
> >> See Documentation/process/email-clients.rst.
> >>
> >>
> >> --
> >> ~Randy
> >
> > From 57c8104d2a30020005be16df2ca69ed66f6c4ae9 Mon Sep 17 00:00:00 2001
> > From: Mark Railton <mark@markrailton.com>
> > Date: Mon, 23 Jul 2018 22:28:53 +0100
> > Subject: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
> >
> > Fixed issue with multi line comment
> >
> > Signed-off-by: Mark Railton <mark@markrailton.com>
> > ---
> > drivers/xen/xlate_mmu.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> > index 23f1387b3ef7..2b77c79f8ce7 100644
> > --- a/drivers/xen/xlate_mmu.c
> > +++ b/drivers/xen/xlate_mmu.c
> > @@ -151,8 +151,10 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> > struct remap_data data;
> > unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> >
> > - /* Kept here for the purpose of making sure code doesn't break
> > - x86 PVOPS */
> > + /*
> > + * Kept here for the purpose of making sure code doesn't
> > + * break x86 PVOPS
> > + */
> > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >
> > data.fgfn = gfn;
> > --
> > 2.17.1
>
>
> Hi,
>
> a. The subject and the patch description should be in present tense, i.e.,
> Fix instead of Fixed.
>
> b. Ideally you start a new email thread for new versions of a patch (but Cc:
> the interested parties).
>
> For the patch itself:
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks.
>
> --
> ~Randy
Thank you for the feedback, I will make sure to take that on board.
Mark
^ permalink raw reply
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Mark Railton @ 2018-07-23 21:58 UTC (permalink / raw)
To: Randy Dunlap; +Cc: jgross, xen-devel, boris.ostrovsky, linux-kernel
In-Reply-To: <e8cab255-eb21-fd08-e62b-3afbbe853b84@infradead.org>
On Mon, Jul 23, 2018 at 02:55:12PM -0700, Randy Dunlap wrote:
> On 07/23/2018 02:48 PM, Mark Railton wrote:
> > On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote:
> >> On 07/23/2018 02:40 PM, Mark Railton wrote:
> >>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
> >>>> On 07/23/2018 02:34 PM, Mark Railton wrote:
> >>>>> Fixed issue with multi line comment
> >>>>
> >>>> Fix [not Fixed]
> >>>>
> >>>>>
> >>>>> Signed-off-by: Mark Railton <mark@markrailton.com>
> >>>>> ---
> >>>>> drivers/xen/xlate_mmu.c | 5 +++--
> >>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> >>>>> index 23f1387b3ef7..3b03bc1641ed 100644
> >>>>> --- a/drivers/xen/xlate_mmu.c
> >>>>> +++ b/drivers/xen/xlate_mmu.c
> >>>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> >>>>> struct remap_data data;
> >>>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> >>>>>
> >>>>> - /* Kept here for the purpose of making sure code doesn't break
> >>>>> - x86 PVOPS */
> >>>>> + /* Kept here for the purpose of making sure code doesn't
> >>>>> + * break x86 PVOPS
> >>>>> + */
> >>>>
> >>>> That is still not the preferred kernel multi-line comment style.
> >>>> Documentation/process/coding-style.rst says:
> >>>>
> >>>> /*
> >>>> * This is the preferred style for multi-line
> >>>> * comments in the Linux kernel source code.
> >>>> * Please use it consistently.
> >>>> *
> >>>> * Description: A column of asterisks on the left side,
> >>>> * with beginning and ending almost-blank lines.
> >>>> */
> >>>>
> >>>> although Networking code has a slightly different preferred style (as in
> >>>> your patch).
> >>>>
> >>>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >>>>>
> >>>>> data.fgfn = gfn;
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> ~Randy
> >>>
> >>> Thank's for the feedback, I'll get that updated now.
> >>>
> >>> I'm still kinda new to this, I assume I need to send the new patch via
> >>> git send-email?
> >>
> >> That is one option. Use whatever works for you.
> >>
> >> There are several email clients that also work well.
> >> See Documentation/process/email-clients.rst.
> >>
> >>
> >> --
> >> ~Randy
> >
> > From 57c8104d2a30020005be16df2ca69ed66f6c4ae9 Mon Sep 17 00:00:00 2001
> > From: Mark Railton <mark@markrailton.com>
> > Date: Mon, 23 Jul 2018 22:28:53 +0100
> > Subject: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
> >
> > Fixed issue with multi line comment
> >
> > Signed-off-by: Mark Railton <mark@markrailton.com>
> > ---
> > drivers/xen/xlate_mmu.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> > index 23f1387b3ef7..2b77c79f8ce7 100644
> > --- a/drivers/xen/xlate_mmu.c
> > +++ b/drivers/xen/xlate_mmu.c
> > @@ -151,8 +151,10 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> > struct remap_data data;
> > unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> >
> > - /* Kept here for the purpose of making sure code doesn't break
> > - x86 PVOPS */
> > + /*
> > + * Kept here for the purpose of making sure code doesn't
> > + * break x86 PVOPS
> > + */
> > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >
> > data.fgfn = gfn;
> > --
> > 2.17.1
>
>
> Hi,
>
> a. The subject and the patch description should be in present tense, i.e.,
> Fix instead of Fixed.
>
> b. Ideally you start a new email thread for new versions of a patch (but Cc:
> the interested parties).
>
> For the patch itself:
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks.
>
> --
> ~Randy
Thank you for the feedback, I will make sure to take that on board.
Mark
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: Changing non-volatile access to volatile in counter examples
From: Paul E. McKenney @ 2018-07-23 20:55 UTC (permalink / raw)
To: Imre Palik; +Cc: perfbook
In-Reply-To: <1532376448-15103-1-git-send-email-imrep.amz@gmail.com>
On Mon, Jul 23, 2018 at 10:07:24PM +0200, Imre Palik wrote:
>
> This series changes some of the counter examples to use volatile access, to
> avoid overly eager compilers/linkers to optimise out necessary reads/writes.
Applied and pushed, thank you!
And very nice to get that graph upgraded to the much more recent Kaby
Lake! By the way, if you have one with more than eight hardware threads,
I would not say "no" to an expanded graph. ;-)
Thanx, Paul
^ permalink raw reply
* Re: [mmotm:master 171/351] mm/vmacache.c:14:39: error: 'PMD_SHIFT' undeclared; did you mean 'PUD_SHIFT'?
From: David Rientjes @ 2018-07-23 21:57 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Johannes Weiner, Andrew Morton,
Linux Memory Management List
In-Reply-To: <201807211152.qkpCcW5b%fengguang.wu@intel.com>
On Sat, 21 Jul 2018, kbuild test robot wrote:
> tree: git://git.cmpxchg.org/linux-mmotm.git master
> head: 51e69b1d3de18116a5dceb6b144444dfdf136dc7
> commit: 77ecf9bc0e3d673d4d561cedc1d01c7a84ef90b7 [171/351] mm, vmacache: hash addresses based on pmd
> config: arm-allnoconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 77ecf9bc0e3d673d4d561cedc1d01c7a84ef90b7
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm
>
I've got my cross compiler back up and working. This is occurring because
allnconfig is disabling CONFIG_MMU so we don't have PMD_SHIFT (there's
only a pgdir). I'll send patch to fix the build errors.
^ permalink raw reply
* Re: [PATCH 12/12] i2c: sh_mobile: use core to detect 'no zero length read' quirk
From: Niklas Söderlund @ 2018-07-23 20:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-renesas-soc, linux-kernel
In-Reply-To: <20180723202617.15230-13-wsa+renesas@sang-engineering.com>
Hi Wolfram,
Thanks for your work.
On 2018-07-23 22:26:16 +0200, Wolfram Sang wrote:
> And don't reimplement in the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas S�derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
>
> drivers/i2c/busses/i2c-sh_mobile.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
> index 5fda4188a9e5..9c7f6f8ceb22 100644
> --- a/drivers/i2c/busses/i2c-sh_mobile.c
> +++ b/drivers/i2c/busses/i2c-sh_mobile.c
> @@ -613,11 +613,6 @@ static void sh_mobile_i2c_xfer_dma(struct sh_mobile_i2c_data *pd)
> static int start_ch(struct sh_mobile_i2c_data *pd, struct i2c_msg *usr_msg,
> bool do_init)
> {
> - if (usr_msg->len == 0 && (usr_msg->flags & I2C_M_RD)) {
> - dev_err(pd->dev, "Unsupported zero length i2c read\n");
> - return -EOPNOTSUPP;
> - }
> -
> if (do_init) {
> /* Initialize channel registers */
> iic_wr(pd, ICCR, ICCR_SCP);
> @@ -758,6 +753,10 @@ static const struct i2c_algorithm sh_mobile_i2c_algorithm = {
> .master_xfer = sh_mobile_i2c_xfer,
> };
>
> +static const struct i2c_adapter_quirks sh_mobile_i2c_quirks = {
> + .flags = I2C_AQ_NO_ZERO_LEN_READ,
> +};
> +
> /*
> * r8a7740 chip has lasting errata on I2C I/O pad reset.
> * this is work-around for it.
> @@ -925,6 +924,7 @@ static int sh_mobile_i2c_probe(struct platform_device *dev)
>
> adap->owner = THIS_MODULE;
> adap->algo = &sh_mobile_i2c_algorithm;
> + adap->quirks = &sh_mobile_i2c_quirks;
> adap->dev.parent = &dev->dev;
> adap->retries = 5;
> adap->nr = dev->id;
> --
> 2.11.0
>
--
Regards,
Niklas S�derlund
^ permalink raw reply
* Re: Fwd: New Defects reported by Coverity Scan for Linux
From: Bjorn Helgaas @ 2018-07-23 20:54 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Honghui Zhang, Sergei Shtylyov, Lorenzo Pieralisi, linux-pci,
Gustavo A. R. Silva
In-Reply-To: <CAErSpo7wy1CZvozUX+vnj0W_-m85M=TBUYp3N=W1wB57=_8kXw@mail.gmail.com>
[+cc Gustavo]
On Mon, Jul 23, 2018 at 02:12:49PM -0500, Bjorn Helgaas wrote:
> Hi Honghui,
>
> Would you consider doing a minor patch to fix the issue Coverity
> reported below (not checking the return value from
> devm_pci_remap_iospace())?
Never mind, I see Gustavo has already posted such a patch:
https://lkml.kernel.org/r/20180720150158.GA10922@embeddedor.com
Thanks, Gustavo!
> ---------- Forwarded message ---------
> From: <scan-admin@coverity.com>
> Date: Sun, Jul 22, 2018 at 11:13 PM
> Subject: New Defects reported by Coverity Scan for Linux
> To: <bhelgaas@google.com>
>
> ...
> ** CID 1438089: Error handling issues (CHECKED_RETURN)
> /drivers/pci/controller/pcie-mediatek.c: 1112 in mtk_pcie_request_resources()
>
>
> ________________________________________________________________________________________________________
> *** CID 1438089: Error handling issues (CHECKED_RETURN)
> /drivers/pci/controller/pcie-mediatek.c: 1112 in mtk_pcie_request_resources()
> 1106 pci_add_resource(windows, &pcie->busn);
> 1107
> 1108 err = devm_request_pci_bus_resources(dev, windows);
> 1109 if (err < 0)
> 1110 return err;
> 1111
> >>> CID 1438089: Error handling issues (CHECKED_RETURN)
> >>> Calling "devm_pci_remap_iospace" without checking return value (as is done elsewhere 5 out of 6 times).
> 1112 devm_pci_remap_iospace(dev, &pcie->pio, pcie->io.start);
> 1113
> 1114 return 0;
> 1115 }
> 1116
> 1117 static int mtk_pcie_register_host(struct pci_host_bridge *host)
^ permalink raw reply
* Re: [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 20:53 UTC (permalink / raw)
To: Jarkko Sakkinen; +Cc: jgg, linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <20180723201956.GB26824@linux.intel.com>
On 07/23/2018 01:19 PM, Jarkko Sakkinen wrote:
> In this case I do not have any major evidence of any major benefit *and*
> the change breaks the ABI.
As I said before - this does not break the ABI.
As for the benefits - it help user space in how they implement the receive
path. Application does not need to provide a 4K buffer for every read even
if the response is, for instance 8 bytes long.
Thanks,
--
Tadeusz
^ permalink raw reply
* [PATCH] tpm: add support for partial reads
From: Jason Gunthorpe @ 2018-07-23 21:56 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <7441b5ef-18d8-13aa-ef4d-40fe684c9218@intel.com>
On Mon, Jul 23, 2018 at 02:38:08PM -0700, Tadeusz Struk wrote:
> On 07/23/2018 02:13 PM, James Bottomley wrote:
> > The current patch does, you even provided a use case in your last email
> > (it's do command to get sizing followed by do command with correctly
> > sized buffer).
>
> The example I provided was: #1 send a command, #2 read the response header
> (10 bytes), get the actual response size from the header and then #3 read
> the full response (response size - size of the header bytes).
The proposed patch doesn't clear the data_pending if the entire buffer
is not consumed, so of course it is ABI breaking, that really isn't OK.
> > However, if you tie it to O_NONBLOCK, it won't because no-one currently
> > opens the TPM device non blocking so it's an ABI conformant
> > discriminator of the uses. Tying to O_NONBLOCK should be simple
> > because it's in file->f_flags.
>
> I think that it might be an option. Especially that I have this on top of
> the async patch. Let's discuss this when Jarkko is back.
Maybe you could do this by requiring the userspace to call pread()
with a non-zero offset to get the trailing segment of the last
executed command and leave normal read/pread(off=0) with the semantics
as they have today.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] PTI for x86-32 Fixes and Updates
From: Pavel Machek @ 2018-07-23 21:55 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linus Torvalds, Joerg Roedel, Thomas Gleixner, Ingo Molnar,
Peter Anvin, the arch/x86 maintainers, Linux Kernel Mailing List,
linux-mm, Andrew Lutomirski, Dave Hansen, Josh Poimboeuf,
Jürgen Groß, Peter Zijlstra, Borislav Petkov,
Jiri Kosina, Boris Ostrovsky, Brian Gerst, David Laight,
Denys Vlasenko, Eduardo Valentin, Greg Kroah-Hartman, Will Deacon,
Liguori, Anthony, Daniel Gruss, Hugh Dickins, Kees Cook,
Andrea Arcangeli, Waiman Long, David H . Gutteridge, Joerg Roedel,
Arnaldo Carvalho de Melo, Alexander Shishkin, Jiri Olsa,
Namhyung Kim
In-Reply-To: <39A1C149-DA03-46D1-801F-0205DCD69A36@amacapital.net>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
Hi!
> > What I want is "if A can ptrace B, and B has pti disabled, A can have
> > pti disabled as well". Now.. I see someone may want to have it
> > per-thread, because for stuff like javascript JIT, thread may have
> > rights to call ptrace, but is unable to call ptrace because JIT
> > removed that ability... hmm...
>
> No, you don’t want that. The problem is that Meltdown isn’t a problem that exists in isolation. It’s very plausible that JavaScript code could trigger a speculation attack that, with PTI off, could read kernel memory.
Yeah, the web browser threads that run javascript code should have PTI
on. But maybe I want the rest of web browser with PTI off.
So... yes, I see why someone may want it per-thread (and not
per-process).
I guess per-process would be good enough for me. Actually, maybe even
per-uid. I don't have any fancy security here, so anything running uid
0 and 1000 is close enough to trusted.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: HID: intel_ish-hid: tx_buf memory leak on probe/remove
From: Srinivas Pandruvada @ 2018-07-23 21:55 UTC (permalink / raw)
To: Anton Vasilyev
Cc: Jiri Kosina, Benjamin Tissoires, Even Xu, linux-input,
linux-kernel, ldv-project
In-Reply-To: <a0faf8a7-17ea-0ed3-5bb5-f1e8fb5debf6@ispras.ru>
On Mon, 2018-07-23 at 20:56 +0300, Anton Vasilyev wrote:
> ish_dev_init() allocates 512*176 bytes memory for tx_buf and stores
> it at
> &dev->wr_free_list_head.link list on ish_probe().
> But there is no deallocation of this memory in ish_remove() and in
> ish_probe()
> error path.
> So current intel-ish-ipc provides 88 KB memory leak for each
> probe/release.
>
> I have two ideas 1) to replace kzalloc allocation by devm_kzalloc,
Thanks for finding this. We can replace both alloc in this function
with devm_ calls. Once you have a patch I can test.
Thanks,
Srinivas
> or 2) release memory stored at &dev->wr_free_list_head.link list
> (and
> may be at
> &dev->wr_processing_list_head.link) in all driver exits.
>
> But I do not know which way is preferable for this case.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> --
> Anton Vasilyev
> Linux Verification Center, ISPRAS
> web: http://linuxtesting.org
> e-mail: vasilyev@ispras.ru
^ permalink raw reply
* Re: [EXTERNAL] [rocko/master][PATCHv2] tidl-utils: SRCREV bump
From: Jacob Stiffler @ 2018-07-23 21:55 UTC (permalink / raw)
To: Djordje Senicic, meta-arago; +Cc: d-senicic1
In-Reply-To: <1532375688-4054-1-git-send-email-x0157990@ti.com>
Denys,
Can you please apply this to the ti2018.01 branch?
Thank you,
Jake
On 7/23/2018 3:54 PM, Djordje Senicic wrote:
> * Get new version of tidl-utils configuration files with fixed path
> * RDEPENDS is not needed for x86 target, as executables are statically linked
>
> Signed-off-by: Djordje Senicic <x0157990@ti.com>
> ---
> meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
> index 264b030..569de5a 100644
> --- a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
> +++ b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
> @@ -8,10 +8,10 @@ INC_PR = "r0"
>
> LIC_FILES_CHKSUM = "file://docs/LICENSE.txt;md5=a93aa5af7a3bbbb6fb34c8df59efaa5c"
>
> -RDEPENDS_${PN} += " tidl-api tidl-examples "
> +RDEPENDS_${PN}_class-target += " tidl-api tidl-examples "
>
> SRC_URI = "git://git.ti.com/tidl/tidl-utils.git;protocol=git;branch=master"
> -SRCREV = "93f66d2c53960b13b7e7f20208ee205f727aaf28"
> +SRCREV = "994d90ae583610673d9d39086ca5e84027a9c56e"
>
> PR = "${INC_PR}.0"
>
^ permalink raw reply
* Re: [PATCH RFC] debugobjects: Make stack check warning more informative
From: Yang Shi @ 2018-07-23 21:54 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: kernel-team, Thomas Gleixner, Waiman Long, Arnd Bergmann,
astrachan
In-Reply-To: <20180723212531.202328-1-joel@joelfernandes.org>
On 7/23/18 2:25 PM, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
>
> Recently we debugged an issue where debugobject tracking was telling
> us of an annotation issue. Turns out the issue was due to the object in
> concern being on a different stack which was due to another issue.
>
> Discussing with tglx, he suggested printing the pointers and the
> location of the stack for the currently running task. This helped find
> the object was on the wrong stack. I turned the resulting patch into
> something upstreamable, so that the error message is more informative
> and can help in debugging for similar issues in the future.
Acked-by: Yang Shi <yang.shi@linux.alibaba.com>
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> lib/debugobjects.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index 994be4805cec..24c1df0d7466 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -360,9 +360,12 @@ static void debug_object_is_on_stack(void *addr, int onstack)
>
> limit++;
> if (is_on_stack)
> - pr_warn("object is on stack, but not annotated\n");
> + pr_warn("object %p is on stack %p, but NOT annotated.\n", addr,
> + task_stack_page(current));
> else
> - pr_warn("object is not on stack, but annotated\n");
> + pr_warn("object %p is NOT on stack %p, but annotated.\n", addr,
> + task_stack_page(current));
> +
> WARN_ON(1);
> }
>
^ permalink raw reply
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Randy Dunlap @ 2018-07-23 21:55 UTC (permalink / raw)
To: Mark Railton; +Cc: boris.ostrovsky, jgross, xen-devel, linux-kernel
In-Reply-To: <20180723214804.GA21761@ZeroCool>
On 07/23/2018 02:48 PM, Mark Railton wrote:
> On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote:
>> On 07/23/2018 02:40 PM, Mark Railton wrote:
>>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
>>>> On 07/23/2018 02:34 PM, Mark Railton wrote:
>>>>> Fixed issue with multi line comment
>>>>
>>>> Fix [not Fixed]
>>>>
>>>>>
>>>>> Signed-off-by: Mark Railton <mark@markrailton.com>
>>>>> ---
>>>>> drivers/xen/xlate_mmu.c | 5 +++--
>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>>> index 23f1387b3ef7..3b03bc1641ed 100644
>>>>> --- a/drivers/xen/xlate_mmu.c
>>>>> +++ b/drivers/xen/xlate_mmu.c
>>>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>>>>> struct remap_data data;
>>>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>>>>>
>>>>> - /* Kept here for the purpose of making sure code doesn't break
>>>>> - x86 PVOPS */
>>>>> + /* Kept here for the purpose of making sure code doesn't
>>>>> + * break x86 PVOPS
>>>>> + */
>>>>
>>>> That is still not the preferred kernel multi-line comment style.
>>>> Documentation/process/coding-style.rst says:
>>>>
>>>> /*
>>>> * This is the preferred style for multi-line
>>>> * comments in the Linux kernel source code.
>>>> * Please use it consistently.
>>>> *
>>>> * Description: A column of asterisks on the left side,
>>>> * with beginning and ending almost-blank lines.
>>>> */
>>>>
>>>> although Networking code has a slightly different preferred style (as in
>>>> your patch).
>>>>
>>>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>>>>>
>>>>> data.fgfn = gfn;
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Randy
>>>
>>> Thank's for the feedback, I'll get that updated now.
>>>
>>> I'm still kinda new to this, I assume I need to send the new patch via
>>> git send-email?
>>
>> That is one option. Use whatever works for you.
>>
>> There are several email clients that also work well.
>> See Documentation/process/email-clients.rst.
>>
>>
>> --
>> ~Randy
>
> From 57c8104d2a30020005be16df2ca69ed66f6c4ae9 Mon Sep 17 00:00:00 2001
> From: Mark Railton <mark@markrailton.com>
> Date: Mon, 23 Jul 2018 22:28:53 +0100
> Subject: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
>
> Fixed issue with multi line comment
>
> Signed-off-by: Mark Railton <mark@markrailton.com>
> ---
> drivers/xen/xlate_mmu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 23f1387b3ef7..2b77c79f8ce7 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -151,8 +151,10 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> struct remap_data data;
> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>
> - /* Kept here for the purpose of making sure code doesn't break
> - x86 PVOPS */
> + /*
> + * Kept here for the purpose of making sure code doesn't
> + * break x86 PVOPS
> + */
> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>
> data.fgfn = gfn;
> --
> 2.17.1
Hi,
a. The subject and the patch description should be in present tense, i.e.,
Fix instead of Fixed.
b. Ideally you start a new email thread for new versions of a patch (but Cc:
the interested parties).
For the patch itself:
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Randy Dunlap @ 2018-07-23 21:55 UTC (permalink / raw)
To: Mark Railton; +Cc: jgross, xen-devel, boris.ostrovsky, linux-kernel
In-Reply-To: <20180723214804.GA21761@ZeroCool>
On 07/23/2018 02:48 PM, Mark Railton wrote:
> On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote:
>> On 07/23/2018 02:40 PM, Mark Railton wrote:
>>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
>>>> On 07/23/2018 02:34 PM, Mark Railton wrote:
>>>>> Fixed issue with multi line comment
>>>>
>>>> Fix [not Fixed]
>>>>
>>>>>
>>>>> Signed-off-by: Mark Railton <mark@markrailton.com>
>>>>> ---
>>>>> drivers/xen/xlate_mmu.c | 5 +++--
>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
>>>>> index 23f1387b3ef7..3b03bc1641ed 100644
>>>>> --- a/drivers/xen/xlate_mmu.c
>>>>> +++ b/drivers/xen/xlate_mmu.c
>>>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
>>>>> struct remap_data data;
>>>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>>>>>
>>>>> - /* Kept here for the purpose of making sure code doesn't break
>>>>> - x86 PVOPS */
>>>>> + /* Kept here for the purpose of making sure code doesn't
>>>>> + * break x86 PVOPS
>>>>> + */
>>>>
>>>> That is still not the preferred kernel multi-line comment style.
>>>> Documentation/process/coding-style.rst says:
>>>>
>>>> /*
>>>> * This is the preferred style for multi-line
>>>> * comments in the Linux kernel source code.
>>>> * Please use it consistently.
>>>> *
>>>> * Description: A column of asterisks on the left side,
>>>> * with beginning and ending almost-blank lines.
>>>> */
>>>>
>>>> although Networking code has a slightly different preferred style (as in
>>>> your patch).
>>>>
>>>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>>>>>
>>>>> data.fgfn = gfn;
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Randy
>>>
>>> Thank's for the feedback, I'll get that updated now.
>>>
>>> I'm still kinda new to this, I assume I need to send the new patch via
>>> git send-email?
>>
>> That is one option. Use whatever works for you.
>>
>> There are several email clients that also work well.
>> See Documentation/process/email-clients.rst.
>>
>>
>> --
>> ~Randy
>
> From 57c8104d2a30020005be16df2ca69ed66f6c4ae9 Mon Sep 17 00:00:00 2001
> From: Mark Railton <mark@markrailton.com>
> Date: Mon, 23 Jul 2018 22:28:53 +0100
> Subject: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
>
> Fixed issue with multi line comment
>
> Signed-off-by: Mark Railton <mark@markrailton.com>
> ---
> drivers/xen/xlate_mmu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> index 23f1387b3ef7..2b77c79f8ce7 100644
> --- a/drivers/xen/xlate_mmu.c
> +++ b/drivers/xen/xlate_mmu.c
> @@ -151,8 +151,10 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> struct remap_data data;
> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
>
> - /* Kept here for the purpose of making sure code doesn't break
> - x86 PVOPS */
> + /*
> + * Kept here for the purpose of making sure code doesn't
> + * break x86 PVOPS
> + */
> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
>
> data.fgfn = gfn;
> --
> 2.17.1
Hi,
a. The subject and the patch description should be in present tense, i.e.,
Fix instead of Fixed.
b. Ideally you start a new email thread for new versions of a patch (but Cc:
the interested parties).
For the patch itself:
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
--
~Randy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2 10/15] xfs: use internal dfops in attr code
From: Bill O'Donnell @ 2018-07-23 20:51 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-xfs
In-Reply-To: <20180723130414.47980-11-bfoster@redhat.com>
On Mon, Jul 23, 2018 at 09:04:09AM -0400, Brian Foster wrote:
> Remove the unnecessary on-stack dfops structure and use the internal
> transaction dfops instead. The lower level xattr code already
> appropriately accesses ->t_dfops throughout.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
Looks good.
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
> ---
> fs/xfs/libxfs/xfs_attr.c | 16 +++++-----------
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
> index 927d4c968f9a..66a22c80a0db 100644
> --- a/fs/xfs/libxfs/xfs_attr.c
> +++ b/fs/xfs/libxfs/xfs_attr.c
> @@ -202,7 +202,6 @@ xfs_attr_set(
> struct xfs_mount *mp = dp->i_mount;
> struct xfs_buf *leaf_bp = NULL;
> struct xfs_da_args args;
> - struct xfs_defer_ops dfops;
> struct xfs_trans_res tres;
> int rsvd = (flags & ATTR_ROOT) != 0;
> int error, err2, local;
> @@ -251,7 +250,6 @@ xfs_attr_set(
> rsvd ? XFS_TRANS_RESERVE : 0, &args.trans);
> if (error)
> return error;
> - xfs_defer_init(args.trans, &dfops);
>
> xfs_ilock(dp, XFS_ILOCK_EXCL);
> error = xfs_trans_reserve_quota_nblks(args.trans, dp, args.total, 0,
> @@ -315,18 +313,18 @@ xfs_attr_set(
> */
> error = xfs_attr_shortform_to_leaf(&args, &leaf_bp);
> if (error)
> - goto out_defer_cancel;
> + goto out;
> /*
> * Prevent the leaf buffer from being unlocked so that a
> * concurrent AIL push cannot grab the half-baked leaf
> * buffer and run into problems with the write verifier.
> */
> xfs_trans_bhold(args.trans, leaf_bp);
> - xfs_defer_bjoin(&dfops, leaf_bp);
> - xfs_defer_ijoin(&dfops, dp);
> - error = xfs_defer_finish(&args.trans, &dfops);
> + xfs_defer_bjoin(args.trans->t_dfops, leaf_bp);
> + xfs_defer_ijoin(args.trans->t_dfops, dp);
> + error = xfs_defer_finish(&args.trans, args.trans->t_dfops);
> if (error)
> - goto out_defer_cancel;
> + goto out;
>
> /*
> * Commit the leaf transformation. We'll need another (linked)
> @@ -366,8 +364,6 @@ xfs_attr_set(
>
> return error;
>
> -out_defer_cancel:
> - xfs_defer_cancel(&dfops);
> out:
> if (leaf_bp)
> xfs_trans_brelse(args.trans, leaf_bp);
> @@ -389,7 +385,6 @@ xfs_attr_remove(
> {
> struct xfs_mount *mp = dp->i_mount;
> struct xfs_da_args args;
> - struct xfs_defer_ops dfops;
> int error;
>
> XFS_STATS_INC(mp, xs_attr_remove);
> @@ -422,7 +417,6 @@ xfs_attr_remove(
> &args.trans);
> if (error)
> return error;
> - xfs_defer_init(args.trans, &dfops);
>
> xfs_ilock(dp, XFS_ILOCK_EXCL);
> /*
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH iproute2] devlink: CTRL_ATTR_FAMILY_ID is a u16
From: Stephen Hemminger @ 2018-07-23 20:51 UTC (permalink / raw)
To: dsahern; +Cc: netdev, jiri, David Ahern
In-Reply-To: <20180720163526.756-1-dsahern@kernel.org>
On Fri, 20 Jul 2018 09:35:26 -0700
dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> CTRL_ATTR_FAMILY_ID is a u16, not a u32. Update devlink accordingly.
>
> Fixes: a3c4b484a1edd ("add devlink tool")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied
^ permalink raw reply
* [PATCH v2 0/2] clk: qcom: Quad SPI (qspi) clock support for sdm845
From: Douglas Anderson @ 2018-07-23 21:54 UTC (permalink / raw)
To: sboyd, andy.gross
Cc: tdas, grahamr, girishm, anischal, bjorn.andersson,
Douglas Anderson, devicetree, Michael Turquette, linux-arm-msm,
linux-kernel, David Brown, Rob Herring, Mark Rutland, linux-soc,
linux-clk
This two-series patch adds the needed clock bits to use the Quad SPI
(qspi) part on sdm845. It's expected that the bindings part of this
patch could land in the clock tree with an immutable git hash and then
be pulled into the Qualcomm tree so it could be used by dts files.
From the reply to my v1, the clock plan for this clock is:
- MinSVS@19.2
- LowSVS@75
- SVS@150
- Nominal@300
...and intermediate frequencies can be used at frequences less than
300. I didn't see a need for 75 MHz and it was unclear from previous
replies if this should come from MAIN or EVEN so I left it out. I
have added 100 MHz here since it is useful (/ 4 = 25 MHz is a useful
clock for SPI flash)
OTHER NOTES:
- From probing lines, it appears that the Quad SPI block has a divide
by 4 somewhere inside it (probably so it can oversample the lines,
or possibly so it can generate phase-offset clocks). Thus we need
the core to go 4 times faster than we'd expect to run the SPI bus.
- SPI devices usually specify the MAX frequency they should be clocked
at, so it's important that we use the clk_rcg2_floor_ops here rather
than the clk_rcg2_ops
Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.
Douglas Anderson (2):
clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header
clk: qcom: Add qspi (Quad SPI) clocks for sdm845
drivers/clk/qcom/gcc-sdm845.c | 63 +++++++++++++++++++++
include/dt-bindings/clock/qcom,gcc-sdm845.h | 3 +
2 files changed, 66 insertions(+)
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply
* [PATCH v2 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845
From: Douglas Anderson @ 2018-07-23 21:54 UTC (permalink / raw)
To: sboyd, andy.gross
Cc: tdas, grahamr, girishm, anischal, bjorn.andersson,
Douglas Anderson, Michael Turquette, linux-arm-msm, linux-kernel,
David Brown, linux-soc, linux-clk
In-Reply-To: <20180723215404.74296-1-dianders@chromium.org>
Add both the interface and core clock.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.
drivers/clk/qcom/gcc-sdm845.c | 63 +++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index 0f694ed4238a..5bca634e277a 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -162,6 +162,13 @@ static const char * const gcc_parent_names_10[] = {
"core_bi_pll_test_se",
};
+static const char * const gcc_parent_names_9[] = {
+ "bi_tcxo",
+ "gpll0",
+ "gpll0_out_even",
+ "core_pi_sleep_clk",
+};
+
static struct clk_alpha_pll gpll0 = {
.offset = 0x0,
.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
@@ -358,6 +365,28 @@ static struct clk_rcg2 gcc_pcie_phy_refgen_clk_src = {
},
};
+static const struct freq_tbl ftbl_gcc_qspi_core_clk_src[] = {
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(100000000, P_GPLL0_OUT_MAIN, 6, 0, 0),
+ F(150000000, P_GPLL0_OUT_MAIN, 4, 0, 0),
+ F(300000000, P_GPLL0_OUT_MAIN, 2, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 gcc_qspi_core_clk_src = {
+ .cmd_rcgr = 0x4b008,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = gcc_parent_map_0,
+ .freq_tbl = ftbl_gcc_qspi_core_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gcc_qspi_core_clk_src",
+ .parent_names = gcc_parent_names_9,
+ .num_parents = 4,
+ .ops = &clk_rcg2_floor_ops,
+ },
+};
+
static const struct freq_tbl ftbl_gcc_pdm2_clk_src[] = {
F(9600000, P_BI_TCXO, 2, 0, 0),
F(19200000, P_BI_TCXO, 1, 0, 0),
@@ -1935,6 +1964,37 @@ static struct clk_branch gcc_qmip_video_ahb_clk = {
},
};
+static struct clk_branch gcc_qspi_cnoc_periph_ahb_clk = {
+ .halt_reg = 0x4b000,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x4b000,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_qspi_cnoc_periph_ahb_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gcc_qspi_core_clk = {
+ .halt_reg = 0x4b004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x4b004,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_qspi_core_clk",
+ .parent_names = (const char *[]){
+ "gcc_qspi_core_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_qupv3_wrap0_s0_clk = {
.halt_reg = 0x17030,
.halt_check = BRANCH_HALT_VOTED,
@@ -3383,6 +3443,9 @@ static struct clk_regmap *gcc_sdm845_clocks[] = {
[GPLL4] = &gpll4.clkr,
[GCC_CPUSS_DVM_BUS_CLK] = &gcc_cpuss_dvm_bus_clk.clkr,
[GCC_CPUSS_GNOC_CLK] = &gcc_cpuss_gnoc_clk.clkr,
+ [GCC_QSPI_CORE_CLK_SRC] = &gcc_qspi_core_clk_src.clkr,
+ [GCC_QSPI_CORE_CLK] = &gcc_qspi_core_clk.clkr,
+ [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = &gcc_qspi_cnoc_periph_ahb_clk.clkr,
};
static const struct qcom_reset_map gcc_sdm845_resets[] = {
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH v2 1/2] clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header
From: Douglas Anderson @ 2018-07-23 21:54 UTC (permalink / raw)
To: sboyd, andy.gross
Cc: tdas, grahamr, girishm, anischal, bjorn.andersson,
Douglas Anderson, devicetree, linux-kernel, Rob Herring,
Mark Rutland
In-Reply-To: <20180723215404.74296-1-dianders@chromium.org>
These clocks will need to be defined in the clock driver and
referenced in device tree files.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2: None
include/dt-bindings/clock/qcom,gcc-sdm845.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h b/include/dt-bindings/clock/qcom,gcc-sdm845.h
index f96fc2dbf60e..b8eae5a76503 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
@@ -194,6 +194,9 @@
#define GPLL4 184
#define GCC_CPUSS_DVM_BUS_CLK 185
#define GCC_CPUSS_GNOC_CLK 186
+#define GCC_QSPI_CORE_CLK_SRC 187
+#define GCC_QSPI_CORE_CLK 188
+#define GCC_QSPI_CNOC_PERIPH_AHB_CLK 189
/* GCC Resets */
#define GCC_MMSS_BCR 0
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* [PATCH v2 0/2] clk: qcom: Quad SPI (qspi) clock support for sdm845
From: Douglas Anderson @ 2018-07-23 21:54 UTC (permalink / raw)
To: sboyd, andy.gross
Cc: tdas, grahamr, girishm, anischal, bjorn.andersson,
Douglas Anderson, devicetree, Michael Turquette, linux-arm-msm,
linux-kernel, David Brown, Rob Herring, Mark Rutland, linux-soc,
linux-clk
This two-series patch adds the needed clock bits to use the Quad SPI
(qspi) part on sdm845. It's expected that the bindings part of this
patch could land in the clock tree with an immutable git hash and then
be pulled into the Qualcomm tree so it could be used by dts files.
>From the reply to my v1, the clock plan for this clock is:
- MinSVS@19.2
- LowSVS@75
- SVS@150
- Nominal@300
...and intermediate frequencies can be used at frequences less than
300. I didn't see a need for 75 MHz and it was unclear from previous
replies if this should come from MAIN or EVEN so I left it out. I
have added 100 MHz here since it is useful (/ 4 = 25 MHz is a useful
clock for SPI flash)
OTHER NOTES:
- From probing lines, it appears that the Quad SPI block has a divide
by 4 somewhere inside it (probably so it can oversample the lines,
or possibly so it can generate phase-offset clocks). Thus we need
the core to go 4 times faster than we'd expect to run the SPI bus.
- SPI devices usually specify the MAX frequency they should be clocked
at, so it's important that we use the clk_rcg2_floor_ops here rather
than the clk_rcg2_ops
Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.
Douglas Anderson (2):
clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header
clk: qcom: Add qspi (Quad SPI) clocks for sdm845
drivers/clk/qcom/gcc-sdm845.c | 63 +++++++++++++++++++++
include/dt-bindings/clock/qcom,gcc-sdm845.h | 3 +
2 files changed, 66 insertions(+)
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply
* Re: Documentation update wrt pci_release_regions()?
From: Bjorn Helgaas @ 2018-07-23 20:50 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Bjorn Helgaas, linux-pci
In-Reply-To: <e024134239091caf9684073887466df073ab1363.camel@linux.intel.com>
On Mon, Jul 23, 2018 at 01:36:43PM +0300, Andy Shevchenko wrote:
> Hi!
>
> At some point I have stumbled over [1] which has a rightful confusion.
> I tried to go through documentation we have and have no idea is that
> behaviour have been fixed or not and if yes, in which kernel version.
>
> Can we submit a patch against documentation to clarify the status of it?
> Followup would be fix of hfi1 driver to drop confusion.
>
> [1]: https://stackoverflow.com/questions/51163832/linux-pci-driver-setup
> -and-teardown
I would love it if somebody posted a patch to clarify this. I don't
have time to research and formulate a patch right now, but if you want
to propose something, or open a bugzilla so we don't forget, that
would be great.
The first fix would be to change the reference to
pci_request_regions(), which doesn't exist.
^ permalink raw reply
* Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
From: Yang Shi @ 2018-07-23 21:52 UTC (permalink / raw)
To: David Rientjes
Cc: Kirill A. Shutemov, hughd, aaron.lu, akpm, linux-mm, linux-kernel
In-Reply-To: <alpine.DEB.2.21.1807231329080.105582@chino.kir.corp.google.com>
On 7/23/18 1:31 PM, David Rientjes wrote:
> On Fri, 20 Jul 2018, Yang Shi wrote:
>
>> I agree to keep it for a while to let that security bug cool down, however, if
>> there is no user anymore, it sounds pointless to still keep a dead knob.
>>
> It's not a dead knob. We use it, and for reasons other than
> CVE-2017-1000405. To mitigate the cost of constantly compacting memory to
> allocate it after it has been freed due to memry pressure, we can either
> continue to disable it, allow it to be persistently available, or use a
> new value for use_zero_page to specify it should be persistently
> available.
My understanding is the cost of memory compaction is *not* unique for
huge zero page, right? It is expected when memory pressure is met, even
though huge zero page is disabled.
^ permalink raw reply
* [PATCH] drm/amdgpu: implement harvesting support for UVD 7.2 (v2)
From: Alex Deucher @ 2018-07-23 21:53 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Alex Deucher
Properly handle cases where one or more instance of the IP
block may be harvested.
v2: make sure ip_num_rings is initialized amdgpu_queue_mgr.c
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 ++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 13 +++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 11 +++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h | 5 +++
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 56 +++++++++++++++++++++++++--
5 files changed, 86 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 258b6f73cbdf..f4d379cd4e47 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -348,8 +348,11 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
break;
case AMDGPU_HW_IP_UVD:
type = AMD_IP_BLOCK_TYPE_UVD;
- for (i = 0; i < adev->uvd.num_uvd_inst; i++)
+ for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
ring_mask |= ((adev->uvd.inst[i].ring.ready ? 1 : 0) << i);
+ }
ib_start_alignment = 64;
ib_size_alignment = 64;
break;
@@ -362,11 +365,14 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
break;
case AMDGPU_HW_IP_UVD_ENC:
type = AMD_IP_BLOCK_TYPE_UVD;
- for (i = 0; i < adev->uvd.num_uvd_inst; i++)
+ for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
for (j = 0; j < adev->uvd.num_enc_rings; j++)
ring_mask |=
((adev->uvd.inst[i].ring_enc[j].ready ? 1 : 0) <<
(j + i * adev->uvd.num_enc_rings));
+ }
ib_start_alignment = 64;
ib_size_alignment = 64;
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
index ea9850c9224d..c59d3a2af388 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
@@ -219,7 +219,7 @@ int amdgpu_queue_mgr_map(struct amdgpu_device *adev,
u32 hw_ip, u32 instance, u32 ring,
struct amdgpu_ring **out_ring)
{
- int r, ip_num_rings;
+ int i, r, ip_num_rings = 0;
struct amdgpu_queue_mapper *mapper = &mgr->mapper[hw_ip];
if (!adev || !mgr || !out_ring)
@@ -248,14 +248,21 @@ int amdgpu_queue_mgr_map(struct amdgpu_device *adev,
ip_num_rings = adev->sdma.num_instances;
break;
case AMDGPU_HW_IP_UVD:
- ip_num_rings = adev->uvd.num_uvd_inst;
+ for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (!(adev->uvd.harvest_config & (1 << i)))
+ ip_num_rings++;
+ }
break;
case AMDGPU_HW_IP_VCE:
ip_num_rings = adev->vce.num_rings;
break;
case AMDGPU_HW_IP_UVD_ENC:
+ for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (!(adev->uvd.harvest_config & (1 << i)))
+ ip_num_rings++;
+ }
ip_num_rings =
- adev->uvd.num_enc_rings * adev->uvd.num_uvd_inst;
+ adev->uvd.num_enc_rings * ip_num_rings;
break;
case AMDGPU_HW_IP_VCN_DEC:
ip_num_rings = 1;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 80b5c453f8c1..a07548c99ab8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -255,7 +255,8 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
bo_size += AMDGPU_GPU_PAGE_ALIGN(le32_to_cpu(hdr->ucode_size_bytes) + 8);
for (j = 0; j < adev->uvd.num_uvd_inst; j++) {
-
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
r = amdgpu_bo_create_kernel(adev, bo_size, PAGE_SIZE,
AMDGPU_GEM_DOMAIN_VRAM, &adev->uvd.inst[j].vcpu_bo,
&adev->uvd.inst[j].gpu_addr, &adev->uvd.inst[j].cpu_addr);
@@ -309,6 +310,8 @@ int amdgpu_uvd_sw_fini(struct amdgpu_device *adev)
&adev->uvd.entity);
for (j = 0; j < adev->uvd.num_uvd_inst; ++j) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
kfree(adev->uvd.inst[j].saved_bo);
amdgpu_bo_free_kernel(&adev->uvd.inst[j].vcpu_bo,
@@ -344,6 +347,8 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev)
}
for (j = 0; j < adev->uvd.num_uvd_inst; ++j) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
if (adev->uvd.inst[j].vcpu_bo == NULL)
continue;
@@ -366,6 +371,8 @@ int amdgpu_uvd_resume(struct amdgpu_device *adev)
int i;
for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
if (adev->uvd.inst[i].vcpu_bo == NULL)
return -EINVAL;
@@ -1160,6 +1167,8 @@ static void amdgpu_uvd_idle_work_handler(struct work_struct *work)
unsigned fences = 0, i, j;
for (i = 0; i < adev->uvd.num_uvd_inst; ++i) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
fences += amdgpu_fence_count_emitted(&adev->uvd.inst[i].ring);
for (j = 0; j < adev->uvd.num_enc_rings; ++j) {
fences += amdgpu_fence_count_emitted(&adev->uvd.inst[i].ring_enc[j]);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h
index 66872286ab12..9cf42454ba81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h
@@ -46,8 +46,12 @@ struct amdgpu_uvd_inst {
struct amdgpu_ring ring_enc[AMDGPU_MAX_UVD_ENC_RINGS];
struct amdgpu_irq_src irq;
uint32_t srbm_soft_reset;
+ uint32_t instance;
};
+#define AMDGPU_UVD_HARVEST_UVD0 (1 << 0)
+#define AMDGPU_UVD_HARVEST_UVD1 (1 << 1)
+
struct amdgpu_uvd {
const struct firmware *fw; /* UVD firmware */
unsigned fw_version;
@@ -61,6 +65,7 @@ struct amdgpu_uvd {
atomic_t handles[AMDGPU_MAX_UVD_HANDLES];
struct drm_sched_entity entity;
struct delayed_work idle_work;
+ unsigned harvest_config;
};
int amdgpu_uvd_sw_init(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
index db5f3d78ab12..8179317be750 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
@@ -41,6 +41,12 @@
#include "mmhub/mmhub_1_0_sh_mask.h"
#include "ivsrcid/uvd/irqsrcs_uvd_7_0.h"
+#define mmUVD_PG0_CC_UVD_HARVESTING 0x00c7
+#define mmUVD_PG0_CC_UVD_HARVESTING_BASE_IDX 1
+//UVD_PG0_CC_UVD_HARVESTING
+#define UVD_PG0_CC_UVD_HARVESTING__UVD_DISABLE__SHIFT 0x1
+#define UVD_PG0_CC_UVD_HARVESTING__UVD_DISABLE_MASK 0x00000002L
+
#define UVD7_MAX_HW_INSTANCES_VEGA20 2
static void uvd_v7_0_set_ring_funcs(struct amdgpu_device *adev);
@@ -370,10 +376,25 @@ static int uvd_v7_0_enc_ring_test_ib(struct amdgpu_ring *ring, long timeout)
static int uvd_v7_0_early_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- if (adev->asic_type == CHIP_VEGA20)
+
+ if (adev->asic_type == CHIP_VEGA20) {
+ u32 harvest;
+ int i;
+
adev->uvd.num_uvd_inst = UVD7_MAX_HW_INSTANCES_VEGA20;
- else
+ for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ harvest = RREG32_SOC15(UVD, i, mmUVD_PG0_CC_UVD_HARVESTING);
+ if (harvest & UVD_PG0_CC_UVD_HARVESTING__UVD_DISABLE_MASK) {
+ adev->uvd.harvest_config |= 1 << i;
+ }
+ }
+ if (adev->uvd.harvest_config == (AMDGPU_UVD_HARVEST_UVD0 |
+ AMDGPU_UVD_HARVEST_UVD1))
+ /* both instances are harvested, disable the block */
+ return -ENOENT;
+ } else {
adev->uvd.num_uvd_inst = 1;
+ }
if (amdgpu_sriov_vf(adev))
adev->uvd.num_enc_rings = 1;
@@ -393,6 +414,8 @@ static int uvd_v7_0_sw_init(void *handle)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
for (j = 0; j < adev->uvd.num_uvd_inst; j++) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
/* UVD TRAP */
r = amdgpu_irq_add_id(adev, amdgpu_ih_clientid_uvds[j], UVD_7_0__SRCID__UVD_SYSTEM_MESSAGE_INTERRUPT, &adev->uvd.inst[j].irq);
if (r)
@@ -425,6 +448,8 @@ static int uvd_v7_0_sw_init(void *handle)
return r;
for (j = 0; j < adev->uvd.num_uvd_inst; j++) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
if (!amdgpu_sriov_vf(adev)) {
ring = &adev->uvd.inst[j].ring;
sprintf(ring->name, "uvd<%d>", j);
@@ -472,6 +497,8 @@ static int uvd_v7_0_sw_fini(void *handle)
return r;
for (j = 0; j < adev->uvd.num_uvd_inst; ++j) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
for (i = 0; i < adev->uvd.num_enc_rings; ++i)
amdgpu_ring_fini(&adev->uvd.inst[j].ring_enc[i]);
}
@@ -500,6 +527,8 @@ static int uvd_v7_0_hw_init(void *handle)
goto done;
for (j = 0; j < adev->uvd.num_uvd_inst; ++j) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
ring = &adev->uvd.inst[j].ring;
if (!amdgpu_sriov_vf(adev)) {
@@ -579,8 +608,11 @@ static int uvd_v7_0_hw_fini(void *handle)
DRM_DEBUG("For SRIOV client, shouldn't do anything.\n");
}
- for (i = 0; i < adev->uvd.num_uvd_inst; ++i)
+ for (i = 0; i < adev->uvd.num_uvd_inst; ++i) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
adev->uvd.inst[i].ring.ready = false;
+ }
return 0;
}
@@ -623,6 +655,8 @@ static void uvd_v7_0_mc_resume(struct amdgpu_device *adev)
int i;
for (i = 0; i < adev->uvd.num_uvd_inst; ++i) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
WREG32_SOC15(UVD, i, mmUVD_LMI_VCPU_CACHE_64BIT_BAR_LOW,
lower_32_bits(adev->firmware.ucode[AMDGPU_UCODE_ID_UVD].mc_addr));
@@ -695,6 +729,8 @@ static int uvd_v7_0_mmsch_start(struct amdgpu_device *adev,
WREG32_SOC15(VCE, 0, mmVCE_MMSCH_VF_MAILBOX_RESP, 0);
for (i = 0; i < adev->uvd.num_uvd_inst; ++i) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
WDOORBELL32(adev->uvd.inst[i].ring_enc[0].doorbell_index, 0);
adev->wb.wb[adev->uvd.inst[i].ring_enc[0].wptr_offs] = 0;
adev->uvd.inst[i].ring_enc[0].wptr = 0;
@@ -751,6 +787,8 @@ static int uvd_v7_0_sriov_start(struct amdgpu_device *adev)
init_table += header->uvd_table_offset;
for (i = 0; i < adev->uvd.num_uvd_inst; ++i) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
ring = &adev->uvd.inst[i].ring;
ring->wptr = 0;
size = AMDGPU_GPU_PAGE_ALIGN(adev->uvd.fw->size + 4);
@@ -890,6 +928,8 @@ static int uvd_v7_0_start(struct amdgpu_device *adev)
int i, j, k, r;
for (k = 0; k < adev->uvd.num_uvd_inst; ++k) {
+ if (adev->uvd.harvest_config & (1 << k))
+ continue;
/* disable DPG */
WREG32_P(SOC15_REG_OFFSET(UVD, k, mmUVD_POWER_STATUS), 0,
~UVD_POWER_STATUS__UVD_PG_MODE_MASK);
@@ -902,6 +942,8 @@ static int uvd_v7_0_start(struct amdgpu_device *adev)
uvd_v7_0_mc_resume(adev);
for (k = 0; k < adev->uvd.num_uvd_inst; ++k) {
+ if (adev->uvd.harvest_config & (1 << k))
+ continue;
ring = &adev->uvd.inst[k].ring;
/* disable clock gating */
WREG32_P(SOC15_REG_OFFSET(UVD, k, mmUVD_CGC_CTRL), 0,
@@ -1069,6 +1111,8 @@ static void uvd_v7_0_stop(struct amdgpu_device *adev)
uint8_t i = 0;
for (i = 0; i < adev->uvd.num_uvd_inst; ++i) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
/* force RBC into idle state */
WREG32_SOC15(UVD, i, mmUVD_RBC_RB_CNTL, 0x11010101);
@@ -1756,6 +1800,8 @@ static void uvd_v7_0_set_ring_funcs(struct amdgpu_device *adev)
int i;
for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
adev->uvd.inst[i].ring.funcs = &uvd_v7_0_ring_vm_funcs;
adev->uvd.inst[i].ring.me = i;
DRM_INFO("UVD(%d) is enabled in VM mode\n", i);
@@ -1767,6 +1813,8 @@ static void uvd_v7_0_set_enc_ring_funcs(struct amdgpu_device *adev)
int i, j;
for (j = 0; j < adev->uvd.num_uvd_inst; j++) {
+ if (adev->uvd.harvest_config & (1 << j))
+ continue;
for (i = 0; i < adev->uvd.num_enc_rings; ++i) {
adev->uvd.inst[j].ring_enc[i].funcs = &uvd_v7_0_enc_ring_vm_funcs;
adev->uvd.inst[j].ring_enc[i].me = j;
@@ -1786,6 +1834,8 @@ static void uvd_v7_0_set_irq_funcs(struct amdgpu_device *adev)
int i;
for (i = 0; i < adev->uvd.num_uvd_inst; i++) {
+ if (adev->uvd.harvest_config & (1 << i))
+ continue;
adev->uvd.inst[i].irq.num_types = adev->uvd.num_enc_rings + 1;
adev->uvd.inst[i].irq.funcs = &uvd_v7_0_irq_funcs;
}
--
2.13.6
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH v2 09/15] xfs: use internal dfops in cow blocks cancel
From: Bill O'Donnell @ 2018-07-23 20:49 UTC (permalink / raw)
To: Brian Foster; +Cc: linux-xfs
In-Reply-To: <20180723130414.47980-10-bfoster@redhat.com>
On Mon, Jul 23, 2018 at 09:04:08AM -0400, Brian Foster wrote:
> All callers either explicitly initialize a dfops or pass a
> transaction with an internal dfops. Drop the hacky old dfops
> replacement logic and use the one associated with the transaction.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
Looks good.
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
> ---
> fs/xfs/xfs_reflink.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
> index 3143889097f1..c3f2a0d3e6f5 100644
> --- a/fs/xfs/xfs_reflink.c
> +++ b/fs/xfs/xfs_reflink.c
> @@ -483,8 +483,6 @@ xfs_reflink_cancel_cow_blocks(
> struct xfs_ifork *ifp = XFS_IFORK_PTR(ip, XFS_COW_FORK);
> struct xfs_bmbt_irec got, del;
> struct xfs_iext_cursor icur;
> - struct xfs_defer_ops dfops;
> - struct xfs_defer_ops *odfops = (*tpp)->t_dfops;
> int error = 0;
>
> if (!xfs_is_reflink_inode(ip))
> @@ -511,7 +509,8 @@ xfs_reflink_cancel_cow_blocks(
> if (error)
> break;
> } else if (del.br_state == XFS_EXT_UNWRITTEN || cancel_real) {
> - xfs_defer_init(*tpp, &dfops);
> + ASSERT((*tpp)->t_dfops);
> + ASSERT((*tpp)->t_firstblock == NULLFSBLOCK);
>
> /* Free the CoW orphan record. */
> error = xfs_refcount_free_cow_extent(ip->i_mount,
> @@ -553,7 +552,6 @@ xfs_reflink_cancel_cow_blocks(
> /* clear tag if cow fork is emptied */
> if (!ifp->if_bytes)
> xfs_inode_clear_cowblocks_tag(ip);
> - (*tpp)->t_dfops = odfops;
> return error;
> }
>
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] PCI: Check for PCIe downtraining conditions
From: Tal Gilboa @ 2018-07-23 21:52 UTC (permalink / raw)
To: Jakub Kicinski, Alexandru Gagniuc
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com,
keith.busch@intel.com, alex_gagniuc@dellteam.com,
austin_bolen@dell.com, shyam_iyer@dell.com,
jeffrey.t.kirsher@intel.com, ariel.elior@cavium.com,
michael.chan@broadcom.com, ganeshgr@chelsio.com, Tariq Toukan,
airlied@gmail.com, alexander.deucher@amd.com,
mike.marciniszyn@intel.com, linux-kernel@vger.kernel.org
In-Reply-To: <20180723140143.1a46902f@cakuba.netronome.com>
On 7/24/2018 12:01 AM, Jakub Kicinski wrote:
> On Mon, 23 Jul 2018 15:03:38 -0500, Alexandru Gagniuc wrote:
>> PCIe downtraining happens when both the device and PCIe port are
>> capable of a larger bus width or higher speed than negotiated.
>> Downtraining might be indicative of other problems in the system, and
>> identifying this from userspace is neither intuitive, nor
>> straightforward.
>>
>> The easiest way to detect this is with pcie_print_link_status(),
>> since the bottleneck is usually the link that is downtrained. It's not
>> a perfect solution, but it works extremely well in most cases.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>> ---
>>
>> For the sake of review, I've created a __pcie_print_link_status() which
>> takes a 'verbose' argument. If we agree want to go this route, and update
>> the users of pcie_print_link_status(), I can split this up in two patches.
>> I prefer just printing this information in the core functions, and letting
>> drivers not have to worry about this. Though there seems to be strong for
>> not going that route, so here it goes:
>
> FWIW the networking drivers print PCIe BW because sometimes the network
> bandwidth is simply over-provisioned on multi port cards, e.g. 80Gbps
> card on a x8 link.
>
> Sorry to bike shed, but currently the networking cards print the info
> during probe. Would it make sense to move your message closer to probe
> time? Rather than when device is added. If driver structure is
> available, we could also consider adding a boolean to struct pci_driver
> to indicate if driver wants the verbose message? This way we avoid
> duplicated prints.
>
> I have no objection to current patch, it LGTM. Just a thought.
I don't see the reason for having two functions. What's the problem with
adding the verbose argument to the original function?
>
>> drivers/pci/pci.c | 22 ++++++++++++++++++----
>> drivers/pci/probe.c | 21 +++++++++++++++++++++
>> include/linux/pci.h | 1 +
>> 3 files changed, 40 insertions(+), 4 deletions(-) >>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 316496e99da9..414ad7b3abdb 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -5302,14 +5302,15 @@ u32 pcie_bandwidth_capable(struct pci_dev *dev, enum pci_bus_speed *speed,
>> }
>>
>> /**
>> - * pcie_print_link_status - Report the PCI device's link speed and width
>> + * __pcie_print_link_status - Report the PCI device's link speed and width
>> * @dev: PCI device to query
>> + * @verbose: Be verbose -- print info even when enough bandwidth is available.
>> *
>> * Report the available bandwidth at the device. If this is less than the
>> * device is capable of, report the device's maximum possible bandwidth and
>> * the upstream link that limits its performance to less than that.
>> */
>> -void pcie_print_link_status(struct pci_dev *dev)
>> +void __pcie_print_link_status(struct pci_dev *dev, bool verbose)
>> {
>> enum pcie_link_width width, width_cap;
>> enum pci_bus_speed speed, speed_cap;
>> @@ -5319,11 +5320,11 @@ void pcie_print_link_status(struct pci_dev *dev)
>> bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap);
>> bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width);
>>
>> - if (bw_avail >= bw_cap)
>> + if (bw_avail >= bw_cap && verbose)
>> pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d link)\n",
>> bw_cap / 1000, bw_cap % 1000,
>> PCIE_SPEED2STR(speed_cap), width_cap);
>> - else
>> + else if (bw_avail < bw_cap)
>> pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
>> bw_avail / 1000, bw_avail % 1000,
>> PCIE_SPEED2STR(speed), width,
>> @@ -5331,6 +5332,19 @@ void pcie_print_link_status(struct pci_dev *dev)
>> bw_cap / 1000, bw_cap % 1000,
>> PCIE_SPEED2STR(speed_cap), width_cap);
>> }
>> +
>> +/**
>> + * pcie_print_link_status - Report the PCI device's link speed and width
>> + * @dev: PCI device to query
>> + *
>> + * Report the available bandwidth at the device. If this is less than the
>> + * device is capable of, report the device's maximum possible bandwidth and
>> + * the upstream link that limits its performance to less than that.
>> + */
>> +void pcie_print_link_status(struct pci_dev *dev)
>> +{
>> + __pcie_print_link_status(dev, true);
>> +}
>> EXPORT_SYMBOL(pcie_print_link_status);
>>
>> /**
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index ac876e32de4b..1f7336377c3b 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -2205,6 +2205,24 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn)
>> return dev;
>> }
>>
>> +static void pcie_check_upstream_link(struct pci_dev *dev)
>> +{
>> + if (!pci_is_pcie(dev))
>> + return;
>> +
>> + /* Look from the device up to avoid downstream ports with no devices. */
>> + if ((pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT) &&
>> + (pci_pcie_type(dev) != PCI_EXP_TYPE_LEG_END) &&
>> + (pci_pcie_type(dev) != PCI_EXP_TYPE_UPSTREAM))
>> + return;
>> +
>> + /* Multi-function PCIe share the same link/status. */
>> + if (PCI_FUNC(dev->devfn) != 0 || dev->is_virtfn)
>> + return;
>> +
>> + __pcie_print_link_status(dev, false);
>> +}
>> +
>> static void pci_init_capabilities(struct pci_dev *dev)
>> {
>> /* Enhanced Allocation */
>> @@ -2240,6 +2258,9 @@ static void pci_init_capabilities(struct pci_dev *dev)
>> /* Advanced Error Reporting */
>> pci_aer_init(dev);
>>
>> + /* Check link and detect downtrain errors */
>> + pcie_check_upstream_link(dev);
This is called for every PCIe device right? Won't there be a duplicated
print in case a device loads with lower PCIe bandwidth than needed?
>> +
>> if (pci_probe_reset_function(dev) == 0)
>> dev->reset_fn = 1;
>> }
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index abd5d5e17aee..15bfab8f7a1b 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -1088,6 +1088,7 @@ int pcie_set_mps(struct pci_dev *dev, int mps);
>> u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
>> enum pci_bus_speed *speed,
>> enum pcie_link_width *width);
>> +void __pcie_print_link_status(struct pci_dev *dev, bool verbose);
>> void pcie_print_link_status(struct pci_dev *dev);
>> int pcie_flr(struct pci_dev *dev);
>> int __pci_reset_function_locked(struct pci_dev *dev);
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.