* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Horia Geantă @ 2018-02-19 13:16 UTC (permalink / raw)
To: Christophe LEROY, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <d5809df9-fc17-03da-b7f4-038d973dbd1f@c-s.fr>
On 2/19/2018 11:14 AM, Christophe LEROY wrote:=0A=
> Le 19/02/2018 =E0 09:30, Horia Geant=E3 a =E9crit=A0:=0A=
>> On 2/19/2018 9:58 AM, Christophe LEROY wrote:=0A=
>>> Le 18/02/2018 =E0 18:14, Horia Geant=E3 a =E9crit=A0:=0A=
>>>> There is no ahash_exit() callback mirroring ahash_init().=0A=
>>>>=0A=
>>>> The clean-up of request ctx should be done in the last states of the h=
ash flows=0A=
>>>> described here:=0A=
>>>> https://www.kernel.org/doc/html/latest/crypto/devel-algos.html#cipher-=
definition-with-struct-shash-alg-and-ahash-alg=0A=
>>>> for e.g. in the final() callback.=0A=
>>>=0A=
>>> Unfortunatly it seems that we can't rely on those finalising functions=
=0A=
>>> being called all the time.=0A=
>>> If you look into test_ahash_jiffies() for instance, in case of error th=
e=0A=
>>> call of crypto_hash_final() is skipped.=0A=
>>=0A=
>> If test_ahash_jiffies() errors before calling crypto_ahash_final(req), t=
his=0A=
>> means a previous callback failed.=0A=
>> Accordingly, DMA unmapping should be performed also on the corresponding=
errors=0A=
>> paths in the driver.=0A=
>>=0A=
> =0A=
> And what about ALGIF path from user space ?=0A=
> What if the user never calls the last sendmsg() which will call =0A=
> hash_finup() ?=0A=
> =0A=
User is expected to follow the rules of the crypto API.=0A=
Of course, kernel won't (or at least shouldn't) crash in case of misuse.=0A=
However, in these cases some resources might not be freed - it's unavoidabl=
e.=0A=
=0A=
Horia=0A=
^ permalink raw reply
* [PATCH] powerpc: Use generic pci_mmap_resource_range()
From: David Woodhouse @ 2018-02-19 12:59 UTC (permalink / raw)
To: mpe, benh, bhelgaas, linuxppc-dev, linux-kernel, linux-pci
Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for
ARM64") added this generic function with the intent of using it
everywhere and ultimately killing the old arch-specific implementations.
Let's get on with that eradication...
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/powerpc/include/asm/pci.h | 9 ++--
arch/powerpc/kernel/pci-common.c | 106 ++++-----------------------------------
2 files changed, 15 insertions(+), 100 deletions(-)
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index d82802f..401c62a 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -76,10 +76,11 @@ extern int pci_proc_domain(struct pci_bus *bus);
struct vm_area_struct;
-/* Tell drivers/pci/proc.c that we have pci_mmap_page_range() and it does WC */
-#define HAVE_PCI_MMAP 1
-#define arch_can_pci_mmap_io() 1
-#define arch_can_pci_mmap_wc() 1
+/* Tell PCI code what kind of PCI resource mappings we support */
+#define HAVE_PCI_MMAP 1
+#define ARCH_GENERIC_PCI_MMAP_RESOURCE 1
+#define arch_can_pci_mmap_io() 1
+#define arch_can_pci_mmap_wc() 1
extern int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val,
size_t count);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 446c796..fe9733f 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -410,72 +410,22 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
}
/*
- * Platform support for /proc/bus/pci/X/Y mmap()s,
- * modelled on the sparc64 implementation by Dave Miller.
+ * Platform support for /proc/bus/pci/X/Y mmap()s.
* -- paulus.
*/
-
-/*
- * Adjust vm_pgoff of VMA such that it is the physical page offset
- * corresponding to the 32-bit pci bus offset for DEV requested by the user.
- *
- * Basically, the user finds the base address for his device which he wishes
- * to mmap. They read the 32-bit value from the config space base register,
- * add whatever PAGE_SIZE multiple offset they wish, and feed this into the
- * offset parameter of mmap on /proc/bus/pci/XXX for that device.
- *
- * Returns negative error code on failure, zero on success.
- */
-static struct resource *__pci_mmap_make_offset(struct pci_dev *dev,
- resource_size_t *offset,
- enum pci_mmap_state mmap_state)
+int pci_iobar_pfn(struct pci_dev *pdev, int bar, struct vm_area_struct *vma)
{
- struct pci_controller *hose = pci_bus_to_host(dev->bus);
- unsigned long io_offset = 0;
- int i, res_bit;
-
- if (hose == NULL)
- return NULL; /* should never happen */
-
- /* If memory, add on the PCI bridge address offset */
- if (mmap_state == pci_mmap_mem) {
-#if 0 /* See comment in pci_resource_to_user() for why this is disabled */
- *offset += hose->pci_mem_offset;
-#endif
- res_bit = IORESOURCE_MEM;
- } else {
- io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
- *offset += io_offset;
- res_bit = IORESOURCE_IO;
- }
-
- /*
- * Check that the offset requested corresponds to one of the
- * resources of the device.
- */
- for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
- struct resource *rp = &dev->resource[i];
- int flags = rp->flags;
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ resource_size_t ioaddr = pci_resource_start(pdev, bar);
- /* treat ROM as memory (should be already) */
- if (i == PCI_ROM_RESOURCE)
- flags |= IORESOURCE_MEM;
-
- /* Active and same type? */
- if ((flags & res_bit) == 0)
- continue;
-
- /* In the range of this resource? */
- if (*offset < (rp->start & PAGE_MASK) || *offset > rp->end)
- continue;
+ if (!hose)
+ return -EINVAL;
- /* found it! construct the final physical address */
- if (mmap_state == pci_mmap_io)
- *offset += hose->io_base_phys - io_offset;
- return rp;
- }
+ /* Convert to an offset within this PCI controller */
+ ioaddr -= (unsigned long)hose->io_base_virt - _IO_BASE;
- return NULL;
+ vma->vm_pgoff += (ioaddr + hose->io_base_phys) >> PAGE_SHIFT;
+ return 0;
}
/*
@@ -527,42 +477,6 @@ pgprot_t pci_phys_mem_access_prot(struct file *file,
return prot;
}
-
-/*
- * Perform the actual remap of the pages for a PCI device mapping, as
- * appropriate for this architecture. The region in the process to map
- * is described by vm_start and vm_end members of VMA, the base physical
- * address is found in vm_pgoff.
- * The pci device structure is provided so that architectures may make mapping
- * decisions on a per-device or per-bus basis.
- *
- * Returns a negative error code on failure, zero on success.
- */
-int pci_mmap_page_range(struct pci_dev *dev, int bar,
- struct vm_area_struct *vma,
- enum pci_mmap_state mmap_state, int write_combine)
-{
- resource_size_t offset =
- ((resource_size_t)vma->vm_pgoff) << PAGE_SHIFT;
- struct resource *rp;
- int ret;
-
- rp = __pci_mmap_make_offset(dev, &offset, mmap_state);
- if (rp == NULL)
- return -EINVAL;
-
- vma->vm_pgoff = offset >> PAGE_SHIFT;
- if (write_combine)
- vma->vm_page_prot = pgprot_noncached_wc(vma->vm_page_prot);
- else
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-
- ret = remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
- vma->vm_end - vma->vm_start, vma->vm_page_prot);
-
- return ret;
-}
-
/* This provides legacy IO read access on a bus */
int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val, size_t size)
{
--
2.7.4
^ permalink raw reply related
* [PATCH V4] cxl: Fix timebase synchronization status on P9
From: Christophe Lombard @ 2018-02-19 12:59 UTC (permalink / raw)
To: linuxppc-dev, fbarrat, vaibhav, andrew.donnellan
The PSL Timebase register is updated by the PSL to maintain the
timebase.
On P9, the Timebase value is only provided by the CAPP as received
the last time a timebase request was performed.
The timebase requests are initiated through the adapter configuration or
application registers.
The specific sysfs entry "/sys/class/cxl/cardxx/psl_timebase_synced" is
now dynamically updated according the content of the PSL Timebase
register.
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
---
This patch applies on top of this patch:
http://patchwork.ozlabs.org/patch/873663/
Changelog[v4]
- Rebased to latest upstream.
- Added log message.
Changelog[v3]
- Rebased to latest upstream.
- Dynamic update is now applied to P8.
Changelog[v2]
- Missing Signed-off-by.
- Spaces required around the ':'.
---
drivers/misc/cxl/pci.c | 17 -----------------
drivers/misc/cxl/sysfs.c | 11 +++++++++++
2 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 66eed6a..3247eaf 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -606,9 +606,6 @@ static u64 timebase_read_xsl(struct cxl *adapter)
static void cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
{
- u64 psl_tb;
- int delta;
- unsigned int retry = 0;
struct device_node *np;
adapter->psl_timebase_synced = false;
@@ -636,20 +633,6 @@ static void cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
cxl_p1_write(adapter, CXL_PSL_Control, 0x0000000000000000);
cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);
- /* Wait until CORE TB and PSL TB difference <= 16usecs */
- do {
- msleep(1);
- if (retry++ > 5) {
- dev_info(&dev->dev, "PSL timebase can't synchronize\n");
- return;
- }
- psl_tb = adapter->native->sl_ops->timebase_read(adapter);
- delta = mftb() - psl_tb;
- if (delta < 0)
- delta = -delta;
- } while (tb_to_ns(delta) > 16000);
-
- adapter->psl_timebase_synced = true;
return;
}
diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index a8b6d6a..a816b93 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -62,6 +62,17 @@ static ssize_t psl_timebase_synced_show(struct device *device,
char *buf)
{
struct cxl *adapter = to_cxl_adapter(device);
+ u64 psl_tb;
+ int delta;
+
+ psl_tb = adapter->native->sl_ops->timebase_read(adapter);
+ delta = abs(mftb() - psl_tb);
+
+ /* CORE TB and PSL TB difference <= 16usecs ? */
+ adapter->psl_timebase_synced = (tb_to_ns(delta) < 16000) ? true : false;
+ pr_devel("PSL timebase %s - delta: 0x%016llx\n",
+ (tb_to_ns(delta) < 16000) ? "synchronized" :
+ "not synchronized", tb_to_ns(delta));
return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->psl_timebase_synced);
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH V3] cxl: Fix timebase synchronization status on P9
From: christophe lombard @ 2018-02-19 10:15 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, fbarrat, andrew.donnellan
In-Reply-To: <87woz9h5lp.fsf@vajain21.in.ibm.com>
Le 19/02/2018 à 07:10, Vaibhav Jain a écrit :
>
> Hi Christophe,
>
> Mostly ok with this patch. Some very minor review comments:
>
> Christophe Lombard <clombard@linux.vnet.ibm.com> writes:
>> --- a/drivers/misc/cxl/sysfs.c
>> +++ b/drivers/misc/cxl/sysfs.c
>> @@ -62,6 +62,16 @@ static ssize_t psl_timebase_synced_show(struct device *device,
>> char *buf)
>> {
>> struct cxl *adapter = to_cxl_adapter(device);
>> + u64 psl_tb;
>> + int delta;
>> +
>> + psl_tb = adapter->native->sl_ops->timebase_read(adapter);
>> + delta = mftb() - psl_tb;
>> + if (delta < 0)
>> + delta = -delta;
> Can just use abs().
okay, I can.
>> +
>> + /* CORE TB and PSL TB difference <= 16usecs ? */
>> + adapter->psl_timebase_synced = (tb_to_ns(delta) < 16000) ? true : false;
> Can be re-written as
> 'adapter->psl_timebase_synced = (tb_to_ns(abs(delta)) < 16000);'
I prefer to keep the original version for easier reading.
>
>>
>> return scnprintf(buf, PAGE_SIZE, "%i\n",
>> adapter->psl_timebase_synced);
> Might be a good idea to debug print/print_once the delta.
sounds good.
>
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Christophe LEROY @ 2018-02-19 9:14 UTC (permalink / raw)
To: Horia Geantă, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR0402MB334256E1706A4E1AED09F4A598C80@VI1PR0402MB3342.eurprd04.prod.outlook.com>
Le 19/02/2018 à 09:30, Horia Geantă a écrit :
> On 2/19/2018 9:58 AM, Christophe LEROY wrote:
>> Le 18/02/2018 à 18:14, Horia Geantă a écrit :
>>> There is no ahash_exit() callback mirroring ahash_init().
>>>
>>> The clean-up of request ctx should be done in the last states of the hash flows
>>> described here:
>>> https://www.kernel.org/doc/html/latest/crypto/devel-algos.html#cipher-definition-with-struct-shash-alg-and-ahash-alg
>>> for e.g. in the final() callback.
>>
>> Unfortunatly it seems that we can't rely on those finalising functions
>> being called all the time.
>> If you look into test_ahash_jiffies() for instance, in case of error the
>> call of crypto_hash_final() is skipped.
>
> If test_ahash_jiffies() errors before calling crypto_ahash_final(req), this
> means a previous callback failed.
> Accordingly, DMA unmapping should be performed also on the corresponding errors
> paths in the driver.
>
And what about ALGIF path from user space ?
What if the user never calls the last sendmsg() which will call
hash_finup() ?
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off
From: Michael Ellerman @ 2018-02-19 8:36 UTC (permalink / raw)
To: Vaibhav Jain, Balbir Singh
Cc: linux-kernel@vger.kernel.org, Nicholas Piggin, Paul Mackerras,
Douglas Miller, Pan Xinhui,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <87d116wy6g.fsf@vajain21.in.ibm.com>
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> writes:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>> <snip>
<snip>
>>
>> What would be nice is if we keep that behaviour, but any action you take
>> in xmon that requires xmon to remain resident, ie. setting a breakpoint,
>> calls a function which makes sure xmon_on = true and if it wasn't prints
>> a nice message saying "Turning xmon on due to breakpoint insertion" or
>> something.
> That makes sense to me and sounds workable. However we already have a
> debugfs interface to enable/disable xmon debugger hook. I can also tweak
> this interface to also register the sysrq key when xmon is enabled. This
> should provide the user the ability to still use xmon if they want to
> after the system has booted with xmon=off.
I agree that sounds sensible, but it has one fatal flaw IMO.
Currently you can boot a box with XMON_DEFAULT=n, and it will crash dump
and so on, but if the box gets stuck you can jump on the console and
drop into xmon with sysrq-x.
If we additionally require xmon to be enabled via debugfs every boot
that will break the above use case, and I don't want to do that.
So in short I think I like my idea better :)
cheers
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Horia Geantă @ 2018-02-19 8:30 UTC (permalink / raw)
To: Christophe LEROY, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <630c313c-5eca-224d-a5ac-fb3f2783573a@c-s.fr>
On 2/19/2018 9:58 AM, Christophe LEROY wrote:=0A=
> Le 18/02/2018 =E0 18:14, Horia Geant=E3 a =E9crit=A0:=0A=
>> There is no ahash_exit() callback mirroring ahash_init().=0A=
>>=0A=
>> The clean-up of request ctx should be done in the last states of the has=
h flows=0A=
>> described here:=0A=
>> https://www.kernel.org/doc/html/latest/crypto/devel-algos.html#cipher-de=
finition-with-struct-shash-alg-and-ahash-alg=0A=
>> for e.g. in the final() callback.=0A=
> =0A=
> Unfortunatly it seems that we can't rely on those finalising functions =
=0A=
> being called all the time.=0A=
> If you look into test_ahash_jiffies() for instance, in case of error the =
=0A=
> call of crypto_hash_final() is skipped.=0A=
=0A=
If test_ahash_jiffies() errors before calling crypto_ahash_final(req), this=
=0A=
means a previous callback failed.=0A=
Accordingly, DMA unmapping should be performed also on the corresponding er=
rors=0A=
paths in the driver.=0A=
=0A=
Horia=0A=
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Christophe LEROY @ 2018-02-19 7:58 UTC (permalink / raw)
To: Horia Geantă, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR0402MB3342D90D574C8829701882BE98C90@VI1PR0402MB3342.eurprd04.prod.outlook.com>
Le 18/02/2018 à 18:14, Horia Geantă a écrit :
> On 2/17/2018 6:32 PM, Christophe LEROY wrote:
>>
>>
>> Le 07/02/2018 à 15:39, Horia Geantă a écrit :
>>> On 10/6/2017 4:06 PM, Christophe Leroy wrote:
>>>> At every request, we map and unmap the same hash hw_context.
>>>>
>>>> This patch moves the dma mapping/unmapping in functions ahash_init()
>>>> and ahash_import().
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>> drivers/crypto/talitos.c | 80 ++++++++++++++++++++++++++++++++++--------------
>>>> 1 file changed, 57 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
>>>> index ebfd6d982ed6..d495649d5267 100644
>>>> --- a/drivers/crypto/talitos.c
>>>> +++ b/drivers/crypto/talitos.c
>>>> @@ -819,6 +819,7 @@ struct talitos_ctx {
>>>> unsigned int keylen;
>>>> unsigned int enckeylen;
>>>> unsigned int authkeylen;
>>>> + dma_addr_t dma_hw_context;
>>> This doesn't look correct.
>>>
>>> talitos_ctx structure is the tfm context.
>>> dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_ctx
>>> structure (request context).
>>
>> Yes but I have now found how I can know that the request context is
>> being released in order to unmap() dma at that time.
>> It is tricky to use the tmf context I agree, but at least I know when
>> tmf context get destroyed, ie in talitos_cra_exit_ahash()
>> The request context is created by ahash_request_alloc() and released by
>> ahash_request_free(). I have not found the way to call dma_unmap()
>> before ahash_request_free() gets called.
>>
>>>
>>> If there are multiple requests in flight for the same tfm, dma_hw_context will
>>> be overwritten.
>>
>> Before overwritting dma_hw_context, it is always released, see
>> talitos_cra_exit_ahash(), ahash_init(), ahash_import()
>>
> The problem is not the unmapping.
> If there are two requests for the same tfm, then given the following sequence
> 1. tfm->ahash_init(req1)
> tfm_ctx->dma_hw_context points to req1_ctx->hw_context
> 2. tfm->ahash_init(req2)
> tfm_ctx->dma_hw_context [unmapped, then] points to req2_ctx->hw_context
> i.e. req1 will use the hw_context of req2.
>
>>>
>>> dma_hw_context needs to be moved in request context (talitos_ahash_req_ctx struct).
>>
>> Any suggestion then on how to handle the issue explained above ?
>>
> There is no ahash_exit() callback mirroring ahash_init().
>
> The clean-up of request ctx should be done in the last states of the hash flows
> described here:
> https://www.kernel.org/doc/html/latest/crypto/devel-algos.html#cipher-definition-with-struct-shash-alg-and-ahash-alg
> for e.g. in the final() callback.
Unfortunatly it seems that we can't rely on those finalising functions
being called all the time.
If you look into test_ahash_jiffies() for instance, in case of error the
call of crypto_hash_final() is skipped.
So at the time being, I can't see any place to put the unmapping to be
100% sure it will be done before the call of ahash_request_free()
Christophe
>
> Hope this helps,
> Horia
>
^ permalink raw reply
* [PATCH] scsi: cxlflash: Select SCSI_SCAN_ASYNC
From: Vaibhav Jain @ 2018-02-19 7:10 UTC (permalink / raw)
To: Manoj N . Kumar
Cc: Vaibhav Jain, Matthew R . Ochs, Uma Krishnan, linux-scsi,
linux-kernel, Frederic Barrat, linuxppc-dev
The cxlflash driver uses "Asynchronous SCSI scanning" enabled by
CONFIG_SCSI_SCAN_ASYNC. Without this enabled the modprobe of cxlflash
module gets hung with following backtrace:
Call Trace:
__switch_to+0x2cc/0x470
__schedule+0x288/0xab0
schedule+0x40/0xc0
schedule_timeout+0x254/0x4f0
wait_for_common+0xdc/0x260
flush_work+0x140/0x2a0
work_on_cpu+0x88/0xb0
pci_device_probe+0x1d0/0x220
driver_probe_device+0x408/0x5b0
__driver_attach+0x16c/0x1a0
bus_for_each_dev+0xb8/0x110
driver_attach+0x3c/0x60
bus_add_driver+0x1d8/0x370
driver_register+0x9c/0x180
__pci_register_driver+0x74/0xa0
init_cxlflash+0x158/0x1cc
do_one_initcall+0x68/0x1e0
do_init_module+0x90/0x254
load_module+0x2f8c/0x3720
SyS_finit_module+0xcc/0x140
system_call+0x58/0x6c
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
---
drivers/scsi/cxlflash/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
index a011c5dbf214..f054c1b0fff3 100644
--- a/drivers/scsi/cxlflash/Kconfig
+++ b/drivers/scsi/cxlflash/Kconfig
@@ -6,6 +6,7 @@ config CXLFLASH
tristate "Support for IBM CAPI Flash"
depends on PCI && SCSI && CXL && EEH
select IRQ_POLL
+ select SCSI_SCAN_ASYNC
default m
help
Allows CAPI Accelerated IO to Flash
--
2.14.3
^ permalink raw reply related
* Re: [PATCH V3] cxl: Fix timebase synchronization status on P9
From: Vaibhav Jain @ 2018-02-19 6:10 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, andrew.donnellan
In-Reply-To: <1518794852-30137-1-git-send-email-clombard@linux.vnet.ibm.com>
Hi Christophe,
Mostly ok with this patch. Some very minor review comments:
Christophe Lombard <clombard@linux.vnet.ibm.com> writes:
> --- a/drivers/misc/cxl/sysfs.c
> +++ b/drivers/misc/cxl/sysfs.c
> @@ -62,6 +62,16 @@ static ssize_t psl_timebase_synced_show(struct device *device,
> char *buf)
> {
> struct cxl *adapter = to_cxl_adapter(device);
> + u64 psl_tb;
> + int delta;
> +
> + psl_tb = adapter->native->sl_ops->timebase_read(adapter);
> + delta = mftb() - psl_tb;
> + if (delta < 0)
> + delta = -delta;
Can just use abs().
> +
> + /* CORE TB and PSL TB difference <= 16usecs ? */
> + adapter->psl_timebase_synced = (tb_to_ns(delta) < 16000) ? true : false;
Can be re-written as
'adapter->psl_timebase_synced = (tb_to_ns(abs(delta)) < 16000);'
>
> return scnprintf(buf, PAGE_SIZE, "%i\n",
> adapter->psl_timebase_synced);
Might be a good idea to debug print/print_once the delta.
--
Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/npu-dma.c: Fix deadlock in mmio_invalidate
From: Alistair Popple @ 2018-02-19 5:02 UTC (permalink / raw)
To: Balbir Singh; +Cc: Mark Hairgrove, mpe, linuxppc-dev, Javier Cabezas
In-Reply-To: <20180219135704.3bd0cfb9@balbir.ozlabs.ibm.com>
> > Shouldn't that be enforced with READ_ONCE() then?
Yep, I can add that.
> Good point, although I think the acquire_* function itself may be called
> from a higher layer with the mmap_sem always held. I wonder if we need
> barriers around get and put mmio_atsd_reg.
test_and_set_bit() should imply a memory barrier so I don't think we need one
there (and looking at the implementation there is one). clear_bit() might need
one though. For that I guess I could use clear_bit_unlock()? There is also a
matching test_and_set_bit_lock() so I will submit a v2 which uses those instead
given we are using these like a lock.
> > > I don't think we can as the invalidate_range() function is called under the ptl
> > > spin-lock and is not allowed to sleep (at least according to
> > > include/linux/mmu_notifier.h).
>
> I double checked, It's the reverse
>
> /*
> * If both of these callbacks cannot block, mmu_notifier_ops.flags
> * should have MMU_INVALIDATE_DOES_NOT_BLOCK set.
> */
Argh, that must have been merged during the current window. Thanks for pointing
out - I will submit a seperate patch to update the mmu_notifier_ops.flags to set
MMU_INVALIDATE_DOES_NOT_BLOCK.
- Alistair
> void (*invalidate_range_start)(struct mmu_notifier *mn,
> struct mm_struct *mm,
> unsigned long start, unsigned long end);
> void (*invalidate_range_end)(struct mmu_notifier *mn,
> struct mm_struct *mm,
> unsigned long start, unsigned long end);
> > >
> > > - Alistair
> > >
> > > > Balbir
> > > >
> > >
> > >
> > >
>
> I think it looks good to me otherwise,
>
> Balbir Singh.
>
^ permalink raw reply
* Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h
From: Michael Ellerman @ 2018-02-19 4:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Ravi Bangoria
Cc: alexander.shishkin, jolsa, namhyung, linux-kernel, brueckner,
tmricht, linuxppc-dev
In-Reply-To: <20180216175002.GC16919@kernel.org>
Arnaldo Carvalho de Melo <acme@kernel.org> writes:
> Em Fri, Feb 16, 2018 at 02:29:01PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Humm, we need to create two tables, one for 32-bit and another for 64,
>> even with ppc not having (AFAIK) clashes in syscall numbers for 32/64...
>>
>> Trying to do it now.
>
> Now seems to work, take a look at my perf/core branch, should be one of the first few csets.
LGTM. Thanks for fixing this up.
cheers
> perfbuilder@cc1a85517216:/git/perf$ grep 192 /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_32.c
> [192] = "mmap2",
> perfbuilder@cc1a85517216:/git/perf$ powerpc-linux-gnu-gcc --version
> powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> perfbuilder@cc1a85517216:/git/perf$
>
> perfbuilder@9d7fc9dcfb73:/git/perf$ grep 192 /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_32.c
> [192] = "mmap2",
> perfbuilder@9d7fc9dcfb73:/git/perf$ grep 192 /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_64.c
> perfbuilder@9d7fc9dcfb73:/git/perf$ powerpc64-linux-gnu-gcc --version
> powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609
> perfbuilder@9d7fc9dcfb73:/git/perf$
^ permalink raw reply
* Re: [PATCH] powerpc/npu-dma.c: Fix deadlock in mmio_invalidate
From: Balbir Singh @ 2018-02-19 2:57 UTC (permalink / raw)
To: Mark Hairgrove; +Cc: Alistair Popple, mpe, linuxppc-dev, Javier Cabezas
In-Reply-To: <alpine.DEB.2.00.1802151910400.10245@mdh-linux64-2.nvidia.com>
On Thu, 15 Feb 2018 19:11:19 -0800
Mark Hairgrove <mhairgrove@nvidia.com> wrote:
> On Wed, 14 Feb 2018, Alistair Popple wrote:
>
> > > > +struct mmio_atsd_reg {
> > > > + struct npu *npu;
> > > > + int reg;
> > > > +};
> > > > +
> > >
> > > Is it just easier to move reg to inside of struct npu?
> >
> > I don't think so, struct npu is global to all npu contexts where as this is
> > specific to the given invalidation. We don't have enough registers to assign
> > each NPU context it's own dedicated register so I'm not sure it makes sense to
> > put it there either.
Fair enough, also discussed this offline with you.
> >
> > > > +static void acquire_atsd_reg(struct npu_context *npu_context,
> > > > + struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS])
> > > > +{
> > > > + int i, j;
> > > > + struct npu *npu;
> > > > + struct pci_dev *npdev;
> > > > + struct pnv_phb *nphb;
> > > >
> > > > - /*
> > > > - * The GPU requires two flush ATSDs to ensure all entries have
> > > > - * been flushed. We use PID 0 as it will never be used for a
> > > > - * process on the GPU.
> > > > - */
> > > > - if (flush)
> > > > - mmio_invalidate_pid(npu, 0, true);
> > > > + for (i = 0; i <= max_npu2_index; i++) {
> > > > + mmio_atsd_reg[i].reg = -1;
> > > > + for (j = 0; j < NV_MAX_LINKS; j++) {
> > >
> > > Is it safe to assume that npu_context->npdev will not change in this
> > > loop? I guess it would need to be stronger than just this loop.
> >
> > It is not safe to assume that npu_context->npdev won't change during this loop,
> > however I don't think it is a problem if it does as we only read each element
> > once during the invalidation.
>
> Shouldn't that be enforced with READ_ONCE() then?
Good point, although I think the acquire_* function itself may be called
from a higher layer with the mmap_sem always held. I wonder if we need
barriers around get and put mmio_atsd_reg.
>
> I assume that npdev->bus can't change until after the last
> pnv_npu2_destroy_context() is called for an npu. In that case, the
> mmu_notifier_unregister() in pnv_npu2_release_context() will block until
> mmio_invalidate() is done using npdev. That seems safe enough, but a
> comment somewhere about that would be useful.
>
> >
> > There are two possibilities for how this could change. pnv_npu2_init_context()
> > will add a nvlink to the npdev which will result in the TLB invalidation being
> > sent to that GPU as well which should not be a problem.
> >
> > pnv_npu2_destroy_context() will remove the the nvlink from npdev. If it happens
> > prior to this loop it should not be a problem (as the destruction will have
> > already invalidated the GPU TLB). If it happens after this loop it shouldn't be
> > a problem either (it will just result in an extra TLB invalidate being sent to
> > this GPU).
> >
> > > > + npdev = npu_context->npdev[i][j];
> > > > + if (!npdev)
> > > > + continue;
> > > > +
> > > > + nphb = pci_bus_to_host(npdev->bus)->private_data;
> > > > + npu = &nphb->npu;
> > > > + mmio_atsd_reg[i].npu = npu;
> > > > + mmio_atsd_reg[i].reg = get_mmio_atsd_reg(npu);
> > > > + while (mmio_atsd_reg[i].reg < 0) {
> > > > + mmio_atsd_reg[i].reg = get_mmio_atsd_reg(npu);
> > > > + cpu_relax();
> > >
> > > A cond_resched() as well if we have too many tries?
> >
> > I don't think we can as the invalidate_range() function is called under the ptl
> > spin-lock and is not allowed to sleep (at least according to
> > include/linux/mmu_notifier.h).
I double checked, It's the reverse
/*
* If both of these callbacks cannot block, mmu_notifier_ops.flags
* should have MMU_INVALIDATE_DOES_NOT_BLOCK set.
*/
void (*invalidate_range_start)(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start, unsigned long end);
void (*invalidate_range_end)(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start, unsigned long end);
> >
> > - Alistair
> >
> > > Balbir
> > >
> >
> >
> >
I think it looks good to me otherwise,
Balbir Singh.
^ permalink raw reply
* Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig
From: Sam Ravnborg @ 2018-02-18 22:13 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Linus Torvalds, Greg Kroah-Hartman, Arnd Bergmann,
Kees Cook, Randy Dunlap, Ulf Magnusson, Michal Marek,
Peter Oberparleiter, kernel-hardening, Jonathan Corbet,
sparclinux, linux-sh, x86, Thomas Gleixner, Rich Felker,
Jeff Dike, H. Peter Anvin, user-mode-linux-devel, Yoshinori Sato,
Benjamin Herrenschmidt, linuxppc-dev, Paul Mackerras,
user-mode-linux-user, Ingo Molnar, David S. Miller,
Michael Ellerman, linux-doc, linux-kernel, Richard Weinberger,
Emese Revfy
In-Reply-To: <1518806331-7101-1-git-send-email-yamada.masahiro@socionext.com>
Hi Masahiro.
On Sat, Feb 17, 2018 at 03:38:28AM +0900, Masahiro Yamada wrote:
> I brushed up the implementation in this version.
>
> In the previous RFC, CC_HAS_ was described by using 'option shell=',
> like this:
>
> config CC_HAS_STACKPROTECTOR
> bool
> option shell="$CC -Werror -fstack-protector -c -x c /dev/null"
>
> After I thought a bit more, the following syntax is more grammatical,
> and flexible.
>
> config CC_HAS_STACKPROTECTOR
> bool
> default $(shell $CC -Werror -fstack-protector -c -x c /dev/null)
Looks good - but maybe we should go one step further.
So we in the syntax explicit handles:
- shell commands
- other commands, defined as strings
- environment variables
- config variables
Each case is explicit - so the reader is not confused what is used when.
$(shell foo) - output of the shell command foo. Uses $SHELL as the shell.
May include optional paramters.
foo may be a config variable referenced using ${} or a config variable prefixed with $
Example:
config BUILD_DIR
string
default $(shell cd ${objtree}; pwd)
$(call bar) - output of the bar command that may take optional parameters.
bar may be a text string, a config variable or an environment variable
The definition of bar may reference the parameters using $(1), $(2)
In this context a config variable needs to be prefixed with $
Example:
config reverse
string
default $(2) $(1)
config NEW_ORDER
string
$(call $reverse, A, B) # Will assign REVERSE the value "B A"
Example2:
config CC_OPTION
string
default $(shell ${srctree}/scripts/cc-option ${CC} $(1) $(2))
config CC_OPTIMIZE
string
$(call $CC_OPTION, -Oz, -Os)
${FOO} - environment variable
The above is inspired by how make implement similar functionality.
I'm not happy that we in one context can reference CONFIG variables
directly, but inside the $(call ...) and $(shell ...) needs the $ prefix.
But I could not come up with something un-ambigious where this could be avoided.
The above proposal include the functionality of the macro stuff proposed in this patch-set.
But with a simpler syntax and we keep all the other kconfig logic (depends on etc) - so
users will not be limited in their creativity.
> Current limitations:
>
> Dependency on outside scripts.
> Inter-option dependency:
> Functions are evaluated statically:
Same limitations exists with the syntax suggested above.
Sam
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Horia Geantă @ 2018-02-18 17:14 UTC (permalink / raw)
To: Christophe LEROY, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2338eb8d-a26a-9722-d667-5a9785b32977@c-s.fr>
On 2/17/2018 6:32 PM, Christophe LEROY wrote:=0A=
> =0A=
> =0A=
> Le 07/02/2018 =E0 15:39, Horia Geant=E3 a =E9crit=A0:=0A=
>> On 10/6/2017 4:06 PM, Christophe Leroy wrote:=0A=
>>> At every request, we map and unmap the same hash hw_context.=0A=
>>>=0A=
>>> This patch moves the dma mapping/unmapping in functions ahash_init()=0A=
>>> and ahash_import().=0A=
>>>=0A=
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>=0A=
>>> ---=0A=
>>> drivers/crypto/talitos.c | 80 ++++++++++++++++++++++++++++++++++-----=
---------=0A=
>>> 1 file changed, 57 insertions(+), 23 deletions(-)=0A=
>>>=0A=
>>> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c=0A=
>>> index ebfd6d982ed6..d495649d5267 100644=0A=
>>> --- a/drivers/crypto/talitos.c=0A=
>>> +++ b/drivers/crypto/talitos.c=0A=
>>> @@ -819,6 +819,7 @@ struct talitos_ctx {=0A=
>>> unsigned int keylen;=0A=
>>> unsigned int enckeylen;=0A=
>>> unsigned int authkeylen;=0A=
>>> + dma_addr_t dma_hw_context;=0A=
>> This doesn't look correct.=0A=
>>=0A=
>> talitos_ctx structure is the tfm context.=0A=
>> dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_c=
tx=0A=
>> structure (request context).=0A=
> =0A=
> Yes but I have now found how I can know that the request context is =0A=
> being released in order to unmap() dma at that time.=0A=
> It is tricky to use the tmf context I agree, but at least I know when =0A=
> tmf context get destroyed, ie in talitos_cra_exit_ahash()=0A=
> The request context is created by ahash_request_alloc() and released by=
=0A=
> ahash_request_free(). I have not found the way to call dma_unmap() =0A=
> before ahash_request_free() gets called.=0A=
> =0A=
>>=0A=
>> If there are multiple requests in flight for the same tfm, dma_hw_contex=
t will=0A=
>> be overwritten.=0A=
> =0A=
> Before overwritting dma_hw_context, it is always released, see =0A=
> talitos_cra_exit_ahash(), ahash_init(), ahash_import()=0A=
> =0A=
The problem is not the unmapping.=0A=
If there are two requests for the same tfm, then given the following sequen=
ce=0A=
1. tfm->ahash_init(req1)=0A=
tfm_ctx->dma_hw_context points to req1_ctx->hw_context=0A=
2. tfm->ahash_init(req2)=0A=
tfm_ctx->dma_hw_context [unmapped, then] points to req2_ctx->hw_context=0A=
i.e. req1 will use the hw_context of req2.=0A=
=0A=
>>=0A=
>> dma_hw_context needs to be moved in request context (talitos_ahash_req_c=
tx struct).=0A=
> =0A=
> Any suggestion then on how to handle the issue explained above ?=0A=
> =0A=
There is no ahash_exit() callback mirroring ahash_init().=0A=
=0A=
The clean-up of request ctx should be done in the last states of the hash f=
lows=0A=
described here:=0A=
https://www.kernel.org/doc/html/latest/crypto/devel-algos.html#cipher-defin=
ition-with-struct-shash-alg-and-ahash-alg=0A=
for e.g. in the final() callback.=0A=
=0A=
Hope this helps,=0A=
Horia=0A=
^ permalink raw reply
* Re: [PATCH] fix double ;;s in code
From: Christophe LEROY @ 2018-02-18 10:00 UTC (permalink / raw)
To: Pavel Machek, elfring, kernel list, vgupta, linux, oleg,
catalin.marinas, will.deacon, paulus, benh, mpe, ard.biesheuvel,
tglx, mingo, hpa, x86, scott.bauer, jonathan.derrick, axboe,
daniel.lezcano, maxime.ripard, wens, alexander.deucher,
christian.koenig, David1.Zhou, airlied, robdclark, joro, shli,
shawnguo, kernel, fabio.estevam, akpm, Alexey.Brodkin, mhocko,
vbabka, Vladislav.Zakharov, noamca, yamada.masahiro, sboyd,
viresh.kumar, linus.walleij, heiko, aik, ruscur, david, fbarrat,
alistair, robh, joe, harry.wentland, tony.cheng, Wenjing.Liu,
airlied, Ding.Wang, sylvia.tsai, hersenxs.wu, Rex.Zhu,
JinHuiEric.Huang, dan.carpenter, architt, daniel.vetter,
narmstrong, ville.syrjala, jcrouse, aishpant, noralf, andresx7,
Monk.Liu, nicolai.haehnle, Andrey.Grodzovsky, linux-snps-arc,
linux-arm-kernel, kvm-ppc, linuxppc-dev, linux-efi, linux-block,
amd-gfx, dri-devel, linux-arm-msm, freedreno, iommu, linux-raid
In-Reply-To: <20180217211955.GE9640@amd>
Le 17/02/2018 à 22:19, Pavel Machek a écrit :
>
> Fix double ;;'s in code.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
A summary of the files modified on top of the patch would help
understand the impact.
A maybe there should be one patch by area, eg one for each arch specific
modif and one for drivers/ and one for block/ ?
Christophe
>
> diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
> index 9d27331..ec12fe1 100644
> --- a/arch/arc/kernel/setup.c
> +++ b/arch/arc/kernel/setup.c
> @@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
> {
> struct cpuinfo_arc *cpu = &cpuinfo_arc700[smp_processor_id()];
> int saved = 0, present = 0;
> - char *opt_nm = NULL;;
> + char *opt_nm = NULL;
>
> if (!cpu->extn.timer0)
> panic("Timer0 is not present!\n");
> diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
> index 333daab..183391d 100644
> --- a/arch/arc/kernel/unwind.c
> +++ b/arch/arc/kernel/unwind.c
> @@ -366,7 +366,7 @@ static void init_unwind_hdr(struct unwind_table *table,
> return;
>
> ret_err:
> - panic("Attention !!! Dwarf FDE parsing errors\n");;
> + panic("Attention !!! Dwarf FDE parsing errors\n");
> }
>
> #ifdef CONFIG_MODULES
> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
> index 629f8e9..cf2701c 100644
> --- a/arch/arm/kernel/time.c
> +++ b/arch/arm/kernel/time.c
> @@ -83,7 +83,7 @@ static void dummy_clock_access(struct timespec64 *ts)
> }
>
> static clock_access_fn __read_persistent_clock = dummy_clock_access;
> -static clock_access_fn __read_boot_clock = dummy_clock_access;;
> +static clock_access_fn __read_boot_clock = dummy_clock_access;
>
> void read_persistent_clock64(struct timespec64 *ts)
> {
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 6618036..9ae31f7 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -1419,7 +1419,7 @@ static int compat_ptrace_hbp_get(unsigned int note_type,
> u64 addr = 0;
> u32 ctrl = 0;
>
> - int err, idx = compat_ptrace_hbp_num_to_idx(num);;
> + int err, idx = compat_ptrace_hbp_num_to_idx(num);
>
> if (num & 1) {
> err = ptrace_hbp_get_addr(note_type, tsk, idx, &addr);
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index f0f5cd4..f9818d7 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -188,7 +188,7 @@ static int xive_provision_queue(struct kvm_vcpu *vcpu, u8 prio)
> if (!qpage) {
> pr_err("Failed to allocate queue %d for VCPU %d\n",
> prio, xc->server_num);
> - return -ENOMEM;;
> + return -ENOMEM;
> }
> memset(qpage, 0, 1 << xive->q_order);
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 496e476..a6c92c7 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1854,7 +1854,7 @@ static int pnv_pci_ioda_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
> s64 rc;
>
> if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
> - return -ENODEV;;
> + return -ENODEV;
>
> pe = &phb->ioda.pe_array[pdn->pe_number];
> if (pe->tce_bypass_enabled) {
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index 353e20c..886a911 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
> struct efi_uga_draw_protocol *uga = NULL, *first_uga;
> efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
> unsigned long nr_ugas;
> - u32 *handles = (u32 *)uga_handle;;
> + u32 *handles = (u32 *)uga_handle;
> efi_status_t status = EFI_INVALID_PARAMETER;
> int i;
>
> @@ -484,7 +484,7 @@ setup_uga64(void **uga_handle, unsigned long size, u32 *width, u32 *height)
> struct efi_uga_draw_protocol *uga = NULL, *first_uga;
> efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
> unsigned long nr_ugas;
> - u64 *handles = (u64 *)uga_handle;;
> + u64 *handles = (u64 *)uga_handle;
> efi_status_t status = EFI_INVALID_PARAMETER;
> int i;
>
> diff --git a/block/sed-opal.c b/block/sed-opal.c
> index 9ed51d0c..e4929ee 100644
> --- a/block/sed-opal.c
> +++ b/block/sed-opal.c
> @@ -490,7 +490,7 @@ static int opal_discovery0_end(struct opal_dev *dev)
>
> if (!found_com_id) {
> pr_debug("Could not find OPAL comid for device. Returning early\n");
> - return -EOPNOTSUPP;;
> + return -EOPNOTSUPP;
> }
>
> dev->comid = comid;
> diff --git a/drivers/clocksource/mips-gic-timer.c b/drivers/clocksource/mips-gic-timer.c
> index a04808a..65e18c8 100644
> --- a/drivers/clocksource/mips-gic-timer.c
> +++ b/drivers/clocksource/mips-gic-timer.c
> @@ -205,12 +205,12 @@ static int __init gic_clocksource_of_init(struct device_node *node)
> } else if (of_property_read_u32(node, "clock-frequency",
> &gic_frequency)) {
> pr_err("GIC frequency not specified.\n");
> - return -EINVAL;;
> + return -EINVAL;
> }
> gic_timer_irq = irq_of_parse_and_map(node, 0);
> if (!gic_timer_irq) {
> pr_err("GIC timer IRQ not specified.\n");
> - return -EINVAL;;
> + return -EINVAL;
> }
>
> ret = __gic_clocksource_init();
> diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
> index 2a3fe83..3b56ea3 100644
> --- a/drivers/clocksource/timer-sun5i.c
> +++ b/drivers/clocksource/timer-sun5i.c
> @@ -334,7 +334,7 @@ static int __init sun5i_timer_init(struct device_node *node)
> timer_base = of_io_request_and_map(node, 0, of_node_full_name(node));
> if (IS_ERR(timer_base)) {
> pr_err("Can't map registers\n");
> - return PTR_ERR(timer_base);;
> + return PTR_ERR(timer_base);
> }
>
> irq = irq_of_parse_and_map(node, 0);
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 61e8c3e..33d91e4 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -718,7 +718,7 @@ static enum link_training_result perform_channel_equalization_sequence(
> uint32_t retries_ch_eq;
> enum dc_lane_count lane_count = lt_settings->link_settings.lane_count;
> union lane_align_status_updated dpcd_lane_status_updated = {{0}};
> - union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};;
> + union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};
>
> hw_tr_pattern = get_supported_tp(link);
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index 4c3223a..adb6e7b 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -162,7 +162,7 @@ static int pp_hw_init(void *handle)
> if(hwmgr->smumgr_funcs->start_smu(pp_handle->hwmgr)) {
> pr_err("smc start failed\n");
> hwmgr->smumgr_funcs->smu_fini(pp_handle->hwmgr);
> - return -EINVAL;;
> + return -EINVAL;
> }
> if (ret == PP_DPM_DISABLED)
> goto exit;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 3e9bba4..6d8e3a9 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -680,7 +680,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> } else {
> dev_info(&pdev->dev,
> "no iommu, fallback to phys contig buffers for scanout\n");
> - aspace = NULL;;
> + aspace = NULL;
> }
>
> pm_runtime_put_sync(&pdev->dev);
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 2c18996..0d95888 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -461,7 +461,7 @@ void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct drm_sched_jo
> {
> struct drm_sched_job *s_job;
> struct drm_sched_entity *entity, *tmp;
> - int i;;
> + int i;
>
> spin_lock(&sched->job_list_lock);
> list_for_each_entry_reverse(s_job, &sched->ring_mirror_list, node) {
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
> index 35a408d..99bc9bd 100644
> --- a/drivers/iommu/intel-svm.c
> +++ b/drivers/iommu/intel-svm.c
> @@ -205,7 +205,7 @@ static void intel_flush_svm_range_dev (struct intel_svm *svm, struct intel_svm_d
> * for example, an "address" value of 0x12345f000 will
> * flush from 0x123440000 to 0x12347ffff (256KiB). */
> unsigned long last = address + ((unsigned long)(pages - 1) << VTD_PAGE_SHIFT);
> - unsigned long mask = __rounddown_pow_of_two(address ^ last);;
> + unsigned long mask = __rounddown_pow_of_two(address ^ last);
>
> desc.high = QI_DEV_EIOTLB_ADDR((address & ~mask) | (mask - 1)) | QI_DEV_EIOTLB_SIZE;
> } else {
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index b2eae33..f978edd 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1108,7 +1108,7 @@ static void alloc_behind_master_bio(struct r1bio *r1_bio,
>
> bio_copy_data(behind_bio, bio);
> skip_copy:
> - r1_bio->behind_master_bio = behind_bio;;
> + r1_bio->behind_master_bio = behind_bio;
> set_bit(R1BIO_BehindIO, &r1_bio->state);
>
> return;
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 53f7275..cfb42f5 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev, struct regmap *regmap,
> if (i == 1) {
> domain->supply = devm_regulator_get(dev, "pu");
> if (IS_ERR(domain->supply))
> - return PTR_ERR(domain->supply);;
> + return PTR_ERR(domain->supply);
>
> ret = imx_pgc_get_clocks(dev, domain);
> if (ret)
>
^ permalink raw reply
* Re: pseries/drmem: Check for zero filled ibm, dynamic-memory property.
From: Michael Ellerman @ 2018-02-18 8:55 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev; +Cc: ""@gmail.com, daniel, camb
In-Reply-To: <151875166139.16739.9174261168457130221.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
On Fri, 2018-02-16 at 03:27:41 UTC, Nathan Fontenot wrote:
> Some versions of QEMU will produce an ibm,dynamic-reconfiguration-memory
> node with a ibm,dynamic-memory property that is zero-filled. This causes
> the drmem code to oops trying to parse this property.
>
> The fix for this is to validate that the property does contain LMB
> entries before trying to parse it and bail if the count is zero.
>
> Oops: Kernel access of bad area, sig: 11 [#1]
...
>
> The ibm,dynamic-reconfiguration-memory device tree property
> generated that causes this:
>
> ibm,dynamic-reconfiguration-memory {
> ibm,lmb-size = <0x0 0x10000000>;
> ibm,memory-flags-mask = <0xff>;
> ibm,dynamic-memory = <0x0 0x0 0x0 0x0 0x0 0x0>;
> linux,phandle = <0x7e57eed8>;
> ibm,associativity-lookup-arrays = <0x1 0x4 0x0 0x0 0x0 0x0>;
> ibm,memory-preservation-time = <0x0>;
> };
>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
> Tested-by: Daniel Black <daniel@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/2c10636a0b9c689450e85f99455839
cheers
^ permalink raw reply
* Re: powerpc: add empty update_numa_cpu_lookup_table for !CONFIG_NUMA
From: Michael Ellerman @ 2018-02-18 8:55 UTC (permalink / raw)
To: Corentin Labbe, benh, paulus, nfont, tyreld
Cc: linuxppc-dev, linux-kernel, Corentin Labbe
In-Reply-To: <1518610667-23406-1-git-send-email-clabbe@baylibre.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
On Wed, 2018-02-14 at 12:17:47 UTC, Corentin Labbe wrote:
> When CONFIG_NUMA is not set, build fail with:
> arch/powerpc/platforms/pseries/hotplug-cpu.c:335:4: error: déclaration implicite de la fonction « update_numa_cpu_lookup_table » [-Werror=implicit-function-declaration]
>
> So we have to add update_numa_cpu_lookup_table as an empty function when CONFIG_NUMA is not set.
>
> Fixes: 1d9a090783be ("powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove")
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/c1e150ceb61e4a585bad156da15c33
cheers
^ permalink raw reply
* Re: powerpc: Expose TSCR via sysfs only on powernv
From: Michael Ellerman @ 2018-02-18 8:55 UTC (permalink / raw)
To: Cyril Bur, linuxppc-dev
In-Reply-To: <20180214032706.6242-1-cyrilbur@gmail.com>
On Wed, 2018-02-14 at 03:27:06 UTC, Cyril Bur wrote:
> The TSCR can only be accessed in hypervisor mode.
>
> Fixes: 88b5e12eeb11 ("powerpc: Expose TSCR via sysfs")
> Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/c134f0d57a47b7f8704dee1cefc246
cheers
^ permalink raw reply
* Re: powerpc/xive: use hw CPU ids when configuring the CPU queues
From: Michael Ellerman @ 2018-02-18 8:55 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev; +Cc: Cédric Le Goater
In-Reply-To: <20180213084712.18351-1-clg@kaod.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Tue, 2018-02-13 at 08:47:12 UTC, =?utf-8?q?C=C3=A9dric_Le_Goater?= wrote:
> The CPU event notification queues on sPAPR should be configured using
> a hardware CPU identifier.
>
> The problem did not show up on the Power Hypervisor because pHyp
> supports 8 threads per core which keeps CPU number contiguous. This is
> not the case on all sPAPR virtual machines, some use SMT=1.
>
> Also improve error logging by adding the CPU number.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/8e036c8d30a2cd9d8fc7442fbf6824
cheers
^ permalink raw reply
* Re: powerpc/powernv: IMC fix out of bounds memory access at shutdown
From: Michael Ellerman @ 2018-02-18 8:55 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
Cc: Anju T Sudhakar, Hemant Kumar, Nicholas Piggin,
Madhavan Srinivasan
In-Reply-To: <20180213074511.6210-1-npiggin@gmail.com>
On Tue, 2018-02-13 at 07:45:11 UTC, Nicholas Piggin wrote:
> The OPAL IMC driver's shutdown handler disables nest PMU counters by
> walking nodes and taking the first CPU out of their cpumask, which is
> used to index into the paca (get_hard_smp_processor_id()). This does
> not always do the right thing, and in particular for CPU-less nodes it
> returns NR_CPUS and that overruns the paca and dereferences random
> memory.
>
> Fix it by being more careful about checking returned CPU, and only
> using online CPUs. It's not clear this shutdown code makes sense
> after commit 885dcd709b ("powerpc/perf: Add nest IMC PMU support"),
> but this should not make things worse
>
> Changing the way pacas are allocated to an array of pointers exposed
> this bug:
...
>
> Cc: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/e7bde88cdb4f0e432398a7d29ca2a1
cheers
^ permalink raw reply
* [PATCH] fix double ;;s in code
From: Pavel Machek @ 2018-02-17 21:19 UTC (permalink / raw)
To: elfring, kernel list, vgupta, linux, oleg, catalin.marinas,
will.deacon, paulus, benh, mpe, ard.biesheuvel, tglx, mingo, hpa,
x86, scott.bauer, jonathan.derrick, axboe, daniel.lezcano,
maxime.ripard, wens, alexander.deucher, christian.koenig,
David1.Zhou, airlied, robdclark, joro, shli, shawnguo, kernel,
fabio.estevam, akpm, Alexey.Brodkin, mhocko, vbabka,
Vladislav.Zakharov, noamca, yamada.masahiro, sboyd, viresh.kumar,
linus.walleij, heiko, aik, ruscur, david, fbarrat, alistair, robh,
joe, harry.wentland, tony.cheng, Wenjing.Liu, airlied, Ding.Wang,
sylvia.tsai, hersenxs.wu, Rex.Zhu, JinHuiEric.Huang,
dan.carpenter, architt, daniel.vetter, narmstrong, ville.syrjala,
jcrouse, aishpant, noralf, andresx7, Monk.Liu, nicolai.haehnle,
Andrey.Grodzovsky, linux-snps-arc, linux-arm-kernel, kvm-ppc,
linuxppc-dev, linux-efi, linux-block, amd-gfx, dri-devel,
linux-arm-msm, freedreno, iommu, linux-raid
[-- Attachment #1: Type: text/plain, Size: 9417 bytes --]
Fix double ;;'s in code.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331..ec12fe1 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
{
struct cpuinfo_arc *cpu = &cpuinfo_arc700[smp_processor_id()];
int saved = 0, present = 0;
- char *opt_nm = NULL;;
+ char *opt_nm = NULL;
if (!cpu->extn.timer0)
panic("Timer0 is not present!\n");
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 333daab..183391d 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -366,7 +366,7 @@ static void init_unwind_hdr(struct unwind_table *table,
return;
ret_err:
- panic("Attention !!! Dwarf FDE parsing errors\n");;
+ panic("Attention !!! Dwarf FDE parsing errors\n");
}
#ifdef CONFIG_MODULES
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 629f8e9..cf2701c 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -83,7 +83,7 @@ static void dummy_clock_access(struct timespec64 *ts)
}
static clock_access_fn __read_persistent_clock = dummy_clock_access;
-static clock_access_fn __read_boot_clock = dummy_clock_access;;
+static clock_access_fn __read_boot_clock = dummy_clock_access;
void read_persistent_clock64(struct timespec64 *ts)
{
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6618036..9ae31f7 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1419,7 +1419,7 @@ static int compat_ptrace_hbp_get(unsigned int note_type,
u64 addr = 0;
u32 ctrl = 0;
- int err, idx = compat_ptrace_hbp_num_to_idx(num);;
+ int err, idx = compat_ptrace_hbp_num_to_idx(num);
if (num & 1) {
err = ptrace_hbp_get_addr(note_type, tsk, idx, &addr);
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index f0f5cd4..f9818d7 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -188,7 +188,7 @@ static int xive_provision_queue(struct kvm_vcpu *vcpu, u8 prio)
if (!qpage) {
pr_err("Failed to allocate queue %d for VCPU %d\n",
prio, xc->server_num);
- return -ENOMEM;;
+ return -ENOMEM;
}
memset(qpage, 0, 1 << xive->q_order);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 496e476..a6c92c7 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1854,7 +1854,7 @@ static int pnv_pci_ioda_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
s64 rc;
if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
- return -ENODEV;;
+ return -ENODEV;
pe = &phb->ioda.pe_array[pdn->pe_number];
if (pe->tce_bypass_enabled) {
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 353e20c..886a911 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
- u32 *handles = (u32 *)uga_handle;;
+ u32 *handles = (u32 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
@@ -484,7 +484,7 @@ setup_uga64(void **uga_handle, unsigned long size, u32 *width, u32 *height)
struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
- u64 *handles = (u64 *)uga_handle;;
+ u64 *handles = (u64 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 9ed51d0c..e4929ee 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -490,7 +490,7 @@ static int opal_discovery0_end(struct opal_dev *dev)
if (!found_com_id) {
pr_debug("Could not find OPAL comid for device. Returning early\n");
- return -EOPNOTSUPP;;
+ return -EOPNOTSUPP;
}
dev->comid = comid;
diff --git a/drivers/clocksource/mips-gic-timer.c b/drivers/clocksource/mips-gic-timer.c
index a04808a..65e18c8 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -205,12 +205,12 @@ static int __init gic_clocksource_of_init(struct device_node *node)
} else if (of_property_read_u32(node, "clock-frequency",
&gic_frequency)) {
pr_err("GIC frequency not specified.\n");
- return -EINVAL;;
+ return -EINVAL;
}
gic_timer_irq = irq_of_parse_and_map(node, 0);
if (!gic_timer_irq) {
pr_err("GIC timer IRQ not specified.\n");
- return -EINVAL;;
+ return -EINVAL;
}
ret = __gic_clocksource_init();
diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
index 2a3fe83..3b56ea3 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -334,7 +334,7 @@ static int __init sun5i_timer_init(struct device_node *node)
timer_base = of_io_request_and_map(node, 0, of_node_full_name(node));
if (IS_ERR(timer_base)) {
pr_err("Can't map registers\n");
- return PTR_ERR(timer_base);;
+ return PTR_ERR(timer_base);
}
irq = irq_of_parse_and_map(node, 0);
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 61e8c3e..33d91e4 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -718,7 +718,7 @@ static enum link_training_result perform_channel_equalization_sequence(
uint32_t retries_ch_eq;
enum dc_lane_count lane_count = lt_settings->link_settings.lane_count;
union lane_align_status_updated dpcd_lane_status_updated = {{0}};
- union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};;
+ union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};
hw_tr_pattern = get_supported_tp(link);
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 4c3223a..adb6e7b 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -162,7 +162,7 @@ static int pp_hw_init(void *handle)
if(hwmgr->smumgr_funcs->start_smu(pp_handle->hwmgr)) {
pr_err("smc start failed\n");
hwmgr->smumgr_funcs->smu_fini(pp_handle->hwmgr);
- return -EINVAL;;
+ return -EINVAL;
}
if (ret == PP_DPM_DISABLED)
goto exit;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 3e9bba4..6d8e3a9 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -680,7 +680,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
} else {
dev_info(&pdev->dev,
"no iommu, fallback to phys contig buffers for scanout\n");
- aspace = NULL;;
+ aspace = NULL;
}
pm_runtime_put_sync(&pdev->dev);
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 2c18996..0d95888 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -461,7 +461,7 @@ void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct drm_sched_jo
{
struct drm_sched_job *s_job;
struct drm_sched_entity *entity, *tmp;
- int i;;
+ int i;
spin_lock(&sched->job_list_lock);
list_for_each_entry_reverse(s_job, &sched->ring_mirror_list, node) {
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 35a408d..99bc9bd 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -205,7 +205,7 @@ static void intel_flush_svm_range_dev (struct intel_svm *svm, struct intel_svm_d
* for example, an "address" value of 0x12345f000 will
* flush from 0x123440000 to 0x12347ffff (256KiB). */
unsigned long last = address + ((unsigned long)(pages - 1) << VTD_PAGE_SHIFT);
- unsigned long mask = __rounddown_pow_of_two(address ^ last);;
+ unsigned long mask = __rounddown_pow_of_two(address ^ last);
desc.high = QI_DEV_EIOTLB_ADDR((address & ~mask) | (mask - 1)) | QI_DEV_EIOTLB_SIZE;
} else {
diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index b2eae33..f978edd 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1108,7 +1108,7 @@ static void alloc_behind_master_bio(struct r1bio *r1_bio,
bio_copy_data(behind_bio, bio);
skip_copy:
- r1_bio->behind_master_bio = behind_bio;;
+ r1_bio->behind_master_bio = behind_bio;
set_bit(R1BIO_BehindIO, &r1_bio->state);
return;
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 53f7275..cfb42f5 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev, struct regmap *regmap,
if (i == 1) {
domain->supply = devm_regulator_get(dev, "pu");
if (IS_ERR(domain->supply))
- return PTR_ERR(domain->supply);;
+ return PTR_ERR(domain->supply);
ret = imx_pgc_get_clocks(dev, domain);
if (ret)
--
(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 related
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Christophe LEROY @ 2018-02-17 16:32 UTC (permalink / raw)
To: Horia Geantă, Herbert Xu, David S. Miller
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR0402MB3342A0A8530F74D408CA2F0298FC0@VI1PR0402MB3342.eurprd04.prod.outlook.com>
Le 07/02/2018 à 15:39, Horia Geantă a écrit :
> On 10/6/2017 4:06 PM, Christophe Leroy wrote:
>> At every request, we map and unmap the same hash hw_context.
>>
>> This patch moves the dma mapping/unmapping in functions ahash_init()
>> and ahash_import().
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>> drivers/crypto/talitos.c | 80 ++++++++++++++++++++++++++++++++++--------------
>> 1 file changed, 57 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
>> index ebfd6d982ed6..d495649d5267 100644
>> --- a/drivers/crypto/talitos.c
>> +++ b/drivers/crypto/talitos.c
>> @@ -819,6 +819,7 @@ struct talitos_ctx {
>> unsigned int keylen;
>> unsigned int enckeylen;
>> unsigned int authkeylen;
>> + dma_addr_t dma_hw_context;
> This doesn't look correct.
>
> talitos_ctx structure is the tfm context.
> dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_ctx
> structure (request context).
Yes but I have now found how I can know that the request context is
being released in order to unmap() dma at that time.
It is tricky to use the tmf context I agree, but at least I know when
tmf context get destroyed, ie in talitos_cra_exit_ahash()
The request context is created by ahash_request_alloc() and released by
ahash_request_free(). I have not found the way to call dma_unmap()
before ahash_request_free() gets called.
>
> If there are multiple requests in flight for the same tfm, dma_hw_context will
> be overwritten.
Before overwritting dma_hw_context, it is always released, see
talitos_cra_exit_ahash(), ahash_init(), ahash_import()
>
> dma_hw_context needs to be moved in request context (talitos_ahash_req_ctx struct).
Any suggestion then on how to handle the issue explained above ?
Thanks
Christophe
>
> Thanks,
> Horia
>
^ permalink raw reply
* Re: [GIT PULL 00/41] perf/core improvements and fixes
From: Ingo Molnar @ 2018-02-17 10:49 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: linux-kernel, linux-perf-users, Adrian Hunter, Alexander Shishkin,
Andi Kleen, coresight, David Ahern, Heiko Carstens,
Hendrik Brueckner, Jaecheol Shin, Jin Yao, Jiri Olsa, Kan Liang,
linux-arm-kernel, linuxppc-dev, Martin Schwidefsky,
Masami Hiramatsu, Mathieu Poirier, Michael Ellerman, Milian Wolff,
Namhyung Kim, Naveen N . Rao, Peter Zijlstra, Ravi Bangoria,
Robert Walker, Sangwon Hong, Stephane Eranian, Taeung Song,
Thomas Richter, Wang Nan, yuzhoujian, Arnaldo Carvalho de Melo
In-Reply-To: <20180216191746.11095-1-acme@kernel.org>
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Hi Ingo,
>
> Please consider pulling, this is on top of tip/perf/urgent.
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 297f9233b53a08fd457815e19f1d6f2c3389857b:
>
> kprobes: Propagate error from disarm_kprobe_ftrace() (2018-02-16 09:12:58 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.17-20180216
>
> for you to fetch changes up to 21316ac6803d4a1aadd74b896db8d60a92cd1140:
>
> perf tests shell lib: Use a wildcard to remove the vfs_getname probe (2018-02-16 15:31:12 -0300)
>
> ----------------------------------------------------------------
> perf/core improvements and fixes:
>
> - Fix wrong jump arrow in systems with branch records with cycles,
> i.e. Intel's >= Skylake (Jin Yao)
>
> - Fix 'perf record --per-thread' problem introduced when
> implementing 'perf stat --per-thread (Jin Yao)
>
> - Use arch__compare_symbol_names() to fix 'perf test vmlinux',
> that was using strcmp(symbol names) while the dso routines
> doing symbol lookups used the arch overridable one, making
> this test fail in architectures that overrided that function
> with something other than strcmp() (Jiri Olsa)
>
> - Add 'perf script --show-round-event' to display
> PERF_RECORD_FINISHED_ROUND entries (Jiri Olsa)
>
> - Fix dwarf unwind for stripped binaries in 'perf test' (Jiri Olsa)
>
> - Use ordered_events for 'perf report --tasks', otherwise we may get
> artifacts when PERF_RECORD_FORK gets processed before PERF_RECORD_COMM
> (when they got recorded in different CPUs) (Jiri Olsa)
>
> - Add support to display group output for non group events, i.e.
> now when one uses 'perf report --group' on a perf.data file
> recorded without explicitly grouping events with {} (e.g.
> "perf record -e '{cycles,instructions}'" get the same output
> that would produce, i.e. see all those non-grouped events in
> multiple columns, at the same time (Jiri Olsa)
>
> - Skip non-address kallsyms entries, e.g. '(null)' for !root (Jiri Olsa)
>
> - Kernel maps fixes wrt perf.data(report) versus live system (top)
> (Jiri Olsa)
>
> - Fix memory corruption when using 'perf record -j call -g -a <application>'
> followed by 'perf report --branch-history' (Jiri Olsa)
>
> - ARM CoreSight fixes (Mathieu Poirier)
>
> - Add inject capability for CoreSight Traces (Robert Waker)
>
> - Update documentation for use of 'perf' + ARM CoreSight (Robert Walker)
>
> - Man pages fixes (Sangwon Hong, Jaecheol Shin)
>
> - Fix some 'perf test' cases on s/390 and x86_64 (some backtraces
> changed with a glibc update) (Thomas Richter)
>
> - Add detailed CPUID info in the 'perf.data' headers for s/390 to
> then use it in 'perf annotate' (Thomas Richter)
>
> - Add '--interval-count N' to 'perf stat', to use with -I, i.e.
> 'perf stat -I 1000 --interval-count 2' will show stats every
> 1000ms, two times (yuzhoujian)
>
> - Add 'perf stat --timeout Nms', that will run for that many
> milliseconds and then stop, printing the counters (yuzhoujian)
>
> - Fix description for 'perf report --mem-modex (Andi Kleen)
>
> - Use a wildcard to remove the vfs_getname probe in the
> 'perf test' shell based test cases (Arnaldo Carvalho de Melo)
>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> ----------------------------------------------------------------
> Andi Kleen (1):
> perf report: Fix description for --mem-mode
>
> Arnaldo Carvalho de Melo (1):
> perf tests shell lib: Use a wildcard to remove the vfs_getname probe
>
> Jaecheol Shin (1):
> perf annotate: Add missing arguments in Man page
>
> Jin Yao (2):
> perf tools: Use target->per_thread and target->system_wide flags
> perf report: Fix wrong jump arrow
>
> Jiri Olsa (18):
> perf record: Put new line after target override warning
> perf script: Add --show-round-event to display PERF_RECORD_FINISHED_ROUND
> tools lib api fs: Add filename__read_xll function
> tools lib api fs: Add sysfs__read_xll function
> perf tests: Fix dwarf unwind for stripped binaries
> perf tools: Fix comment for sort__* compare functions
> perf report: Ask for ordered events for --tasks option
> perf report: Add support to display group output for non group events
> tools lib symbol: Skip non-address kallsyms line
> perf symbols: Check if we read regular file in dso__load()
> perf machine: Free root_dir in machine__init() error path
> perf machine: Move kernel mmap name into struct machine
> perf machine: Generalize machine__set_kernel_mmap()
> perf machine: Don't search for active kernel start in __machine__create_kernel_maps
> perf machine: Remove machine__load_kallsyms()
> perf tools: Do not create kernel maps in sample__resolve()
> perf tests: Use arch__compare_symbol_names to compare symbols
> perf report: Fix memory corruption in --branch-history mode --branch-history
>
> Mathieu Poirier (3):
> perf cs-etm: Freeing allocated memory
> perf auxtrace arm: Fixing uninitialised variable
> perf cs-etm: Properly deal with cpu maps
>
> Ravi Bangoria (3):
> tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h
> perf powerpc: Generate system call table from asm/unistd.h
> perf trace powerpc: Use generated syscall table
>
> Robert Walker (3):
> perf cs-etm: Inject capabilitity for CoreSight traces
> perf inject: Emit instruction records on ETM trace discontinuity
> coresight: Update documentation for perf usage
>
> Sangwon Hong (2):
> perf kmem: Document a missing option & an argument
> perf mem: Document a missing option
>
> Thomas Richter (5):
> perf record: Provide detailed information on s390 CPU
> perf annotate: Scan cpuid for s390 and save machine type
> perf cpuid: Introduce a platform specific cpuid compare function
> perf test: Fix test case 23 for s390 z/VM or KVM guests
> perf test: Fix test case inet_pton to accept inlines.
>
> yuzhoujian (2):
> perf stat: Add support to print counts for fixed times
> perf stat: Add support to print counts after a period of time
>
> Documentation/trace/coresight.txt | 51 +++
> tools/arch/powerpc/include/uapi/asm/unistd.h | 402 +++++++++++++++++
> tools/lib/api/fs/fs.c | 44 +-
> tools/lib/api/fs/fs.h | 2 +
> tools/lib/symbol/kallsyms.c | 4 +
> tools/perf/Documentation/perf-annotate.txt | 6 +-
> tools/perf/Documentation/perf-kmem.txt | 6 +-
> tools/perf/Documentation/perf-mem.txt | 4 +
> tools/perf/Documentation/perf-report.txt | 5 +-
> tools/perf/Documentation/perf-script.txt | 3 +
> tools/perf/Documentation/perf-stat.txt | 10 +
> tools/perf/Makefile.config | 2 +
> tools/perf/arch/arm/util/auxtrace.c | 2 +-
> tools/perf/arch/arm/util/cs-etm.c | 51 ++-
> tools/perf/arch/powerpc/Makefile | 25 ++
> .../perf/arch/powerpc/entry/syscalls/mksyscalltbl | 37 ++
> tools/perf/arch/s390/annotate/instructions.c | 27 +-
> tools/perf/arch/s390/util/header.c | 148 ++++++-
> tools/perf/builtin-record.c | 2 +-
> tools/perf/builtin-report.c | 7 +-
> tools/perf/builtin-script.c | 17 +
> tools/perf/builtin-stat.c | 53 ++-
> tools/perf/check-headers.sh | 1 +
> tools/perf/tests/code-reading.c | 33 +-
> tools/perf/tests/dwarf-unwind.c | 46 +-
> tools/perf/tests/shell/lib/probe_vfs_getname.sh | 2 +-
> .../perf/tests/shell/trace+probe_libc_inet_pton.sh | 6 +-
> tools/perf/tests/vmlinux-kallsyms.c | 4 +-
> tools/perf/ui/browsers/annotate.c | 9 +-
> tools/perf/util/build-id.c | 10 +-
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 74 +++-
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 2 +
> tools/perf/util/cs-etm.c | 478 ++++++++++++++++++---
> tools/perf/util/event.c | 16 +-
> tools/perf/util/evlist.c | 21 +-
> tools/perf/util/header.h | 1 +
> tools/perf/util/hist.c | 4 +-
> tools/perf/util/hist.h | 1 -
> tools/perf/util/machine.c | 145 +++----
> tools/perf/util/machine.h | 6 +-
> tools/perf/util/pmu.c | 47 +-
> tools/perf/util/sort.c | 7 +-
> tools/perf/util/stat.h | 2 +
> tools/perf/util/symbol.c | 13 +-
> tools/perf/util/syscalltbl.c | 8 +
> tools/perf/util/thread_map.c | 4 +-
> tools/perf/util/thread_map.h | 2 +-
> 47 files changed, 1577 insertions(+), 273 deletions(-)
> create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h
> create mode 100755 tools/perf/arch/powerpc/entry/syscalls/mksyscalltbl
Pulled, thanks a lot Arnaldo!
Ingo
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-4.16-3 tag
From: Michael Ellerman @ 2018-02-17 9:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: clabbe, clg, cyrilbur, linux-kernel, linuxppc-dev, nfont, npiggin
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
Hi Linus,
Please pull some more powerpc fixes for 4.16. Sorry to send a pull
request on the weekend, and a 2nd one this week, but one of these
commits fixes a boot crash which would be good to get in before rc2.
cheers
The following changes since commit 694a20dae6efc3803740971fa9f7c86b8c8d4685:
Merge tag 'powerpc-4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2018-02-14 10:06:41 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.16-3
for you to fetch changes up to 2c10636a0b9c689450e85f9945583920f50337c9:
powerpc/pseries: Check for zero filled ibm,dynamic-memory property (2018-02-16 21:34:14 +1100)
----------------------------------------------------------------
powerpc fixes for 4.16 #3
The main attraction is a fix for a bug in the new drmem code, which was causing
an oops on boot on some versions of Qemu.
There's also a fix for XIVE (Power9 interrupt controller) on KVM, as well as a
few other minor fixes.
Thanks to:
Corentin Labbe, Cyril Bur, Cédric Le Goater, Daniel Black, Nathan Fontenot,
Nicholas Piggin.
----------------------------------------------------------------
Corentin Labbe (1):
powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n
Cyril Bur (1):
powerpc: Expose TSCR via sysfs only on powernv
Cédric Le Goater (1):
powerpc/xive: Use hw CPU ids when configuring the CPU queues
Nathan Fontenot (1):
powerpc/pseries: Check for zero filled ibm,dynamic-memory property
Nicholas Piggin (1):
powerpc/powernv: IMC fix out of bounds memory access at shutdown
arch/powerpc/include/asm/topology.h | 3 +++
arch/powerpc/kernel/sysfs.c | 6 ++++--
arch/powerpc/mm/drmem.c | 8 ++++++++
arch/powerpc/platforms/powernv/opal-imc.c | 6 ++++--
arch/powerpc/sysdev/xive/spapr.c | 16 ++++++++++------
5 files changed, 29 insertions(+), 10 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox