* [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
* [PATCH 1/3] gpiolib: Export gpiochip_irqchip_irq_valid() to drivers
From: Linus Walleij @ 2018-01-10 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110015848.11480-2-sboyd@codeaurora.org>
On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> Some pinctrl drivers can use the gpiochip irq valid information
> to figure out if certain gpios are exposed to the kernel for
> usage or not. Expose this API so we can use it in the
> pinmux_ops::request ops.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Makes a lot of sense.
Patch applied with Bj?rn's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [RESEND PATCH v9 00/13] Add STM32 DFSDM support
From: Arnaud Pouliquen @ 2018-01-10 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EDAAA911-C2FA-44B1-AAD6-22D7600CF6A5@jic23.retrosnub.co.uk>
On 01/10/2018 01:57 PM, Jonathan Cameron wrote:
>
>
> 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
>
Jonathan, Lars, Mark and Rob
Even if it is just the first step of the integration process, i would
like to take this opportunity to thank you for your help to integrate
the DFSDM drivers.
Probably not the most tricky one, but not the easiest either...
So thanks for your reviews, advices, solutions, and compromises.
Regards
Arnaud
>>
>>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 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Linus Walleij @ 2018-01-10 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110015848.11480-3-sboyd@codeaurora.org>
On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd <sboyd@codeaurora.org> 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.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
I like the idea, let's check what we think about the details regarding
naming and semantics, I need feedback from some DT people
in particular.
Paging in Grant on this as he might have some input.
> I stuck this inside msm8996, but maybe it can go somewhere more generic?
Yeah just put it in Documentation/devicetree/bindings/gpio/gpio.txt
Everyone and its dog doing GPIO reservations "from another world"
will need to use this.
> +- ngpios-ranges:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: Tuples of GPIO ranges (base, size) indicating
> + GPIOs available for use.
> +
> Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
> a general description of GPIO and interrupt bindings.
I like the tuples syntax. That's fine. It's like gpio-ranges we have
already to map between pin controllers and GPIO.
I don't think we can reuse gpio-ranges because that is
exclusively for pin control ATM, it would be fine if the ranges
were for a specific device, like pin control does, like:
gpio-ranges = <&secure_world_thing 0 20 10>;
But you definately would need a node to tie it to, so that the
driver for that node can specify that it's gonna take the
GPIOs.
But I think the semantics should be the inverse. That you
point out "holes" with the lines we *can't* use.
We already support a generic property "ngpios" that says how
many of the GPIOs (counted from zero) that can be used,
so if those should be able to use this as a generic property it
is better with the inverse semantics and say that the
"reserved-gpio-ranges", "secureworld-gpio-ranges"
(or whatever we decide to call it) takes precedence over
ngpios so we don't end up in ambigous places.
Then, will it be possible to put the parsing, handling and
disablement of these ranges into drivers/gpio/gpiolib-of.c
where we handle the ranges today, or do we need to
do it in the individual drivers?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] PCI: imx6: Add PHY reference clock source support
From: Ilya Ledvich @ 2018-01-10 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515408232.12538.7.camel@pengutronix.de>
Hi Lucas,
On 01/08/2018 12:43 PM, Lucas Stach wrote:
> Am Donnerstag, den 04.01.2018, 15:52 +0200 schrieb Ilya Ledvich:
>> i.MX7D variant of the IP can use either Crystal Oscillator input
>> or internal clock input as a Reference Clock input for PCIe PHY.
>> Add support for an optional property 'fsl,pcie-phy-refclk-internal'.
>> If present then an internal clock input is used as PCIe PHY
>> reference clock source. By default an external oscillator input
>> is still used.
>>
>> Verified on Compulab SBC-iMX7 Single Board Computer.
>
> Sorry to get in late here, but I would rather have the external clock
> input modeled as a real clock and only use the internal clock if that
> isn't present.
>
I tried to follow the logic described in the iMX7 TRM, where external
oscillator is a default option. Additionally, the external clock input
model you've suggested, requires additional changes in the iMX7 SabreSD
board (and probably other boards which use an external input too)
devicetree files.
> Are you even sure that the i.MX7 clock you mention isn't the already
> documented "pcie_bus" clock? This one is also allowed to be sourced
> externally on the i.MX6.
To the best of my understanding it's not the pcie_bus clock, but I'm
absolutely sure. Could anybody from the BSP team guys elaborate on this
issue? Thanks a lot!
Best regards,
Ilya.
>> ---
>> changes since V2:
>> add a vendor prefix 'fsl' to a new property
>>
>> ?Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +++++
>> ?drivers/pci/dwc/pci-imx6.c???????????????????????????????| 8
>> +++++++-
>> ?2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> index 7b1e48b..1591a6a 100644
>> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
>> @@ -50,6 +50,11 @@ Additional required properties for imx7d-pcie:
>> ? ???????- "pciephy"
>> ? ???????- "apps"
>>
>> +Additional optional properties for imx7d-pcie:
>> +- fsl,pcie-phy-refclk-internal: If present then an internal PLL
>> input is used
>> +??as PCIe PHY reference clock source. By default an external
>> oscillator input
>> +??is used.
>> +
>> ?Example:
>>
>> ? pcie at 0x01000000 {
>> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
>> index b734835..36812d3 100644
>> --- a/drivers/pci/dwc/pci-imx6.c
>> +++ b/drivers/pci/dwc/pci-imx6.c
>> @@ -61,6 +61,7 @@ struct imx6_pcie {
>> ? u32 tx_swing_low;
>> ? int link_gen;
>> ? struct regulator *vpcie;
>> + bool pciephy_refclk_sel;
>> ?};
>>
>> ?/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
>> @@ -474,7 +475,9 @@ static void imx6_pcie_init_phy(struct imx6_pcie
>> *imx6_pcie)
>> ? switch (imx6_pcie->variant) {
>> ? case IMX7D:
>> ? regmap_update_bits(imx6_pcie->iomuxc_gpr,
>> IOMUXC_GPR12,
>> - ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
>> 0);
>> + ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
>> + ???imx6_pcie->pciephy_refclk_sel ?
>> + ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL :
>> 0);
>> ? break;
>> ? case IMX6SX:
>> ? regmap_update_bits(imx6_pcie->iomuxc_gpr,
>> IOMUXC_GPR12,
>> @@ -840,6 +843,9 @@ static int imx6_pcie_probe(struct platform_device
>> *pdev)
>> ? imx6_pcie->vpcie = NULL;
>> ? }
>>
>> + imx6_pcie->pciephy_refclk_sel =
>> + of_property_read_bool(node, "fsl,pcie-phy-refclk-
>> internal");
>> +
>> ? platform_set_drvdata(pdev, imx6_pcie);
>>
>> ? ret = imx6_add_pcie_port(imx6_pcie, pdev);
^ permalink raw reply
* [RESEND PATCH] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.
From: Linus Walleij @ 2018-01-10 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109055902.GA1306@arx-s1>
On Tue, Jan 9, 2018 at 6:59 AM, hao_zhang <hao5781286@gmail.com> wrote:
> Pin function can not be match correctly when SUNXI_PIN describe with
> mutiple variant and same function.
>
> such as:
> on pinctrl-sun4i-a10.c
>
> SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> SUNXI_FUNCTION(0x0, "gpio_in"),
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION_VARIANT(0x2, "pwm", /* PWM0 */
> PINCTRL_SUN4I_A10 |
> PINCTRL_SUN7I_A20),
> SUNXI_FUNCTION_VARIANT(0x3, "pwm", /* PWM0 */
> PINCTRL_SUN8I_R40)),
>
> it would always match to the first variant function
> (PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)
>
> so we should add variant compare on it.
>
> Regards
> Hao
>
> Signed-off-by: hao_zhang <hao5781286@gmail.com>
Patch applied with Maxime's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/4 v6] drm/bridge: Add bindings for TI THS8134
From: Linus Walleij @ 2018-01-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
This adds device tree bindings for the Texas Instruments
THS8134, THS8134A and THS8134B VGA DACs by extending and
renaming the existing bindings for THS8135.
These DACs are used for the VGA outputs on the ARM reference
designs such as Integrator, Versatile and RealView.
Cc: devicetree at vger.kernel.org
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v5->v6:
- Fix the more-to-less specific compatible strings.
- Fix some speling.
- Collect Laurent's review tag.
ChangeLog v2->v5:
- Dropped the "ti,ths813x" as it turns out we need precise info
about the sub-variant anyways as they all very in timings.
- Refine the THS8134 variants, it turns out ths8134, ths8134a
and ths8134b are three different variants of ths8134.
ChangeLog v1->v2:
- Introduce specific-to-general compatible string:
compatible = "ti,ths8134a", "ti,ths813x";
so drivers can handle the whole family the same way.
- Collected Rob's ACK.
---
.../display/bridge/{ti,ths8135.txt => ti,ths813x.txt} | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt => ti,ths813x.txt} (69%)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
similarity index 69%
rename from Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
rename to Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
index 6ec1a880ac18..df3d7c1ac09e 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
@@ -1,11 +1,16 @@
-THS8135 Video DAC
------------------
+THS8134 and THS8135 Video DAC
+-----------------------------
-This is the binding for Texas Instruments THS8135 Video DAC bridge.
+This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and
+THS8135 Video DAC bridges.
Required properties:
-- compatible: Must be "ti,ths8135"
+- compatible: Must be one of
+ "ti,ths8134"
+ "ti,ths8134a," "ti,ths8134"
+ "ti,ths8134b", "ti,ths8134"
+ "ti,ths8135"
Required nodes:
--
2.14.3
^ permalink raw reply related
* [PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges
From: Linus Walleij @ 2018-01-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110141226.27826-1-linus.walleij@linaro.org>
After some discussion and failed patch sets trying to convey
the right timing information between the display engine and
a bridge using the connector, I try instead to use an optional
timing information container in the bridge itself, so that
display engines can retrieve it from any bridge and use it to
determine how to drive outputs.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v5->v6:
- Sort forward struct declarations alphabetically
- Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
positive or negatice clock samling edge
ChangeLog ->v5:
- New patch
---
include/drm/drm_bridge.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..28c9ac6d9036 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -29,6 +29,7 @@
#include <drm/drm_modes.h>
struct drm_bridge;
+struct drm_bridge_timings;
struct drm_panel;
/**
@@ -222,6 +223,23 @@ struct drm_bridge_funcs {
void (*enable)(struct drm_bridge *bridge);
};
+/**
+ * struct drm_bridge_timings - timing information for the bridge
+ * @sampling_edge: whether the bridge samples the digital input signal from the
+ * display engine on the positive or negative edge of the clock, this should
+ * reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise flags from the DRM
+ * connector (bit 2 and 3 valid)
+ * @setup_time_ps: the time in picoseconds the input data lines must be stable
+ * before the clock edge
+ * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
+ * input signal after the clock edge
+ */
+struct drm_bridge_timings {
+ u32 sampling_edge;
+ u32 setup_time_ps;
+ u32 hold_time_ps;
+};
+
/**
* struct drm_bridge - central DRM bridge control structure
* @dev: DRM device this bridge belongs to
@@ -229,6 +247,8 @@ struct drm_bridge_funcs {
* @next: the next bridge in the encoder chain
* @of_node: device node pointer to the bridge
* @list: to keep track of all added bridges
+ * @timings: the timing specification for the bridge, if any (may
+ * be NULL)
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
@@ -240,6 +260,7 @@ struct drm_bridge {
struct device_node *of_node;
#endif
struct list_head list;
+ const struct drm_bridge_timings *timings;
const struct drm_bridge_funcs *funcs;
void *driver_private;
--
2.14.3
^ permalink raw reply related
* [PATCH 3/4 v6] drm/bridge: Add timing support to dumb VGA DAC
From: Linus Walleij @ 2018-01-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110141226.27826-1-linus.walleij@linaro.org>
This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.
We assign the proper timing data to the pointer inside the
bridge struct so display controllers that need to align their
timings to the bridge can pick it up and work from there.
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v5->v6:
- Use DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
the sampling edge of the clock signal.
- Skip intermediate variable for timings.
- Leave timings as NULL for really dumb VGA DACs.
- Collect Laurent's Review tag.
ChangeLog v4->v5:
- Rewrite the support using the new concept of defining
fine-granular sampling (setup+hold) timing definitions
stored in the bridge timings struct.
ChangeLog v3->v4:
- Actually have the code syntactically correct and compiling :(
(Kconfig mistake.)
(...)
AS usr/initramfs_data.o
AR usr/built-in.o
CC drivers/gpu/drm/bridge/dumb-vga-dac.o
AR drivers/gpu/drm/bridge/built-in.o
AR drivers/gpu/drm/built-in.o
AR drivers/gpu/built-in.o
AR drivers/built-in.o
(...)
ChangeLog v2->v3:
- Move const specifier.
- Cut one line of code assigning bus flags.
- Preserve the "ti,ths8135" compatible for elder device trees.
ChangeLog v1->v2:
- Alphabetize includes
- Use a u32 with the bus polarity flags and just encode the
polarity using the DRM define directly.
- Rename vendor_data to vendor_info.
- Simplify assignment of the flag as it is just a simple
u32 now.
- Probe all TI variants on the "ti,ths813x" wildcard for now,
we only need to know that the device is in this family to
set the clock edge flag right.
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 59 +++++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index de5e7dee7ad6..498d5948d1a8 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -11,6 +11,7 @@
*/
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/regulator/consumer.h>
@@ -204,6 +205,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
vga->bridge.funcs = &dumb_vga_bridge_funcs;
vga->bridge.of_node = pdev->dev.of_node;
+ vga->bridge.timings = of_device_get_match_data(&pdev->dev);
drm_bridge_add(&vga->bridge);
@@ -222,10 +224,61 @@ static int dumb_vga_remove(struct platform_device *pdev)
return 0;
}
+/*
+ * We assume the ADV7123 DAC is the "default" for historical reasons
+ * Information taken from the ADV7123 datasheet, revision D.
+ * NOTE: the ADV7123EP seems to have other timings and need a new timings
+ * set if used.
+ */
+static const struct drm_bridge_timings default_dac_timings = {
+ /* Timing specifications, datasheet page 7 */
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .setup_time_ps = 500,
+ .hold_time_ps = 1500,
+};
+
+/*
+ * Information taken from the THS8134, THS8134A, THS8134B datasheet named
+ * "SLVS205D", dated May 1990, revised March 2000.
+ */
+static const struct drm_bridge_timings ti_ths8134_dac_timings = {
+ /* From timing diagram, datasheet page 9 */
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ /* From datasheet, page 12 */
+ .setup_time_ps = 3000,
+ /* I guess this means latched input */
+ .hold_time_ps = 0,
+};
+
+/*
+ * Information taken from the THS8135 datasheet named "SLAS343B", dated
+ * May 2001, revised April 2013.
+ */
+static const struct drm_bridge_timings ti_ths8135_dac_timings = {
+ /* From timing diagram, datasheet page 14 */
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ /* From datasheet, page 16 */
+ .setup_time_ps = 2000,
+ .hold_time_ps = 500,
+};
+
static const struct of_device_id dumb_vga_match[] = {
- { .compatible = "dumb-vga-dac" },
- { .compatible = "adi,adv7123" },
- { .compatible = "ti,ths8135" },
+ {
+ .compatible = "dumb-vga-dac",
+ .data = NULL,
+ },
+ {
+ .compatible = "adi,adv7123",
+ .data = &default_dac_timings,
+ },
+ {
+ .compatible = "ti,ths8135",
+ .data = &ti_ths8135_dac_timings,
+ },
+ {
+ .compatible = "ti,ths8134",
+ .data = &ti_ths8134_dac_timings,
+ },
{},
};
MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
2.14.3
^ permalink raw reply related
* [PATCH 4/4 v6] drm/pl111: Support handling bridge timings
From: Linus Walleij @ 2018-01-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110141226.27826-1-linus.walleij@linaro.org>
If the bridge has a too strict setup time for the incoming
signals, we may not be fast enough and then we need to
compensate by outputting the signal on the inverse clock
edge so it is for sure stable when the bridge samples it.
Since bridges in difference to panels does not expose their
connectors, make the connector optional in the display
setup code.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v5->v6:
- Collect Laurent's ACK.
ChangeLog v4->v5:
- Use the new bridge timings setup method.
---
drivers/gpu/drm/pl111/Kconfig | 1 +
drivers/gpu/drm/pl111/pl111_display.c | 35 +++++++++++++++++++++++++++++++----
drivers/gpu/drm/pl111/pl111_drv.c | 20 +++++++++++---------
3 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index e5e2abd66491..82cb3e60ddc8 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -8,6 +8,7 @@ config DRM_PL111
select DRM_GEM_CMA_HELPER
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
+ select DRM_DUMB_VGA_DAC
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
Choose this option for DRM support for the PL111 CLCD controller.
diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c
index 06c4bf756b69..7fe4040aea46 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -94,6 +94,7 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode = &cstate->mode;
struct drm_framebuffer *fb = plane->state->fb;
struct drm_connector *connector = priv->connector;
+ struct drm_bridge *bridge = priv->bridge;
u32 cntl;
u32 ppl, hsw, hfp, hbp;
u32 lpp, vsw, vfp, vbp;
@@ -143,11 +144,37 @@ static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
tim2 |= TIM2_IVS;
- if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
- tim2 |= TIM2_IOE;
+ if (connector) {
+ if (connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW)
+ tim2 |= TIM2_IOE;
- if (connector->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- tim2 |= TIM2_IPC;
+ if (connector->display_info.bus_flags &
+ DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+ tim2 |= TIM2_IPC;
+ }
+
+ if (bridge) {
+ const struct drm_bridge_timings *btimings = bridge->timings;
+
+ /*
+ * Here is when things get really fun. Sometimes the bridge
+ * timings are such that the signal out from PL11x is not
+ * stable before the receiving bridge (such as a dumb VGA DAC
+ * or similar) samples it. If that happens, we compensate by
+ * the only method we have: output the data on the opposite
+ * edge of the clock so it is for sure stable when it gets
+ * sampled.
+ *
+ * The PL111 manual does not contain proper timining diagrams
+ * or data for these details, but we know from experiments
+ * that the setup time is more than 3000 picoseconds (3 ns).
+ * If we have a bridge that requires the signal to be stable
+ * earlier than 3000 ps before the clock pulse, we have to
+ * output the data on the opposite edge to avoid flicker.
+ */
+ if (btimings && btimings->setup_time_ps >= 3000)
+ tim2 ^= TIM2_IPC;
+ }
tim2 |= cpl << 16;
writel(tim2, priv->regs + CLCD_TIM2);
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c
index 201d57d5cb54..101a9c7db6ff 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
ret = PTR_ERR(bridge);
goto out_config;
}
- /*
- * TODO: when we are using a different bridge than a panel
- * (such as a dumb VGA connector) we need to devise a different
- * method to get the connector out of the bridge.
- */
+ } else if (bridge) {
+ dev_info(dev->dev, "Using non-panel bridge\n");
+ } else {
+ dev_err(dev->dev, "No bridge, exiting\n");
+ return -ENODEV;
+ }
+
+ priv->bridge = bridge;
+ if (panel) {
+ priv->panel = panel;
+ priv->connector = panel->connector;
}
ret = pl111_display_init(dev);
@@ -125,10 +131,6 @@ static int pl111_modeset_init(struct drm_device *dev)
if (ret)
return ret;
- priv->bridge = bridge;
- priv->panel = panel;
- priv->connector = panel->connector;
-
ret = drm_vblank_init(dev, 1);
if (ret != 0) {
dev_err(dev->dev, "Failed to init vblank\n");
--
2.14.3
^ permalink raw reply related
* [PATCH 1/6] Documentation: crypto: document crypto engine API
From: Fabien DESSENNE @ 2018-01-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103201109.16077-2-clabbe.montjoie@gmail.com>
Hi Corentin,
Thank you for this new version which I have testes successfully with the
stm32 hash & cryp drivers.
As a general comment on this patchset, I would say that it does not
cover all async requests: typically I need (for the pending stm32 cryp
driver uprade) to use CryptoEngine to process AEAD requests which is not
covered here.
Could you please consider adding the 'transfer' and 'finalize' EXPORTed
functions for aead requests? (the implementation is quite trivial)
Have also a look at struct acomp_req (acompress.h) and struct
kpp_request (kpp.h) which also use "struct crypto_async_request base"
BR
Fabien
On 03/01/18 21:11, Corentin Labbe wrote:
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> Documentation/crypto/crypto_engine.rst | 46 ++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/crypto/crypto_engine.rst
>
> diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst
> new file mode 100644
> index 000000000000..b0ed37f9fb0c
> --- /dev/null
> +++ b/Documentation/crypto/crypto_engine.rst
> @@ -0,0 +1,46 @@
> +=============
> +CRYPTO ENGINE
> +=============
> +
> +Overview
> +--------
> +The crypto engine API (CE), is a crypto queue manager.
> +
> +Requirement
> +-----------
> +You have to put at start of your tfm_ctx the struct crypto_engine_reqctx
> +struct your_tfm_ctx {
> + struct crypto_engine_reqctx enginectx;
> + ...
> +};
> +Why: Since CE manage only crypto_async_request, it cannot know the underlying
> +request_type and so have access only on the TFM.
> +So using container_of for accessing __ctx is impossible.
> +Furthermore, the crypto engine cannot know the "struct your_tfm_ctx",
> +so it must assume that crypto_engine_reqctx is at start of it.
> +
> +Order of operations
> +-------------------
> +You have to obtain a struct crypto_engine via crypto_engine_alloc_init().
> +And start it via crypto_engine_start().
> +
> +Before transferring any request, you have to fill the enginectx.
> +- prepare_request: (taking a function pointer) If you need to do some processing before doing the request
> +- unprepare_request: (taking a function pointer) Undoing what's done in prepare_request
> +- do_one_request: (taking a function pointer) Do encryption for current request
> +
> +Note: that those three functions get the crypto_async_request associated with the received request.
> +So your need to get the original request via container_of(areq, struct yourrequesttype_request, base);
> +
> +When your driver receive a crypto_request, you have to transfer it to
> +the cryptoengine via one of:
> +- crypto_transfer_cipher_request_to_engine()
> +- crypto_transfer_skcipher_request_to_engine()
> +- crypto_transfer_akcipher_request_to_engine()
> +- crypto_transfer_hash_request_to_engine()
> +
> +At the end of the request process, a call to one of the following function is needed:
> +- crypto_finalize_cipher_request
> +- crypto_finalize_skcipher_request
> +- crypto_finalize_akcipher_request
> +- crypto_finalize_hash_request
^ permalink raw reply
* [PATCH -next] meson-mx-socinfo: Make local function meson_mx_socinfo_init() static
From: Wei Yongjun @ 2018-01-10 14:19 UTC (permalink / raw)
To: linux-arm-kernel
Fixes the following sparse warnings:
drivers/soc/amlogic/meson-mx-socinfo.c:107:12: warning:
symbol 'meson_mx_socinfo_init' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/soc/amlogic/meson-mx-socinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/amlogic/meson-mx-socinfo.c b/drivers/soc/amlogic/meson-mx-socinfo.c
index 7bfff5f..78f0f1a 100644
--- a/drivers/soc/amlogic/meson-mx-socinfo.c
+++ b/drivers/soc/amlogic/meson-mx-socinfo.c
@@ -104,7 +104,7 @@ static const char *meson_mx_socinfo_soc_id(unsigned int major_ver,
{ /* sentinel */ }
};
-int __init meson_mx_socinfo_init(void)
+static int __init meson_mx_socinfo_init(void)
{
struct soc_device_attribute *soc_dev_attr;
struct soc_device *soc_dev;
^ permalink raw reply related
* [PATCH -next] meson-gx-socinfo: make local function meson_gx_socinfo_init static
From: Wei Yongjun @ 2018-01-10 14:19 UTC (permalink / raw)
To: linux-arm-kernel
Fixes the following sparse warnings:
drivers/soc/amlogic/meson-gx-socinfo.c:100:12: warning:
symbol 'meson_gx_socinfo_init' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index f2d8c3c..ea091f1 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -97,7 +97,7 @@ static const char *socinfo_to_soc_id(u32 socinfo)
return "Unknown";
}
-int __init meson_gx_socinfo_init(void)
+static int __init meson_gx_socinfo_init(void)
{
struct soc_device_attribute *soc_dev_attr;
struct soc_device *soc_dev;
^ permalink raw reply related
* [PATCH 2/6] crypto: engine - Permit to enqueue all async requests
From: Fabien DESSENNE @ 2018-01-10 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103201109.16077-3-clabbe.montjoie@gmail.com>
On 03/01/18 21:11, Corentin Labbe wrote:
> The crypto engine could actually only enqueue hash and ablkcipher request.
> This patch permit it to enqueue any type of crypto_async_request.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> crypto/crypto_engine.c | 230 ++++++++++++++++++++++++------------------------
> include/crypto/engine.h | 59 +++++++------
> 2 files changed, 148 insertions(+), 141 deletions(-)
>
> diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
> index 61e7c4e02fd2..036270b61648 100644
> --- a/crypto/crypto_engine.c
> +++ b/crypto/crypto_engine.c
> @@ -15,7 +15,6 @@
> #include <linux/err.h>
> #include <linux/delay.h>
> #include <crypto/engine.h>
> -#include <crypto/internal/hash.h>
> #include <uapi/linux/sched/types.h>
> #include "internal.h"
>
> @@ -34,11 +33,10 @@ static void crypto_pump_requests(struct crypto_engine *engine,
> bool in_kthread)
> {
> struct crypto_async_request *async_req, *backlog;
> - struct ahash_request *hreq;
> - struct ablkcipher_request *breq;
> unsigned long flags;
> bool was_busy = false;
> - int ret, rtype;
> + int ret;
> + struct crypto_engine_reqctx *enginectx;
>
> spin_lock_irqsave(&engine->queue_lock, flags);
>
> @@ -94,7 +92,6 @@ static void crypto_pump_requests(struct crypto_engine *engine,
>
> spin_unlock_irqrestore(&engine->queue_lock, flags);
>
> - rtype = crypto_tfm_alg_type(engine->cur_req->tfm);
> /* Until here we get the request need to be encrypted successfully */
> if (!was_busy && engine->prepare_crypt_hardware) {
> ret = engine->prepare_crypt_hardware(engine);
> @@ -104,57 +101,31 @@ static void crypto_pump_requests(struct crypto_engine *engine,
> }
> }
>
> - switch (rtype) {
> - case CRYPTO_ALG_TYPE_AHASH:
> - hreq = ahash_request_cast(engine->cur_req);
> - if (engine->prepare_hash_request) {
> - ret = engine->prepare_hash_request(engine, hreq);
> - if (ret) {
> - dev_err(engine->dev, "failed to prepare request: %d\n",
> - ret);
> - goto req_err;
> - }
> - engine->cur_req_prepared = true;
> - }
> - ret = engine->hash_one_request(engine, hreq);
> - if (ret) {
> - dev_err(engine->dev, "failed to hash one request from queue\n");
> - goto req_err;
> - }
> - return;
> - case CRYPTO_ALG_TYPE_ABLKCIPHER:
> - breq = ablkcipher_request_cast(engine->cur_req);
> - if (engine->prepare_cipher_request) {
> - ret = engine->prepare_cipher_request(engine, breq);
> - if (ret) {
> - dev_err(engine->dev, "failed to prepare request: %d\n",
> - ret);
> - goto req_err;
> - }
> - engine->cur_req_prepared = true;
> - }
> - ret = engine->cipher_one_request(engine, breq);
> + enginectx = crypto_tfm_ctx(async_req->tfm);
> +
> + if (enginectx->op.prepare_request) {
> + ret = enginectx->op.prepare_request(engine, async_req);
> if (ret) {
> - dev_err(engine->dev, "failed to cipher one request from queue\n");
> + dev_err(engine->dev, "failed to prepare request: %d\n",
> + ret);
> goto req_err;
> }
> - return;
> - default:
> - dev_err(engine->dev, "failed to prepare request of unknown type\n");
> - return;
> + engine->cur_req_prepared = true;
> + }
> + if (!enginectx->op.do_one_request) {
> + dev_err(engine->dev, "failed to do request\n");
> + ret = -EINVAL;
> + goto req_err;
> + }
> + ret = enginectx->op.do_one_request(engine, async_req);
> + if (ret) {
> + dev_err(engine->dev, "Failed to do one request from queue: %d\n", ret);
> + goto req_err;
> }
> + return;
>
> req_err:
> - switch (rtype) {
> - case CRYPTO_ALG_TYPE_AHASH:
> - hreq = ahash_request_cast(engine->cur_req);
> - crypto_finalize_hash_request(engine, hreq, ret);
> - break;
> - case CRYPTO_ALG_TYPE_ABLKCIPHER:
> - breq = ablkcipher_request_cast(engine->cur_req);
> - crypto_finalize_cipher_request(engine, breq, ret);
> - break;
> - }
> + crypto_finalize_request(engine, async_req, ret);
> return;
>
> out:
> @@ -170,13 +141,12 @@ static void crypto_pump_work(struct kthread_work *work)
> }
>
> /**
> - * crypto_transfer_cipher_request - transfer the new request into the
> - * enginequeue
> + * crypto_transfer_request - transfer the new request into the engine queue
> * @engine: the hardware engine
> * @req: the request need to be listed into the engine queue
> */
> -int crypto_transfer_cipher_request(struct crypto_engine *engine,
> - struct ablkcipher_request *req,
> +static int crypto_transfer_request(struct crypto_engine *engine,
> + struct crypto_async_request *req,
> bool need_pump)
> {
> unsigned long flags;
> @@ -189,7 +159,7 @@ int crypto_transfer_cipher_request(struct crypto_engine *engine,
> return -ESHUTDOWN;
> }
>
> - ret = ablkcipher_enqueue_request(&engine->queue, req);
> + ret = crypto_enqueue_request(&engine->queue, req);
>
> if (!engine->busy && need_pump)
> kthread_queue_work(engine->kworker, &engine->pump_requests);
> @@ -197,85 +167,97 @@ int crypto_transfer_cipher_request(struct crypto_engine *engine,
> spin_unlock_irqrestore(&engine->queue_lock, flags);
> return ret;
> }
> -EXPORT_SYMBOL_GPL(crypto_transfer_cipher_request);
> +EXPORT_SYMBOL_GPL(crypto_transfer_request);
Do not export this function which is a static one.
>
> /**
> - * crypto_transfer_cipher_request_to_engine - transfer one request to list
> + * crypto_transfer_request_to_engine - transfer one request to list
> * into the engine queue
> * @engine: the hardware engine
> * @req: the request need to be listed into the engine queue
> */
> +static int crypto_transfer_request_to_engine(struct crypto_engine *engine,
> + struct crypto_async_request *req)
> +{
> + return crypto_transfer_request(engine, req, true);
> +}
> +
> +/**
> + * crypto_transfer_cipher_request_to_engine - transfer one ablkcipher_request
> + * to list into the engine queue
> + * @engine: the hardware engine
> + * @req: the request need to be listed into the engine queue
> + * TODO: Remove this function when skcipher conversion is finished
> + */
> int crypto_transfer_cipher_request_to_engine(struct crypto_engine *engine,
> struct ablkcipher_request *req)
> {
> - return crypto_transfer_cipher_request(engine, req, true);
> + return crypto_transfer_request_to_engine(engine, &req->base);
> }
> EXPORT_SYMBOL_GPL(crypto_transfer_cipher_request_to_engine);
>
> /**
> - * crypto_transfer_hash_request - transfer the new request into the
> - * enginequeue
> + * crypto_transfer_skcipher_request_to_engine - transfer one skcipher_request
> + * to list into the engine queue
> * @engine: the hardware engine
> * @req: the request need to be listed into the engine queue
> */
> -int crypto_transfer_hash_request(struct crypto_engine *engine,
> - struct ahash_request *req, bool need_pump)
> +int crypto_transfer_skcipher_request_to_engine(struct crypto_engine *engine,
> + struct skcipher_request *req)
> {
> - unsigned long flags;
> - int ret;
> -
> - spin_lock_irqsave(&engine->queue_lock, flags);
> -
> - if (!engine->running) {
> - spin_unlock_irqrestore(&engine->queue_lock, flags);
> - return -ESHUTDOWN;
> - }
> -
> - ret = ahash_enqueue_request(&engine->queue, req);
> -
> - if (!engine->busy && need_pump)
> - kthread_queue_work(engine->kworker, &engine->pump_requests);
> + return crypto_transfer_request_to_engine(engine, &req->base);
> +}
> +EXPORT_SYMBOL_GPL(crypto_transfer_skcipher_request_to_engine);
>
> - spin_unlock_irqrestore(&engine->queue_lock, flags);
> - return ret;
> +/**
> + * crypto_transfer_akcipher_request_to_engine - transfer one akcipher_request
> + * to list into the engine queue
> + * @engine: the hardware engine
> + * @req: the request need to be listed into the engine queue
> + */
> +int crypto_transfer_akcipher_request_to_engine(struct crypto_engine *engine,
> + struct akcipher_request *req)
> +{
> + return crypto_transfer_request_to_engine(engine, &req->base);
> }
> -EXPORT_SYMBOL_GPL(crypto_transfer_hash_request);
> +EXPORT_SYMBOL_GPL(crypto_transfer_akcipher_request_to_engine);
>
> /**
> - * crypto_transfer_hash_request_to_engine - transfer one request to list
> - * into the engine queue
> + * crypto_transfer_hash_request_to_engine - transfer one ahash_request
> + * to list into the engine queue
> * @engine: the hardware engine
> * @req: the request need to be listed into the engine queue
> */
> int crypto_transfer_hash_request_to_engine(struct crypto_engine *engine,
> struct ahash_request *req)
> {
> - return crypto_transfer_hash_request(engine, req, true);
> + return crypto_transfer_request_to_engine(engine, &req->base);
> }
> EXPORT_SYMBOL_GPL(crypto_transfer_hash_request_to_engine);
>
Please add this EXPORTed function:
crypto_transfer_aead_request_to_engine(struct crypto_engine *engine,
struct aead_request *req)
> /**
> - * crypto_finalize_cipher_request - finalize one request if the request is done
> + * crypto_finalize_request - finalize one request if the request is done
> * @engine: the hardware engine
> * @req: the request need to be finalized
> * @err: error number
> */
> -void crypto_finalize_cipher_request(struct crypto_engine *engine,
> - struct ablkcipher_request *req, int err)
> +void crypto_finalize_request(struct crypto_engine *engine,
shall be static
> + struct crypto_async_request *req, int err)
> {
> unsigned long flags;
> bool finalize_cur_req = false;
> int ret;
> + struct crypto_engine_reqctx *enginectx;
>
> spin_lock_irqsave(&engine->queue_lock, flags);
> - if (engine->cur_req == &req->base)
> + if (engine->cur_req == req)
> finalize_cur_req = true;
> spin_unlock_irqrestore(&engine->queue_lock, flags);
>
> if (finalize_cur_req) {
> + enginectx = crypto_tfm_ctx(req->tfm);
> if (engine->cur_req_prepared &&
> - engine->unprepare_cipher_request) {
> - ret = engine->unprepare_cipher_request(engine, req);
> + enginectx->op.unprepare_request) {
> + ret = enginectx->op.unprepare_request(engine, req);
> if (ret)
> dev_err(engine->dev, "failed to unprepare request\n");
> }
> @@ -285,46 +267,64 @@ void crypto_finalize_cipher_request(struct crypto_engine *engine,
> spin_unlock_irqrestore(&engine->queue_lock, flags);
> }
>
> - req->base.complete(&req->base, err);
> + req->complete(req, err);
>
> kthread_queue_work(engine->kworker, &engine->pump_requests);
> }
> -EXPORT_SYMBOL_GPL(crypto_finalize_cipher_request);
>
> /**
> - * crypto_finalize_hash_request - finalize one request if the request is done
> + * crypto_finalize_cipher_request - finalize one ablkcipher_request if
> + * the request is done
> * @engine: the hardware engine
> * @req: the request need to be finalized
> * @err: error number
> */
> -void crypto_finalize_hash_request(struct crypto_engine *engine,
> - struct ahash_request *req, int err)
> +void crypto_finalize_cipher_request(struct crypto_engine *engine,
> + struct ablkcipher_request *req, int err)
> {
> - unsigned long flags;
> - bool finalize_cur_req = false;
> - int ret;
> -
> - spin_lock_irqsave(&engine->queue_lock, flags);
> - if (engine->cur_req == &req->base)
> - finalize_cur_req = true;
> - spin_unlock_irqrestore(&engine->queue_lock, flags);
> + return crypto_finalize_request(engine, &req->base, err);
> +}
> +EXPORT_SYMBOL_GPL(crypto_finalize_cipher_request);
>
> - if (finalize_cur_req) {
> - if (engine->cur_req_prepared &&
> - engine->unprepare_hash_request) {
> - ret = engine->unprepare_hash_request(engine, req);
> - if (ret)
> - dev_err(engine->dev, "failed to unprepare request\n");
> - }
> - spin_lock_irqsave(&engine->queue_lock, flags);
> - engine->cur_req = NULL;
> - engine->cur_req_prepared = false;
> - spin_unlock_irqrestore(&engine->queue_lock, flags);
> - }
> +/**
> + * crypto_finalize_skcipher_request - finalize one skcipher_request if
> + * the request is done
> + * @engine: the hardware engine
> + * @req: the request need to be finalized
> + * @err: error number
> + */
> +void crypto_finalize_skcipher_request(struct crypto_engine *engine,
> + struct skcipher_request *req, int err)
> +{
> + return crypto_finalize_request(engine, &req->base, err);
> +}
> +EXPORT_SYMBOL_GPL(crypto_finalize_skcipher_request);
>
> - req->base.complete(&req->base, err);
> +/**
> + * crypto_finalize_akcipher_request - finalize one akcipher_request if
> + * the request is done
> + * @engine: the hardware engine
> + * @req: the request need to be finalized
> + * @err: error number
> + */
> +void crypto_finalize_akcipher_request(struct crypto_engine *engine,
> + struct akcipher_request *req, int err)
> +{
> + return crypto_finalize_request(engine, &req->base, err);
> +}
> +EXPORT_SYMBOL_GPL(crypto_finalize_akcipher_request);
>
> - kthread_queue_work(engine->kworker, &engine->pump_requests);
> +/**
> + * crypto_finalize_hash_request - finalize one ahash_request if
> + * the request is done
> + * @engine: the hardware engine
> + * @req: the request need to be finalized
> + * @err: error number
> + */
> +void crypto_finalize_hash_request(struct crypto_engine *engine,
> + struct ahash_request *req, int err)
> +{
> + return crypto_finalize_request(engine, &req->base, err);
> }
> EXPORT_SYMBOL_GPL(crypto_finalize_hash_request);
Add
crypto_finalize_aead_request(struct crypto_engine *engine, struct
aead_request *req, int err)
>
> diff --git a/include/crypto/engine.h b/include/crypto/engine.h
> index dd04c1699b51..1ea7cbe92eaf 100644
> --- a/include/crypto/engine.h
> +++ b/include/crypto/engine.h
> @@ -17,7 +17,9 @@
> #include <linux/kernel.h>
> #include <linux/kthread.h>
> #include <crypto/algapi.h>
> +#include <crypto/akcipher.h>
> #include <crypto/hash.h>
> +#include <crypto/skcipher.h>
>
> #define ENGINE_NAME_LEN 30
> /*
> @@ -37,12 +39,6 @@
> * @unprepare_crypt_hardware: there are currently no more requests on the
> * queue so the subsystem notifies the driver that it may relax the
> * hardware by issuing this call
> - * @prepare_cipher_request: do some prepare if need before handle the current request
> - * @unprepare_cipher_request: undo any work done by prepare_cipher_request()
> - * @cipher_one_request: do encryption for current request
> - * @prepare_hash_request: do some prepare if need before handle the current request
> - * @unprepare_hash_request: undo any work done by prepare_hash_request()
> - * @hash_one_request: do hash for current request
> * @kworker: kthread worker struct for request pump
> * @pump_requests: work struct for scheduling work to the request pump
> * @priv_data: the engine private data
> @@ -65,19 +61,6 @@ struct crypto_engine {
> int (*prepare_crypt_hardware)(struct crypto_engine *engine);
> int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
>
> - int (*prepare_cipher_request)(struct crypto_engine *engine,
> - struct ablkcipher_request *req);
> - int (*unprepare_cipher_request)(struct crypto_engine *engine,
> - struct ablkcipher_request *req);
> - int (*prepare_hash_request)(struct crypto_engine *engine,
> - struct ahash_request *req);
> - int (*unprepare_hash_request)(struct crypto_engine *engine,
> - struct ahash_request *req);
> - int (*cipher_one_request)(struct crypto_engine *engine,
> - struct ablkcipher_request *req);
> - int (*hash_one_request)(struct crypto_engine *engine,
> - struct ahash_request *req);
> -
> struct kthread_worker *kworker;
> struct kthread_work pump_requests;
>
> @@ -85,19 +68,43 @@ struct crypto_engine {
> struct crypto_async_request *cur_req;
> };
>
> -int crypto_transfer_cipher_request(struct crypto_engine *engine,
> - struct ablkcipher_request *req,
> - bool need_pump);
> +/*
> + * struct crypto_engine_op - crypto hardware engine operations
> + * @prepare__request: do some prepare if need before handle the current request
> + * @unprepare_request: undo any work done by prepare_request()
> + * @do_one_request: do encryption for current request
> + */
> +struct crypto_engine_op {
> + int (*prepare_request)(struct crypto_engine *engine,
> + void *areq);
> + int (*unprepare_request)(struct crypto_engine *engine,
> + void *areq);
> + int (*do_one_request)(struct crypto_engine *engine,
> + void *areq);
> +};
> +
> +struct crypto_engine_reqctx {
> + struct crypto_engine_op op;
> +};
> +
> +int crypto_transfer_akcipher_request_to_engine(struct crypto_engine *engine,
> + struct akcipher_request *req);
> int crypto_transfer_cipher_request_to_engine(struct crypto_engine *engine,
> - struct ablkcipher_request *req);
> -int crypto_transfer_hash_request(struct crypto_engine *engine,
> - struct ahash_request *req, bool need_pump);
> + struct ablkcipher_request *req);
> int crypto_transfer_hash_request_to_engine(struct crypto_engine *engine,
> - struct ahash_request *req);
> + struct ahash_request *req);
> +int crypto_transfer_skcipher_request_to_engine(struct crypto_engine *engine,
> + struct skcipher_request *req);
+ transfer_aead
> +void crypto_finalize_request(struct crypto_engine *engine,
> + struct crypto_async_request *req, int err);
static (+move to? .c file?)
> +void crypto_finalize_akcipher_request(struct crypto_engine *engine,
> + struct akcipher_request *req, int err);
> void crypto_finalize_cipher_request(struct crypto_engine *engine,
> struct ablkcipher_request *req, int err);
> void crypto_finalize_hash_request(struct crypto_engine *engine,
> struct ahash_request *req, int err);
> +void crypto_finalize_skcipher_request(struct crypto_engine *engine,
> + struct skcipher_request *req, int err);
+ finalize_aead
> int crypto_engine_start(struct crypto_engine *engine);
> int crypto_engine_stop(struct crypto_engine *engine);
> struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
^ permalink raw reply
* [PATCH -next] clocksource/drivers/stm32: fix error return code in stm32_timer_init()
From: Wei Yongjun @ 2018-01-10 14:23 UTC (permalink / raw)
To: linux-arm-kernel
Fix to return error code -ENOMEM from the kzalloc error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/clocksource/timer-stm32.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index e5cdc3a..2717f88 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -304,8 +304,10 @@ static int __init stm32_timer_init(struct device_node *node)
to->private_data = kzalloc(sizeof(struct stm32_timer_private),
GFP_KERNEL);
- if (!to->private_data)
+ if (!to->private_data) {
+ ret = -ENOMEM;
goto deinit;
+ }
rstc = of_reset_control_get(node, NULL);
if (!IS_ERR(rstc)) {
^ permalink raw reply related
* [PATCH 5/6] crypto: stm32-hash: convert to the new crypto engine API
From: Fabien DESSENNE @ 2018-01-10 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103201109.16077-6-clabbe.montjoie@gmail.com>
On 03/01/18 21:11, Corentin Labbe wrote:
> This patch convert the stm32-hash driver to the new crypto engine API.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> drivers/crypto/stm32/stm32-hash.c | 18 +++++++++++++-----
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/stm32/stm32-hash.c b/drivers/crypto/stm32/stm32-hash.c
> index 4ca4a264a833..9790c2c936c7 100644
> --- a/drivers/crypto/stm32/stm32-hash.c
> +++ b/drivers/crypto/stm32/stm32-hash.c
> @@ -122,6 +122,7 @@ enum stm32_hash_data_format {
> #define HASH_DMA_THRESHOLD 50
>
> struct stm32_hash_ctx {
> + struct crypto_engine_reqctx enginectx;
> struct stm32_hash_dev *hdev;
> unsigned long flags;
>
> @@ -828,6 +829,11 @@ static int stm32_hash_hw_init(struct stm32_hash_dev *hdev,
> return 0;
> }
>
> +static int stm32_hash_one_request(struct crypto_engine *engine,
> + void *areq);
merge these two lines in a single one
> +static int stm32_hash_prepare_req(struct crypto_engine *engine,
> + void *areq);
merge these two lines in a single one
> +
> static int stm32_hash_handle_queue(struct stm32_hash_dev *hdev,
> struct ahash_request *req)
> {
> @@ -835,8 +841,9 @@ static int stm32_hash_handle_queue(struct stm32_hash_dev *hdev,
> }
>
> static int stm32_hash_prepare_req(struct crypto_engine *engine,
> - struct ahash_request *req)
> + void *areq)
merge these two lines in a single one
> {
> + struct ahash_request *req = container_of(areq, struct ahash_request, base);
> 80 characters (CHECKPATCH)
> struct stm32_hash_ctx *ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(req));
> struct stm32_hash_dev *hdev = stm32_hash_find_dev(ctx);
> struct stm32_hash_request_ctx *rctx;
> @@ -855,8 +862,9 @@ static int stm32_hash_prepare_req(struct crypto_engine *engine,
> }
>
> static int stm32_hash_one_request(struct crypto_engine *engine,
> - struct ahash_request *req)
> + void *areq)
merge these two lines in a single one
> {
> + struct ahash_request *req = container_of(areq, struct ahash_request, base);
> 80 characters (CHECKPATCH)
> struct stm32_hash_ctx *ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(req));
> struct stm32_hash_dev *hdev = stm32_hash_find_dev(ctx);
> struct stm32_hash_request_ctx *rctx;
> @@ -1033,6 +1041,9 @@ static int stm32_hash_cra_init_algs(struct crypto_tfm *tfm,
> if (algs_hmac_name)
> ctx->flags |= HASH_FLAGS_HMAC;
>
> + ctx->enginectx.op.do_one_request = stm32_hash_one_request;
> + ctx->enginectx.op.prepare_request = stm32_hash_prepare_req;
> + ctx->enginectx.op.unprepare_request = NULL;
> return 0;
> }
>
> @@ -1493,9 +1504,6 @@ static int stm32_hash_probe(struct platform_device *pdev)
> goto err_engine;
> }
>
> - hdev->engine->prepare_hash_request = stm32_hash_prepare_req;
> - hdev->engine->hash_one_request = stm32_hash_one_request;
> -
> ret = crypto_engine_start(hdev->engine);
> if (ret)
> goto err_engine_start;
^ 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