* [PATCH 2/2] cpufreq: scpi: remove arm_big_little dependency
From: Sudeep Holla @ 2018-01-10 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110041905.GC3335@vireshk-i7>
On 10/01/18 04:19, Viresh Kumar wrote:
> On 09-01-18, 16:49, Sudeep Holla wrote:
>> +static int
>> +scpi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
>> {
>> - return scpi_ops->get_transition_latency(cpu_dev);
>> + int cpu, domain, tdomain;
>> + struct device *tcpu_dev;
>> +
>> + domain = scpi_ops->device_domain_id(cpu_dev);
>> + if (domain < 0)
>> + return domain;
>> +
>> + for_each_possible_cpu(cpu) {
>> + if (cpu == cpu_dev->id)
>> + continue;
>> +
>> + tcpu_dev = get_cpu_device(cpu);
>> + if (!tcpu_dev)
>> + continue;
>> +
>> + tdomain = scpi_ops->device_domain_id(tcpu_dev);
>> + if (tdomain == domain)
>> + cpumask_set_cpu(cpu, cpumask);
>> + }
>> +
>> + return 0;
>> }
>
> So this is the main thing you want to achieve ? i.e. get the
> policy->cpus from scpi_ops, right ?
>
>From the looks of it yes, but...
> Why can't we update .init_opp_table() to include policy as a parameter
> and let individual stub drivers update policy->cpus then ?
>
Possible, again but ...
There are few reasons why I would like remove scpi dependency on bL driver:
1. It has a notion of big and little which may not be true but that not
much of a problem.
2. MAX_CLUSTER = 2 and scpi is getting used on multi-cluster systems
though it was first tested on Juno which was bL system. There are
quite a few internal FVP platforms that can manage to run with just
proper DT with this change.
3. raw_cpu_to_cluster still calls topology_physical_package_id which
breaks on these platforms and also with introduction of ACPI PPTT it
will break on all ARM64 platforms.
4. We can still leave usage of topology_physical_package_id as is in
arm_big_little.c worst case if it's going to be used only on ARM32
For ARM64, topology_physical_package_id will be changed to give
actual physical socket number which will be 0 for all multi-cluster
(including bL) systems as along as they are single chip.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 31/33] dma-direct: reject too small dma masks
From: Robin Murphy @ 2018-01-10 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080027.13879-32-hch@lst.de>
On 10/01/18 08:00, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-direct.h | 1 +
> lib/dma-direct.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index 4788bf0bf683..bcdb1a3e4b1f 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -42,5 +42,6 @@ void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> gfp_t gfp, unsigned long attrs);
> void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
> dma_addr_t dma_addr, unsigned long attrs);
> +int dma_direct_supported(struct device *dev, u64 mask);
>
> #endif /* _LINUX_DMA_DIRECT_H */
> diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> index 784a68dfdbe3..40b1f92f2214 100644
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -122,6 +122,24 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
> return nents;
> }
>
> +int dma_direct_supported(struct device *dev, u64 mask)
> +{
> +#ifdef CONFIG_ZONE_DMA
> + if (mask < DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
> + return 0;
> +#else
> + /*
> + * Because 32-bit DMA masks are so common we expect every architecture
> + * to be able to satisfy them - either by not supporting more physical
> + * memory, or by providing a ZONE_DMA32. If neither is the case, the
> + * architecture needs to use an IOMMU instead of the direct mapping.
> + */
> + if (mask < DMA_BIT_MASK(32))
> + return 0;
Do you think it's worth the effort to be a little more accommodating
here? i.e.:
return dma_max_pfn(dev) >= max_pfn;
We seem to have a fair few 28-31 bit masks for older hardware which
probably associates with host systems packing equivalently small amounts
of RAM.
Otherwise though,
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Robin.
> +#endif
> + return 1;
> +}
> +
> static int dma_direct_mapping_error(struct device *dev, dma_addr_t dma_addr)
> {
> return dma_addr == DIRECT_MAPPING_ERROR;
> @@ -132,6 +150,7 @@ const struct dma_map_ops dma_direct_ops = {
> .free = dma_direct_free,
> .map_page = dma_direct_map_page,
> .map_sg = dma_direct_map_sg,
> + .dma_supported = dma_direct_supported,
> .mapping_error = dma_direct_mapping_error,
> };
> EXPORT_SYMBOL(dma_direct_ops);
>
^ permalink raw reply
* [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers
From: Arnd Bergmann @ 2018-01-10 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109223126.13093-4-jae.hyun.yoo@linux.intel.com>
On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
<jae.hyun.yoo@linux.intel.com> wrote:
> This commit adds driver implementation for Aspeed PECI. Also adds
> generic peci.h and peci_ioctl.h files to provide compatibility
> to peci drivers that can be implemented later e.g. Nuvoton's BMC
> SoC family.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> +#include <linux/clk.h>
> +#include <linux/crc8.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/jiffies.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/peci_ioctl.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/semaphore.h>
> +#include <linux/types.h>
> +#include <linux/uaccess.h>
semaphore.h is not used here and can be dropped.
> +static struct aspeed_peci *aspeed_peci_priv;
Try to avoid instance variables like this one. You should always be able to find
that pointer from whatever structure you were called with.
> + timeout = wait_for_completion_interruptible_timeout(
> + &priv->xfer_complete,
> + msecs_to_jiffies(priv->cmd_timeout_ms));
> +
> + dev_dbg(priv->dev, "INT_STS : 0x%08x\n", priv->sts);
> + if (!regmap_read(priv->regmap, AST_PECI_CMD, &peci_state))
> + dev_dbg(priv->dev, "PECI_STATE : 0x%lx\n",
> + PECI_CMD_STS_GET(peci_state));
> + else
> + dev_dbg(priv->dev, "PECI_STATE : read error\n");
> +
> + if (timeout <= 0 || !(priv->sts & PECI_INT_CMD_DONE)) {
> + if (timeout <= 0) {
> + dev_dbg(priv->dev, "Timeout waiting for a response!\n");
> + rc = -ETIME;
> + } else {
> + dev_dbg(priv->dev, "No valid response!\n");
> + rc = -EFAULT;
> + }
> + return rc;
> + }
You don't seem to handle -ERESTARTSYS correct here. Either do it
right, or drop the _interruptible part above.
> +typedef int (*ioctl_fn)(struct aspeed_peci *, void *);
> +
> +static ioctl_fn peci_ioctl_fn[PECI_CMD_MAX] = {
> + ioctl_xfer_msg,
> + ioctl_ping,
> + ioctl_get_dib,
> + ioctl_get_temp,
> + ioctl_rd_pkg_cfg,
> + ioctl_wr_pkg_cfg,
> + ioctl_rd_ia_msr,
> + NULL, /* Reserved */
> + ioctl_rd_pci_cfg,
> + NULL, /* Reserved */
> + ioctl_rd_pci_cfg_local,
> + ioctl_wr_pci_cfg_local,
> +};
> +
> +
> +long peci_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> +{
> + struct aspeed_peci *priv;
> + long ret = 0;
> + void __user *argp = (void __user *)arg;
> + int timeout = PECI_IDLE_CHECK_TIMEOUT;
> + u8 msg[sizeof(struct peci_xfer_msg)];
> + unsigned int peci_cmd, msg_size;
> + u32 cmd_sts;
> +
> + /*
> + * Treat it as an inter module call when filp is null but only in case
> + * the private data is initialized.
> + */
> + if (filp)
> + priv = container_of(filp->private_data,
> + struct aspeed_peci, miscdev);
> + else
> + priv = aspeed_peci_priv;
Drop this.
> + if (!priv)
> + return -ENXIO;
> +
> + switch (cmd) {
> + case PECI_IOC_XFER:
> + case PECI_IOC_PING:
> + case PECI_IOC_GET_DIB:
> + case PECI_IOC_GET_TEMP:
> + case PECI_IOC_RD_PKG_CFG:
> + case PECI_IOC_WR_PKG_CFG:
> + case PECI_IOC_RD_IA_MSR:
> + case PECI_IOC_RD_PCI_CFG:
> + case PECI_IOC_RD_PCI_CFG_LOCAL:
> + case PECI_IOC_WR_PCI_CFG_LOCAL:
> + peci_cmd = _IOC_TYPE(cmd) - PECI_IOC_BASE;
> + msg_size = _IOC_SIZE(cmd);
> + break;
Having to keep the switch() statement and the array above seems a
little fragile. Can you just do one or the other?
Regarding the command set, you have both a low-level PECI_IOC_XFER
interface and a high-level interface. Can you explain why? I'd think that
generally speaking it's better to have only one of the two.
> + /* Check command sts and bus idle state */
> + while (!regmap_read(priv->regmap, AST_PECI_CMD, &cmd_sts)
> + && (cmd_sts & (PECI_CMD_STS_MASK | PECI_CMD_PIN_MON))) {
> + if (timeout-- < 0) {
> + dev_dbg(priv->dev, "Timeout waiting for idle state!\n");
> + ret = -ETIME;
> + goto out;
> + }
> + usleep_range(10000, 11000);
> + };
To implement timeout, it's better to replace the counter with a
jiffies/time_before or ktime_get()/ktime_before() check, since usleep_range()
is might sleep considerably longer than expected.
> +EXPORT_SYMBOL_GPL(peci_ioctl);
No user of this, so drop it.
> +static int aspeed_peci_open(struct inode *inode, struct file *filp)
> +{
> + struct aspeed_peci *priv =
> + container_of(filp->private_data, struct aspeed_peci, miscdev);
> +
> + atomic_inc(&priv->ref_count);
> +
> + dev_dbg(priv->dev, "ref_count : %d\n", atomic_read(&priv->ref_count));
> +
> + return 0;
> +}
> +
> +static int aspeed_peci_release(struct inode *inode, struct file *filp)
> +{
> + struct aspeed_peci *priv =
> + container_of(filp->private_data, struct aspeed_peci, miscdev);
> +
> + atomic_dec(&priv->ref_count);
> +
> + dev_dbg(priv->dev, "ref_count : %d\n", atomic_read(&priv->ref_count));
> +
> + return 0;
> +}
Nothing uses that reference count, drop it.
> new file mode 100644
> index 0000000..66322c6
> --- /dev/null
> +++ b/include/misc/peci.h
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017 Intel Corporation
> +
> +#ifndef __PECI_H
> +#define __PECI_H
> +
> +#include <linux/peci_ioctl.h>
> +
> +long peci_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
> +
> +#endif /* __PECI_H */
Not used anywhere.
> diff --git a/include/uapi/linux/peci_ioctl.h b/include/uapi/linux/peci_ioctl.h
> new file mode 100644
> index 0000000..8386848
> --- /dev/null
> +++ b/include/uapi/linux/peci_ioctl.h
> @@ -0,0 +1,270 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2017 Intel Corporation
> +
> +#ifndef __PECI_IOCTL_H
> +#define __PECI_IOCTL_H
> +
> +#include <linux/ioctl.h>
> +
> +/* Base Address of 48d */
> +#define PECI_BASE_ADDR 0x30 /* The PECI client's default address of 0x30 */
> +#define PECI_OFFSET_MAX 8 /* Max numver of CPU clients */
> +
> +/* PCI Access */
> +#define MAX_PCI_READ_LEN 24 /* Number of bytes of the PCI Space read */
> +
> +#define PCI_BUS0_CPU0 0x00
> +#define PCI_BUS0_CPU1 0x80
> +#define PCI_CPUBUSNO_BUS 0x00
> +#define PCI_CPUBUSNO_DEV 0x08
> +#define PCI_CPUBUSNO_FUNC 0x02
> +#define PCI_CPUBUSNO 0xcc
> +#define PCI_CPUBUSNO_1 0xd0
> +#define PCI_CPUBUSNO_VALID 0xd4
I can't tell for sure, but this file seems to be mixing the kernel API with
hardware specific macros that are not needed in user space. Can you move
some of this file into the driver itself?
This might go back to the previous question about the high-level and
low-level interfaces: if you can drop the low-level ioctl interface, more
of this header can become private to the driver.
> +/* Package Identifier Read Parameter Value */
> +#define PKG_ID_CPU_ID 0x0000 /* 0 - CPUID Info */
> +#define PKG_ID_PLATFORM_ID 0x0001 /* 1 - Platform ID */
> +#define PKG_ID_UNCORE_ID 0x0002 /* 2 - Uncore Device ID */
> +#define PKG_ID_MAX_THREAD_ID 0x0003 /* 3 - Max Thread ID */
> +#define PKG_ID_MICROCODE_REV 0x0004 /* 4 - CPU Microcode Update Revision */
> +#define PKG_ID_MACHINE_CHECK_STATUS 0x0005 /* 5 - Machine Check Status */
> +
> +/* RdPkgConfig Index */
> +#define MBX_INDEX_CPU_ID 0 /* Package Identifier Read */
> +#define MBX_INDEX_VR_DEBUG 1 /* VR Debug */
> +#define MBX_INDEX_PKG_TEMP_READ 2 /* Package Temperature Read */
> +#define MBX_INDEX_ENERGY_COUNTER 3 /* Energy counter */
> +#define MBX_INDEX_ENERGY_STATUS 4 /* DDR Energy Status */
> +#define MBX_INDEX_WAKE_MODE_BIT 5 /* "Wake on PECI" Mode bit */
> +#define MBX_INDEX_EPI 6 /* Efficient Performance Indication */
Who defines these constants? Are they specific to the aspeed BMC, to the HECI
protocol, or to a particular version of the remote endpoint?
> +#pragma pack(push, 1)
> +struct peci_xfer_msg {
> + unsigned char client_addr;
> + unsigned char tx_len;
> + unsigned char rx_len;
> + unsigned char tx_buf[MAX_BUFFER_SIZE];
> + unsigned char rx_buf[MAX_BUFFER_SIZE];
> +};
> +#pragma pack(pop)
> +
> +struct peci_ping_msg {
> + unsigned char target;
> +};
> +
> +struct peci_get_dib_msg {
> + unsigned char target;
> + unsigned int dib;
> +};
> +
> +struct peci_get_temp_msg {
> + unsigned char target;
> + signed short temp_raw;
> +};
Aside from what Greg already said about the types, please be careful to
also avoid implicit padding in the API data structures, including the end of the
structure.
> +#define PECI_IOC_RD_PCI_CFG \
> + _IOWR(PECI_IOC_BASE + PECI_CMD_RD_PCI_CFG, 0, \
> + struct peci_rd_pci_cfg_msg)
> +
> +#define PECI_IOC_RD_PCI_CFG_LOCAL \
> + _IOWR(PECI_IOC_BASE + PECI_CMD_RD_PCI_CFG_LOCAL, 0, \
> + struct peci_rd_pci_cfg_local_msg)
> +
> +#define PECI_IOC_WR_PCI_CFG_LOCAL \
> + _IOWR(PECI_IOC_BASE + PECI_CMD_WR_PCI_CFG_LOCAL, 0, \
> + struct peci_wr_pci_cfg_local_msg)
Can you give some background on what these do? In particular, who
is configuring whose PCI devices?
Arnd
^ permalink raw reply
* [PATCH 20/33] dma-mapping: clear harmful GFP_* flags in common code
From: Robin Murphy @ 2018-01-10 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080027.13879-21-hch@lst.de>
On 10/01/18 08:00, Christoph Hellwig wrote:
[...]
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 9f28b2fa329e..88bcb1a8211d 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -518,6 +518,13 @@ static inline void *dma_alloc_attrs(struct device *dev, size_t size,
> if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr))
> return cpu_addr;
>
> + /*
> + * Let the implementation decide on the zone to allocate from, and
> + * decide on the way of zeroing the memory given that the memory
> + * returned should always be zeroed.
> + */
Just a note that if we're all happy to enshrine the "allocations are
always zeroed" behaviour in the API (I am too, for the record), we
should remember to follow up once the dust settles to update the docs
and I guess just #define dma_zalloc_coherent dma_alloc_coherent.
Robin.
> + flag &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM | __GFP_ZERO);
> +
> if (!arch_dma_alloc_attrs(&dev, &flag))
> return NULL;
> if (!ops->alloc)
>
^ permalink raw reply
* [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
From: Yixun Lan @ 2018-01-10 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515569324.5048.103.camel@baylibre.com>
Hi Jerome:
On 01/10/2018 03:28 PM, Jerome Brunet wrote:
> On Wed, 2018-01-10 at 10:12 +0800, Yixun Lan wrote:
>>
>> On 01/08/18 16:52, Jerome Brunet wrote:
>>> On Mon, 2018-01-08 at 15:33 +0800, Yixun Lan wrote:
>>>> These two patches are general improvement for meson pinctrl driver.
>>>> It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
>>>> one hardware block even its pin groups live inside two differet hardware domains,
>>>> which for example EE vs AO domain here.
>>>>
>>>> This idea is motivated by Martin's question at [1]
>>>>
>>>> [1]
>>>> http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw at mail.gmail.com
>>>>
>>>>
>>>> Yixun Lan (2):
>>>> pinctrl: meson: introduce a macro to have name/groups seperated
>>>> pinctrl: meson-axg: correct the pin expansion of UART_AO_B
>>>>
>>>> drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
>>>> drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
>>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> Hi Yixun,
>>>
>>> Honestly, I don't like the idea. I think it adds an unnecessary complexity.
>>> I don't see the point of FUNCTION_EX(uart_ao_b, _z) when you could simply write
>>> FUNCTION(uart_ao_b_z) ... especially when there is just a couple of function per
>>> SoC available on different domains.
>>>
>>> A pinctrl driver can already be challenging to understand at first, let's keep
>>> it simple and avoid adding more macros.
>>>
>>
>> Hi Jerome?
>> In my opinion, the idea of keeping one uniform 'function' in DT (thus
>> introducing another macro) is worth considering. It would make the DT
>> part much clean.
>
> Ok this is your opinion. I don't share it. Keeping function names tidy is good,
> I don't think we need another macro to do so.
>
>> And yes, it's a trade-off here, either we 1) do more in code to make
>> DT clean or 2) do nothing in the code level to make DT live with it.
>
> I don't see how adding a macro doing just string concatenation is going to make
> anything more clean. It does not prevent one to write FUNCTION_EX(uart_ao_b,
> _gpioz), resulting in uart_ao_b_gpioz, which is what is apparently considered
> 'not clean'
>
for the benefits of introducing macro 'FUNCTION_EX', it will end with
.name = "uart_ao_b", -> same for both EE, AO domain, and it will match
the DT part (although still different for '.groups')
> BTW, there no cleanness issue here, the name is just out of the 'usual scheme'
> but there is no problem with. If you want to change this, and
> s/uart_ao_b_gpioz/uart_ao_b_z/, now is the time to change it.
>
I'd rather *NOT* to push a pinctrl patch for just changing
'uart_ao_b_gpioz' to 'uart_ao_b_z' (it's a cosmetic change, and still
end with two different name - 'uart_ao_b_gpioz/z' & 'uart_ao_b' in DT)
>>
>> Yixun
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
^ permalink raw reply
* [PATCH 27/33] dma-direct: use node local allocations for coherent memory
From: Robin Murphy @ 2018-01-10 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080027.13879-28-hch@lst.de>
On 10/01/18 08:00, Christoph Hellwig wrote:
> To preserve the x86 behavior.
And combined with patch 10/22 of the SWIOTLB refactoring, this means
SWIOTLB allocations will also end up NUMA-aware, right? Great, that's
what we want on arm64 too :)
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> lib/dma-direct.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> index a9ae98be7af3..f04a424f91fa 100644
> --- a/lib/dma-direct.c
> +++ b/lib/dma-direct.c
> @@ -38,7 +38,7 @@ static void *dma_direct_alloc(struct device *dev, size_t size,
> if (gfpflags_allow_blocking(gfp))
> page = dma_alloc_from_contiguous(dev, count, page_order, gfp);
> if (!page)
> - page = alloc_pages(gfp, page_order);
> + page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
> if (!page)
> return NULL;
>
>
^ permalink raw reply
* [PATCH 0/7] arm64: move literal data into .rodata section
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
Prevent inadvertently creating speculative gadgets by moving literal data
into the .rodata section.
Patch #1 enables this for C code, by reverting a change that disables the
GCC feature implementing this. Note that this conflicts with the mitigation
of erratum #843419 for Cortex-A53.
Patch #2 - #7 update the crypto asm code to move sboxes and round constant
tables (which may or may not be hiding 'interesting' opcodes) from .text
to .rodata
Ard Biesheuvel (7):
arm64: kernel: avoid executable literal pools
arm64/crypto: aes-cipher: move S-box to .rodata section
arm64/crypto: aes-neon: move literal data to .rodata section
arm64/crypto: crc32: move literal data to .rodata section
arm64/crypto: crct10dif: move literal data to .rodata section
arm64/crypto: sha2-ce: move the round constant table to .rodata
section
arm64/crypto: sha1-ce: get rid of literal pool
arch/arm64/Makefile | 4 ++--
arch/arm64/crypto/aes-cipher-core.S | 19 ++++++++++---------
arch/arm64/crypto/aes-neon.S | 8 ++++----
arch/arm64/crypto/crc32-ce-core.S | 7 ++++---
arch/arm64/crypto/crct10dif-ce-core.S | 17 +++++++++--------
arch/arm64/crypto/sha1-ce-core.S | 20 +++++++++-----------
arch/arm64/crypto/sha2-ce-core.S | 4 +++-
7 files changed, 41 insertions(+), 38 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/7] arm64: kernel: avoid executable literal pools
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Recent versions of GCC will emit literals into a separate .rodata section
rather than interspersed with the instruction stream. We disabled this
in commit 67dfa1751ce71 ("arm64: errata: Add -mpc-relative-literal-loads
to build flags"), because it uses adrp/add pairs to reference these
literals even when building with -mcmodel=large, which breaks module
loading when we have the mitigation for Cortex-A53 erratum #843419
enabled.
However, due to the recent discoveries regarding speculative execution,
we should avoid putting data into executable sections, to prevent
creating speculative gadgets inadvertently.
So set -mpc-relative-literal-loads only for modules, and only if the
A53 erratum is enabled.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index b481b4a7c011..bd7cb205e28a 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -26,7 +26,8 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
ifeq ($(call ld-option, --fix-cortex-a53-843419),)
$(warning ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum)
else
-LDFLAGS_vmlinux += --fix-cortex-a53-843419
+LDFLAGS_vmlinux += --fix-cortex-a53-843419
+KBUILD_CFLAGS_MODULE += $(call cc-option, -mpc-relative-literal-loads)
endif
endif
@@ -51,7 +52,6 @@ endif
KBUILD_CFLAGS += -mgeneral-regs-only $(lseinstr) $(brokengasinst)
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
-KBUILD_CFLAGS += $(call cc-option, -mpc-relative-literal-loads)
KBUILD_AFLAGS += $(lseinstr) $(brokengasinst)
KBUILD_CFLAGS += $(call cc-option,-mabi=lp64)
--
2.11.0
^ permalink raw reply related
* [PATCH 2/7] arm64/crypto: aes-cipher: move S-box to .rodata section
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Move the AES inverse S-box to the .rodata section where it is safe from
abuse by speculation.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-cipher-core.S | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/crypto/aes-cipher-core.S b/arch/arm64/crypto/aes-cipher-core.S
index 6d2445d603cc..3a44eada2347 100644
--- a/arch/arm64/crypto/aes-cipher-core.S
+++ b/arch/arm64/crypto/aes-cipher-core.S
@@ -125,6 +125,16 @@ CPU_BE( rev w7, w7 )
ret
.endm
+ENTRY(__aes_arm64_encrypt)
+ do_crypt fround, crypto_ft_tab, crypto_ft_tab + 1, 2
+ENDPROC(__aes_arm64_encrypt)
+
+ .align 5
+ENTRY(__aes_arm64_decrypt)
+ do_crypt iround, crypto_it_tab, __aes_arm64_inverse_sbox, 0
+ENDPROC(__aes_arm64_decrypt)
+
+ .section ".rodata", "a"
.align L1_CACHE_SHIFT
.type __aes_arm64_inverse_sbox, %object
__aes_arm64_inverse_sbox:
@@ -161,12 +171,3 @@ __aes_arm64_inverse_sbox:
.byte 0x17, 0x2b, 0x04, 0x7e, 0xba, 0x77, 0xd6, 0x26
.byte 0xe1, 0x69, 0x14, 0x63, 0x55, 0x21, 0x0c, 0x7d
.size __aes_arm64_inverse_sbox, . - __aes_arm64_inverse_sbox
-
-ENTRY(__aes_arm64_encrypt)
- do_crypt fround, crypto_ft_tab, crypto_ft_tab + 1, 2
-ENDPROC(__aes_arm64_encrypt)
-
- .align 5
-ENTRY(__aes_arm64_decrypt)
- do_crypt iround, crypto_it_tab, __aes_arm64_inverse_sbox, 0
-ENDPROC(__aes_arm64_decrypt)
--
2.11.0
^ permalink raw reply related
* [PATCH 3/7] arm64/crypto: aes-neon: move literal data to .rodata section
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Move the S-boxes and some other literals to the .rodata section where
it is safe from being exploited by speculative execution.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-neon.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index f1e3aa2732f9..1c7b45b7268e 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arch/arm64/crypto/aes-neon.S
@@ -32,10 +32,10 @@
/* preload the entire Sbox */
.macro prepare, sbox, shiftrows, temp
- adr \temp, \sbox
movi v12.16b, #0x1b
- ldr q13, \shiftrows
- ldr q14, .Lror32by8
+ ldr_l q13, \shiftrows, \temp
+ ldr_l q14, .Lror32by8, \temp
+ adr_l \temp, \sbox
ld1 {v16.16b-v19.16b}, [\temp], #64
ld1 {v20.16b-v23.16b}, [\temp], #64
ld1 {v24.16b-v27.16b}, [\temp], #64
@@ -272,7 +272,7 @@
#include "aes-modes.S"
- .text
+ .section ".rodata", "a"
.align 6
.LForward_Sbox:
.byte 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5
--
2.11.0
^ permalink raw reply related
* [PATCH 4/7] arm64/crypto: crc32: move literal data to .rodata section
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Move CRC32 literal data to the .rodata section where it is safe from
being exploited by speculative execution.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/crc32-ce-core.S | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/crc32-ce-core.S b/arch/arm64/crypto/crc32-ce-core.S
index 18f5a8442276..16ed3c7ebd37 100644
--- a/arch/arm64/crypto/crc32-ce-core.S
+++ b/arch/arm64/crypto/crc32-ce-core.S
@@ -50,7 +50,7 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
- .text
+ .section ".rodata", "a"
.align 6
.cpu generic+crypto+crc
@@ -115,12 +115,13 @@
* uint crc32_pmull_le(unsigned char const *buffer,
* size_t len, uint crc32)
*/
+ .text
ENTRY(crc32_pmull_le)
- adr x3, .Lcrc32_constants
+ adr_l x3, .Lcrc32_constants
b 0f
ENTRY(crc32c_pmull_le)
- adr x3, .Lcrc32c_constants
+ adr_l x3, .Lcrc32c_constants
0: bic LEN, LEN, #15
ld1 {v1.16b-v4.16b}, [BUF], #0x40
--
2.11.0
^ permalink raw reply related
* [PATCH 5/7] arm64/crypto: crct10dif: move literal data to .rodata section
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Move the CRC-T10DIF literal data to the .rodata section where it is
safe from being exploited by speculative execution.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/crct10dif-ce-core.S | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/crypto/crct10dif-ce-core.S b/arch/arm64/crypto/crct10dif-ce-core.S
index d5b5a8c038c8..f179c01bd55c 100644
--- a/arch/arm64/crypto/crct10dif-ce-core.S
+++ b/arch/arm64/crypto/crct10dif-ce-core.S
@@ -128,7 +128,7 @@ CPU_LE( ext v7.16b, v7.16b, v7.16b, #8 )
// XOR the initial_crc value
eor v0.16b, v0.16b, v10.16b
- ldr q10, rk3 // xmm10 has rk3 and rk4
+ ldr_l q10, rk3, x8 // xmm10 has rk3 and rk4
// type of pmull instruction
// will determine which constant to use
@@ -184,13 +184,13 @@ CPU_LE( ext v12.16b, v12.16b, v12.16b, #8 )
// fold the 8 vector registers to 1 vector register with different
// constants
- ldr q10, rk9
+ ldr_l q10, rk9, x8
.macro fold16, reg, rk
pmull v8.1q, \reg\().1d, v10.1d
pmull2 \reg\().1q, \reg\().2d, v10.2d
.ifnb \rk
- ldr q10, \rk
+ ldr_l q10, \rk, x8
.endif
eor v7.16b, v7.16b, v8.16b
eor v7.16b, v7.16b, \reg\().16b
@@ -251,7 +251,7 @@ CPU_LE( ext v1.16b, v1.16b, v1.16b, #8 )
// get rid of the extra data that was loaded before
// load the shift constant
- adr x4, tbl_shf_table + 16
+ adr_l x4, tbl_shf_table + 16
sub x4, x4, arg3
ld1 {v0.16b}, [x4]
@@ -275,7 +275,7 @@ CPU_LE( ext v1.16b, v1.16b, v1.16b, #8 )
_128_done:
// compute crc of a 128-bit value
- ldr q10, rk5 // rk5 and rk6 in xmm10
+ ldr_l q10, rk5, x8 // rk5 and rk6 in xmm10
// 64b fold
ext v0.16b, vzr.16b, v7.16b, #8
@@ -291,7 +291,7 @@ _128_done:
// barrett reduction
_barrett:
- ldr q10, rk7
+ ldr_l q10, rk7, x8
mov v0.d[0], v7.d[1]
pmull v0.1q, v0.1d, v10.1d
@@ -321,7 +321,7 @@ CPU_LE( ext v7.16b, v7.16b, v7.16b, #8 )
b.eq _128_done // exactly 16 left
b.lt _less_than_16_left
- ldr q10, rk1 // rk1 and rk2 in xmm10
+ ldr_l q10, rk1, x8 // rk1 and rk2 in xmm10
// update the counter. subtract 32 instead of 16 to save one
// instruction from the loop
@@ -333,7 +333,7 @@ CPU_LE( ext v7.16b, v7.16b, v7.16b, #8 )
_less_than_16_left:
// shl r9, 4
- adr x0, tbl_shf_table + 16
+ adr_l x0, tbl_shf_table + 16
sub x0, x0, arg3
ld1 {v0.16b}, [x0]
movi v9.16b, #0x80
@@ -345,6 +345,7 @@ ENDPROC(crc_t10dif_pmull)
// precomputed constants
// these constants are precomputed from the poly:
// 0x8bb70000 (0x8bb7 scaled to 32 bits)
+ .section ".rodata", "a"
.align 4
// Q = 0x18BB70000
// rk1 = 2^(32*3) mod Q << 32
--
2.11.0
^ permalink raw reply related
* [PATCH 6/7] arm64/crypto: sha2-ce: move the round constant table to .rodata section
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Move the SHA2 round constant table to the .rodata section where it is
safe from being exploited by speculative execution.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha2-ce-core.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index 679c6c002f4f..4c3c89b812ce 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -53,6 +53,7 @@
/*
* The SHA-256 round constants
*/
+ .section ".rodata", "a"
.align 4
.Lsha2_rcon:
.word 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5
@@ -76,9 +77,10 @@
* void sha2_ce_transform(struct sha256_ce_state *sst, u8 const *src,
* int blocks)
*/
+ .text
ENTRY(sha2_ce_transform)
/* load round constants */
- adr x8, .Lsha2_rcon
+ adr_l x8, .Lsha2_rcon
ld1 { v0.4s- v3.4s}, [x8], #64
ld1 { v4.4s- v7.4s}, [x8], #64
ld1 { v8.4s-v11.4s}, [x8], #64
--
2.11.0
^ permalink raw reply related
* [PATCH 7/7] arm64/crypto: sha1-ce: get rid of literal pool
From: Ard Biesheuvel @ 2018-01-10 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110121142.18291-1-ard.biesheuvel@linaro.org>
Load the four SHA-1 round constants using immediates rather than literal
pool entries, to avoid having executable data that may be exploitable
under speculation attacks.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha1-ce-core.S | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 8550408735a0..46049850727d 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -58,12 +58,11 @@
sha1su1 v\s0\().4s, v\s3\().4s
.endm
- /*
- * The SHA1 round constants
- */
- .align 4
-.Lsha1_rcon:
- .word 0x5a827999, 0x6ed9eba1, 0x8f1bbcdc, 0xca62c1d6
+ .macro loadrc, k, val, tmp
+ movz \tmp, :abs_g0_nc:\val
+ movk \tmp, :abs_g1:\val
+ dup \k, \tmp
+ .endm
/*
* void sha1_ce_transform(struct sha1_ce_state *sst, u8 const *src,
@@ -71,11 +70,10 @@
*/
ENTRY(sha1_ce_transform)
/* load round constants */
- adr x6, .Lsha1_rcon
- ld1r {k0.4s}, [x6], #4
- ld1r {k1.4s}, [x6], #4
- ld1r {k2.4s}, [x6], #4
- ld1r {k3.4s}, [x6]
+ loadrc k0.4s, 0x5a827999, w6
+ loadrc k1.4s, 0x6ed9eba1, w6
+ loadrc k2.4s, 0x8f1bbcdc, w6
+ loadrc k3.4s, 0xca62c1d6, w6
/* load state */
ld1 {dgav.4s}, [x0]
--
2.11.0
^ permalink raw reply related
* [PATCH 02/22] arm64: rename swiotlb_dma_ops
From: Robin Murphy @ 2018-01-10 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080932.14157-3-hch@lst.de>
On 10/01/18 08:09, Christoph Hellwig wrote:
> We'll need that name for a generic implementation soon.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/mm/dma-mapping.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index f3a637b98487..6840426bbe77 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -368,7 +368,7 @@ static int __swiotlb_dma_mapping_error(struct device *hwdev, dma_addr_t addr)
> return 0;
> }
>
> -static const struct dma_map_ops swiotlb_dma_ops = {
> +static const struct dma_map_ops arm64_swiotlb_dma_ops = {
> .alloc = __dma_alloc,
> .free = __dma_free,
> .mmap = __swiotlb_mmap,
> @@ -923,7 +923,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
> const struct iommu_ops *iommu, bool coherent)
> {
> if (!dev->dma_ops)
> - dev->dma_ops = &swiotlb_dma_ops;
> + dev->dma_ops = &arm64_swiotlb_dma_ops;
>
> dev->archdata.dma_coherent = coherent;
> __iommu_setup_dma_ops(dev, dma_base, size, iommu);
>
^ permalink raw reply
* [PATCH] usb: dwc2: Fix endless deferral probe
From: Stefan Wahren @ 2018-01-10 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3eggC=XWLxr-A+pdaXj-0kMZ4aoX3hRyg5tLUknoDeBA@mail.gmail.com>
Hi Arnd,
Am 09.01.2018 um 22:33 schrieb Arnd Bergmann:
> On Tue, Jan 9, 2018 at 8:28 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> The dwc2 USB driver tries to find a generic PHY first and then look
>> for an old style USB PHY. In case of a valid generic PHY node without
>> a PHY driver, the PHY layer will return -EPROBE_DEFER forever. So dwc2
>> will never tries for an USB PHY.
>>
>> Fix this issue by finding a generic PHY and an old style USB PHY
>> at once.
> This would fix only one of the USB controllers (dwc2), but not the others
> that are affected. As I wrote in my suggested patch, dwc3 appears to be
> affected the same way, and all other host drivers that call usb_add_hcd()
> without first setting hcd->phy would suffer from this as well.
>
> If we go down the route of addressing it here in the hcd drivers, we should
> at least change all three of those, and hope this doesn't regress in
> another way.
>
> Arnd
i fully unterstand. But we leaving the path of "fixing a critical issue
on BCM2835" and go to "fixing multiple USB host controller". I do this
all in my spare time and don't have any of the other USB controller
available. So before i proceed with any other patch i like so see some
feedback from John, Greg or Felipe.
After finalizing this patch i think the chance is little that this would
be applied to 4.15. So i seems to me that we still revert my DT clean up
patch.
Stefan
^ permalink raw reply
* [PATCH] ARM: i.MX6: add new silicon revision number 1.6
From: Fabio Estevam @ 2018-01-10 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515502273.2493.9.camel@googlemail.com>
On Tue, Jan 9, 2018 at 10:51 AM, Christoph Fritz
<chf.fritz@googlemail.com> wrote:
> This patch adds new silicon revision number 1.6 as specified in document
> IMX6DQCEC.pdf.
>
> Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 08/22] swiotlb: wire up ->dma_supported in swiotlb_dma_ops
From: Robin Murphy @ 2018-01-10 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080932.14157-9-hch@lst.de>
On 10/01/18 08:09, Christoph Hellwig wrote:
> To properly reject too small DMA masks based on the addressability of the
> bounce buffer.
I reckon this is self-evident enough that it should simply be squashed
into the previous patch.
Robin.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> lib/swiotlb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 0fae2f45c3c0..539fd1099ba9 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -1128,5 +1128,6 @@ const struct dma_map_ops swiotlb_dma_ops = {
> .unmap_sg = swiotlb_unmap_sg_attrs,
> .map_page = swiotlb_map_page,
> .unmap_page = swiotlb_unmap_page,
> + .dma_supported = swiotlb_dma_supported,
> };
> #endif /* CONFIG_DMA_DIRECT_OPS */
>
^ permalink raw reply
* [PATCH linux dev-4.10 4/6] Documentation: dt-bindings: Add a generic PECI hwmon
From: Arnd Bergmann @ 2018-01-10 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109223126.13093-5-jae.hyun.yoo@linux.intel.com>
On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
<jae.hyun.yoo@linux.intel.com> wrote:
> This commit add a dt-bindings document for a generic PECI hwmon
> driver.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> ---
> .../devicetree/bindings/hwmon/peci-hwmon.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt b/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
> new file mode 100644
> index 0000000..20b86f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/peci-hwmon.txt
> @@ -0,0 +1,33 @@
> +* Generic PECI (Platform Environment Control Interface) hwmon driver.
> +
> +Dependency:
> +- This driver uses a PECI misc driver as a controller interface so one of PECI
> + misc drivers which provides compatible ioctls has to be enabled.
The binding should only explain how we describe the hardware in an
operating-system
independent way, but not talk about how an OS is supposed to implement those
drivers.
Having multiple drivers each provide an exported function is not possible
in Linux: it immediately breaks building an 'allyesconfig' kernel, and prevents
you from running the same kernel across multiple implementations, so that
has to be redesigned anyway.
> +Required properties:
> +- compatible: "peci-hwmon"
> +- cpu-id: Should contain CPU socket ID
> + - 0 ~ 7
> +
> +Optional properties:
> +- show-core: If this protperty is defined, core tmeperature attrubites will be
s/protperty/property/
s/tmeperature/temperature/
s/attrubites/attributes/
> + enumerated.
> +- dimm-nums: Should contain the number of DIMM slots that attached to each CPU
> + which is indicated by cpu-id.
> + 0 ~ 16 (default: 16)
> + In case of 0, DIMM temperature attrubites will not be enumerated.
Is this only an initial list that you expect to be extended in the
future, or is this
a complete list of sensors that can ever be connected to PECI?
Should this be PECI version specific?
Arnd
^ permalink raw reply
* [PATCH 10/22] swiotlb: refactor coherent buffer allocation
From: Robin Murphy @ 2018-01-10 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080932.14157-11-hch@lst.de>
On 10/01/18 08:09, Christoph Hellwig wrote:
> Factor out a new swiotlb_alloc_buffer helper that allocates DMA coherent
> memory from the swiotlb bounce buffer.
>
> This allows to simplify the swiotlb_alloc implemenation that uses
> dma_direct_alloc to try to allocate a reachable buffer first.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> lib/swiotlb.c | 122 +++++++++++++++++++++++++++++++---------------------------
> 1 file changed, 65 insertions(+), 57 deletions(-)
>
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 1a147f1354a1..bf2d19ee91c1 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -709,75 +709,79 @@ void swiotlb_tbl_sync_single(struct device *hwdev, phys_addr_t tlb_addr,
> }
> EXPORT_SYMBOL_GPL(swiotlb_tbl_sync_single);
>
> -void *
> -swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> - dma_addr_t *dma_handle, gfp_t flags)
> +static inline bool dma_coherent_ok(struct device *dev, dma_addr_t addr,
> + size_t size)
> {
> - bool warn = !(flags & __GFP_NOWARN);
> - dma_addr_t dev_addr;
> - void *ret;
> - int order = get_order(size);
> - u64 dma_mask = DMA_BIT_MASK(32);
> + u64 mask = DMA_BIT_MASK(32);
>
> - if (hwdev && hwdev->coherent_dma_mask)
> - dma_mask = hwdev->coherent_dma_mask;
> + if (dev && dev->coherent_dma_mask)
> + mask = dev->coherent_dma_mask;
> + return addr + size - 1 <= mask;
> +}
>
> - ret = (void *)__get_free_pages(flags, order);
> - if (ret) {
> - dev_addr = swiotlb_virt_to_bus(hwdev, ret);
> - if (dev_addr + size - 1 > dma_mask) {
> - /*
> - * The allocated memory isn't reachable by the device.
> - */
> - free_pages((unsigned long) ret, order);
> - ret = NULL;
> - }
> - }
> - if (!ret) {
> - /*
> - * We are either out of memory or the device can't DMA to
> - * GFP_DMA memory; fall back on map_single(), which
> - * will grab memory from the lowest available address range.
> - */
> - phys_addr_t paddr = map_single(hwdev, 0, size, DMA_FROM_DEVICE,
> - warn ? 0 : DMA_ATTR_NO_WARN);
> - if (paddr == SWIOTLB_MAP_ERROR)
> - goto err_warn;
> +static void *
> +swiotlb_alloc_buffer(struct device *dev, size_t size, dma_addr_t *dma_handle,
> + unsigned long attrs)
> +{
> + phys_addr_t phys_addr;
> +
> + if (swiotlb_force == SWIOTLB_NO_FORCE)
> + goto out_warn;
>
> - ret = phys_to_virt(paddr);
> - dev_addr = swiotlb_phys_to_dma(hwdev, paddr);
> + phys_addr = swiotlb_tbl_map_single(dev,
> + swiotlb_phys_to_dma(dev, io_tlb_start),
> + 0, size, DMA_FROM_DEVICE, 0);
> + if (phys_addr == SWIOTLB_MAP_ERROR)
> + goto out_warn;
>
> - /* Confirm address can be DMA'd by device */
> - if (dev_addr + size - 1 > dma_mask) {
> - printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
> - (unsigned long long)dma_mask,
> - (unsigned long long)dev_addr);
> + *dma_handle = swiotlb_phys_to_dma(dev, phys_addr);
nit: this should probably go after the dma_coherent_ok() check (as with
the original logic).
>
> - /*
> - * DMA_TO_DEVICE to avoid memcpy in unmap_single.
> - * The DMA_ATTR_SKIP_CPU_SYNC is optional.
> - */
> - swiotlb_tbl_unmap_single(hwdev, paddr,
> - size, DMA_TO_DEVICE,
> - DMA_ATTR_SKIP_CPU_SYNC);
> - goto err_warn;
> - }
> - }
> + if (dma_coherent_ok(dev, *dma_handle, size))
> + goto out_unmap;
>
> - *dma_handle = dev_addr;
> - memset(ret, 0, size);
> + memset(phys_to_virt(phys_addr), 0, size);
> + return phys_to_virt(phys_addr);
>
> - return ret;
> +out_unmap:
> + dev_warn(dev, "hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
> + (unsigned long long)(dev ? dev->coherent_dma_mask : 0),
> + (unsigned long long)*dma_handle);
>
> -err_warn:
> - if (warn && printk_ratelimit()) {
> - pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n",
> - dev_name(hwdev), size);
> + /*
> + * DMA_TO_DEVICE to avoid memcpy in unmap_single.
> + * DMA_ATTR_SKIP_CPU_SYNC is optional.
> + */
> + swiotlb_tbl_unmap_single(dev, phys_addr, size, DMA_TO_DEVICE,
> + DMA_ATTR_SKIP_CPU_SYNC);
> +out_warn:
> + if ((attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) {
> + dev_warn(dev,
> + "swiotlb: coherent allocation failed, size=%zu\n",
> + size);
> dump_stack();
> }
> -
> return NULL;
> }
> +
> +void *
> +swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flags)
> +{
> + int order = get_order(size);
> + unsigned long attrs = (flags & __GFP_NOWARN) ? DMA_ATTR_NO_WARN : 0;
> + void *ret;
> +
> + ret = (void *)__get_free_pages(flags, order);
> + if (ret) {
> + *dma_handle = swiotlb_virt_to_bus(hwdev, ret);
> + if (dma_coherent_ok(hwdev, *dma_handle, size)) {
> + memset(ret, 0, size);
> + return ret;
> + }
Aren't we leaking the pages here?
Robin.
> + }
> +
> + return swiotlb_alloc_buffer(hwdev, size, dma_handle, attrs);
> +}
> EXPORT_SYMBOL(swiotlb_alloc_coherent);
>
> static bool swiotlb_free_buffer(struct device *dev, size_t size,
> @@ -1103,6 +1107,10 @@ void *swiotlb_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> {
> void *vaddr;
>
> + /* temporary workaround: */
> + if (gfp & __GFP_NOWARN)
> + attrs |= DMA_ATTR_NO_WARN;
> +
> /*
> * Don't print a warning when the first allocation attempt fails.
> * swiotlb_alloc_coherent() will print a warning when the DMA memory
> @@ -1112,7 +1120,7 @@ void *swiotlb_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
>
> vaddr = dma_direct_alloc(dev, size, dma_handle, gfp, attrs);
> if (!vaddr)
> - vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
> + vaddr = swiotlb_alloc_buffer(dev, size, dma_handle, attrs);
> return vaddr;
> }
>
>
^ permalink raw reply
* [PATCH linux dev-4.10 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon
From: Arnd Bergmann @ 2018-01-10 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109223126.13093-7-jae.hyun.yoo@linux.intel.com>
On Tue, Jan 9, 2018 at 11:31 PM, Jae Hyun Yoo
<jae.hyun.yoo@linux.intel.com> wrote:
> This commit adds driver implementation for a generic PECI hwmon.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> +static int xfer_peci_msg(int cmd, void *pmsg)
> +{
> + int rc;
> +
> + mutex_lock(&peci_hwmon_lock);
> + rc = peci_ioctl(NULL, cmd, (unsigned long)pmsg);
> + mutex_unlock(&peci_hwmon_lock);
> +
> + return rc;
> +}
I said earlier that peci_ioctl() looked unused, that was obviously
wrong, but what you have here
is not a proper way to abstract a bus.
Maybe this can be done more like an i2c bus: make the peci controller
a bus device
and register all known target/index pairs as devices with the peci bus
type, and have
them probed from DT. The driver can then bind to each of those individually.
Not sure if that is getting to granular at that point, I'd have to
understand better
how it is expected to get used, and what the variances are between
implementations.
Arnd
^ permalink raw reply
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Andy Shevchenko @ 2018-01-10 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110015848.11480-3-sboyd@codeaurora.org>
On Tue, 2018-01-09 at 17:58 -0800, Stephen Boyd wrote:
> Some qcom platforms make some GPIOs or pins unavailable for use
> by non-secure operating systems, and thus reading or writing the
> registers for those pins will cause access control issues.
> Introduce a DT property to describe the set of GPIOs that are
> available for use so that higher level OSes are able to know what
> pins to avoid reading/writing.
> +- ngpios-ranges:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: Tuples of GPIO ranges (base, size) indicating
> + GPIOs available for use.
Can be name more particular?
We have on one hand gpio-range-list for mapping, on the other this one
might become generic.
So, there are few options (at least?) to consider:
1) re-use gpio-ranges
2) add a valid property to gpio-ranges
3) rename ngpios-ranges to something like gpio-valid-ranges (I don't
like it so much either, but for me it looks more descriptive than
ngpios-ranges)
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [RESEND PATCH v9 00/13] Add STM32 DFSDM support
From: Jonathan Cameron @ 2018-01-10 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110103607.GD9003@sirena.org.uk>
On 10 January 2018 10:36:07 GMT, Mark Brown <broonie@kernel.org> wrote:
>On Wed, Jan 10, 2018 at 11:13:02AM +0100, Arnaud Pouliquen wrote:
>
>> Jonathan's comment for you, posted for this version:
>> >So Mark, over to you. I'm happy if you want to do the immutable
>branch once
>> >any issue you find are fixed, or I can do it.
>> >I'm just looking for acks or a pull request now.
>
>Jonathan, this is a pretty weird way of doing things - the bulk of the
>series is for IIO so I'd have expected it to go in via the IIO tree.
>It's especially odd to end up with the driver which isn't a build
>dependency in my tree.
Hi Mark,
Sure, such a branch in IIO might have made more sense. I got it into my head that you
wanted to do it this way!
Didn't care myself as result is the same.
Oops if that wasn't your intent.
Ah well, all is well that ends well and thanks for this.
Jonathan
>
>The following changes since commit
>4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
>are available in the Git repository at:
>
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>tags/iio-asoc-sync
>
>for you to fetch changes up to
>16cbca06fa8288a4f58426fc898b141e12ee8008:
>
> IIO: consumer: allow to set buffer sizes (2018-01-10 10:30:14 +0000)
>
>----------------------------------------------------------------
>IIO: ST DFSDM support
>
>This is the IIO portion of some patches adding support for the ST DFSDM
>IP, it's shared with ASoC as the hardware is also used for audio.
>
>----------------------------------------------------------------
>Arnaud Pouliquen (10):
> docs: driver-api: add iio hw consumer section
> IIO: hw_consumer: add devm_iio_hw_consumer_alloc
> IIO: inkern: API for manipulating channel attributes
> IIO: Add DT bindings for sigma delta adc modulator
> IIO: ADC: add sigma delta modulator support
> IIO: add DT bindings for stm32 DFSDM filter
> IIO: ADC: add stm32 DFSDM core support
> IIO: ADC: add STM32 DFSDM sigma delta ADC support
> IIO: ADC: add stm32 DFSDM support for PDM microphone
> IIO: consumer: allow to set buffer sizes
>
>Lars-Peter Clausen (1):
> iio: Add hardware consumer buffer support
>
> .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 16 +
> .../bindings/iio/adc/sigma-delta-modulator.txt | 13 +
> .../bindings/iio/adc/st,stm32-dfsdm-adc.txt | 128 +++
> Documentation/driver-api/iio/hw-consumer.rst | 51 +
> Documentation/driver-api/iio/index.rst | 1 +
> drivers/iio/adc/Kconfig | 37 +
> drivers/iio/adc/Makefile | 3 +
> drivers/iio/adc/sd_adc_modulator.c | 68 ++
>drivers/iio/adc/stm32-dfsdm-adc.c | 1216
>++++++++++++++++++++
> drivers/iio/adc/stm32-dfsdm-core.c | 309 +++++
> drivers/iio/adc/stm32-dfsdm.h | 310 +++++
> drivers/iio/buffer/Kconfig | 10 +
> drivers/iio/buffer/Makefile | 1 +
> drivers/iio/buffer/industrialio-buffer-cb.c | 11 +
> drivers/iio/buffer/industrialio-hw-consumer.c | 247 ++++
> drivers/iio/inkern.c | 17 +-
> include/linux/iio/adc/stm32-dfsdm-adc.h | 18 +
> include/linux/iio/consumer.h | 37 +
> include/linux/iio/hw-consumer.h | 21 +
> include/linux/iio/iio.h | 28 -
> include/linux/iio/types.h | 28 +
> 21 files changed, 2537 insertions(+), 33 deletions(-)
>create mode 100644
>Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
>create mode 100644
>Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
>create mode 100644
>Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt
> create mode 100644 Documentation/driver-api/iio/hw-consumer.rst
> create mode 100644 drivers/iio/adc/sd_adc_modulator.c
> create mode 100644 drivers/iio/adc/stm32-dfsdm-adc.c
> create mode 100644 drivers/iio/adc/stm32-dfsdm-core.c
> create mode 100644 drivers/iio/adc/stm32-dfsdm.h
> create mode 100644 drivers/iio/buffer/industrialio-hw-consumer.c
> create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h
> create mode 100644 include/linux/iio/hw-consumer.h
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH 21/22] arm64: replace ZONE_DMA with ZONE_DMA32
From: Robin Murphy @ 2018-01-10 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080932.14157-22-hch@lst.de>
On 10/01/18 08:09, Christoph Hellwig wrote:
> arm64 uses ZONE_DMA for allocations below 32-bits. These days we
> name the zone for that ZONE_DMA32, which will allow to use the
> dma-direct and generic swiotlb code as-is, so rename it.
I do wonder if we could also "upgrade" GFP_DMA to GFP_DMA32 somehow when
!ZONE_DMA - there are almost certainly arm64 drivers out there using a
combination of GFP_DMA and streaming mappings which will no longer get
the guaranteed 32-bit addresses they expect after this. I'm not sure
quite how feasible that is, though :/
That said, I do agree that this is an appropriate change (the legacy of
GFP_DMA is obviously horrible), so, provided we get plenty of time to
find and fix the fallout when it lands:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Robin.
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/Kconfig | 2 +-
> arch/arm64/mm/dma-mapping.c | 6 +++---
> arch/arm64/mm/init.c | 16 ++++++++--------
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c9a7e9e1414f..6b6985f15d02 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -227,7 +227,7 @@ config GENERIC_CSUM
> config GENERIC_CALIBRATE_DELAY
> def_bool y
>
> -config ZONE_DMA
> +config ZONE_DMA32
> def_bool y
>
> config HAVE_GENERIC_GUP
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 6840426bbe77..0d641875b20e 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -95,9 +95,9 @@ static void *__dma_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flags,
> unsigned long attrs)
> {
> - if (IS_ENABLED(CONFIG_ZONE_DMA) &&
> + if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
> dev->coherent_dma_mask <= DMA_BIT_MASK(32))
> - flags |= GFP_DMA;
> + flags |= GFP_DMA32;
> if (dev_get_cma_area(dev) && gfpflags_allow_blocking(flags)) {
> struct page *page;
> void *addr;
> @@ -397,7 +397,7 @@ static int __init atomic_pool_init(void)
> page = dma_alloc_from_contiguous(NULL, nr_pages,
> pool_size_order, GFP_KERNEL);
> else
> - page = alloc_pages(GFP_DMA, pool_size_order);
> + page = alloc_pages(GFP_DMA32, pool_size_order);
>
> if (page) {
> int ret;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 00e7b900ca41..8f03276443c9 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -217,7 +217,7 @@ static void __init reserve_elfcorehdr(void)
> }
> #endif /* CONFIG_CRASH_DUMP */
> /*
> - * Return the maximum physical address for ZONE_DMA (DMA_BIT_MASK(32)). It
> + * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
> * currently assumes that for memory starting above 4G, 32-bit devices will
> * use a DMA offset.
> */
> @@ -233,8 +233,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
> {
> unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
>
> - if (IS_ENABLED(CONFIG_ZONE_DMA))
> - max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
> + if (IS_ENABLED(CONFIG_ZONE_DMA32))
> + max_zone_pfns[ZONE_DMA32] = PFN_DOWN(max_zone_dma_phys());
> max_zone_pfns[ZONE_NORMAL] = max;
>
> free_area_init_nodes(max_zone_pfns);
> @@ -251,9 +251,9 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
> memset(zone_size, 0, sizeof(zone_size));
>
> /* 4GB maximum for 32-bit only capable devices */
> -#ifdef CONFIG_ZONE_DMA
> +#ifdef CONFIG_ZONE_DMA32
> max_dma = PFN_DOWN(arm64_dma_phys_limit);
> - zone_size[ZONE_DMA] = max_dma - min;
> + zone_size[ZONE_DMA32] = max_dma - min;
> #endif
> zone_size[ZONE_NORMAL] = max - max_dma;
>
> @@ -266,10 +266,10 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
> if (start >= max)
> continue;
>
> -#ifdef CONFIG_ZONE_DMA
> +#ifdef CONFIG_ZONE_DMA32
> if (start < max_dma) {
> unsigned long dma_end = min(end, max_dma);
> - zhole_size[ZONE_DMA] -= dma_end - start;
> + zhole_size[ZONE_DMA32] -= dma_end - start;
> }
> #endif
> if (end > max_dma) {
> @@ -467,7 +467,7 @@ void __init arm64_memblock_init(void)
> early_init_fdt_scan_reserved_mem();
>
> /* 4GB maximum for 32-bit only capable devices */
> - if (IS_ENABLED(CONFIG_ZONE_DMA))
> + if (IS_ENABLED(CONFIG_ZONE_DMA32))
> arm64_dma_phys_limit = max_zone_dma_phys();
> else
> arm64_dma_phys_limit = PHYS_MASK + 1;
>
^ permalink raw reply
* [PATCH 22/22] arm64: use swiotlb_alloc and swiotlb_free
From: Robin Murphy @ 2018-01-10 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110080932.14157-23-hch@lst.de>
On 10/01/18 08:09, Christoph Hellwig wrote:
> The generic swiotlb_alloc and swiotlb_free routines already take care
> of CMA allocations and adding GFP_DMA32 where needed, so use them
> instead of the arm specific helpers.
It took a while to satisfy myself that the GFP_DMA(32) handling ends up
equivalent to the current behaviour, but I think it checks out. This
will certainly help with the long-overdue cleanup of this file that I've
had sat around half-finished for ages.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/mm/dma-mapping.c | 46 +++------------------------------------------
> 2 files changed, 4 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 6b6985f15d02..53205c02b18a 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -59,6 +59,7 @@ config ARM64
> select COMMON_CLK
> select CPU_PM if (SUSPEND || CPU_IDLE)
> select DCACHE_WORD_ACCESS
> + select DMA_DIRECT_OPS
> select EDAC_SUPPORT
> select FRAME_POINTER
> select GENERIC_ALLOCATOR
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 0d641875b20e..a96ec0181818 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -91,46 +91,6 @@ static int __free_from_pool(void *start, size_t size)
> return 1;
> }
>
> -static void *__dma_alloc_coherent(struct device *dev, size_t size,
> - dma_addr_t *dma_handle, gfp_t flags,
> - unsigned long attrs)
> -{
> - if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
> - dev->coherent_dma_mask <= DMA_BIT_MASK(32))
> - flags |= GFP_DMA32;
> - if (dev_get_cma_area(dev) && gfpflags_allow_blocking(flags)) {
> - struct page *page;
> - void *addr;
> -
> - page = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
> - get_order(size), flags);
> - if (!page)
> - return NULL;
> -
> - *dma_handle = phys_to_dma(dev, page_to_phys(page));
> - addr = page_address(page);
> - memset(addr, 0, size);
> - return addr;
> - } else {
> - return swiotlb_alloc_coherent(dev, size, dma_handle, flags);
> - }
> -}
> -
> -static void __dma_free_coherent(struct device *dev, size_t size,
> - void *vaddr, dma_addr_t dma_handle,
> - unsigned long attrs)
> -{
> - bool freed;
> - phys_addr_t paddr = dma_to_phys(dev, dma_handle);
> -
> -
> - freed = dma_release_from_contiguous(dev,
> - phys_to_page(paddr),
> - size >> PAGE_SHIFT);
> - if (!freed)
> - swiotlb_free_coherent(dev, size, vaddr, dma_handle);
> -}
> -
> static void *__dma_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flags,
> unsigned long attrs)
> @@ -152,7 +112,7 @@ static void *__dma_alloc(struct device *dev, size_t size,
> return addr;
> }
>
> - ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs);
> + ptr = swiotlb_alloc(dev, size, dma_handle, flags, attrs);
> if (!ptr)
> goto no_mem;
>
> @@ -173,7 +133,7 @@ static void *__dma_alloc(struct device *dev, size_t size,
> return coherent_ptr;
>
> no_map:
> - __dma_free_coherent(dev, size, ptr, *dma_handle, attrs);
> + swiotlb_free(dev, size, ptr, *dma_handle, attrs);
> no_mem:
> return NULL;
> }
> @@ -191,7 +151,7 @@ static void __dma_free(struct device *dev, size_t size,
> return;
> vunmap(vaddr);
> }
> - __dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
> + swiotlb_free(dev, size, swiotlb_addr, dma_handle, attrs);
> }
>
> static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
>
^ 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