Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [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

* [PATCH 6/6] crypto: stm32-cryp: convert to the new crypto engine API
From: Fabien DESSENNE @ 2018-01-10 14:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103201109.16077-7-clabbe.montjoie@gmail.com>



On 03/01/18 21:11, Corentin Labbe wrote:
> This patch convert the stm32-cryp driver to the new crypto engine API.
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
>   drivers/crypto/stm32/stm32-cryp.c | 21 ++++++++++++++++-----
>   1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
> index cf1dddbeaa2c..99e0473ef247 100644
> --- a/drivers/crypto/stm32/stm32-cryp.c
> +++ b/drivers/crypto/stm32/stm32-cryp.c
> @@ -91,6 +91,7 @@
>   #define _walked_out             (cryp->out_walk.offset - cryp->out_sg->offset)
>   
>   struct stm32_cryp_ctx {
> +	struct crypto_engine_reqctx enginectx;
>   	struct stm32_cryp       *cryp;
>   	int                     keylen;
>   	u32                     key[AES_KEYSIZE_256 / sizeof(u32)];
> @@ -494,10 +495,20 @@ static int stm32_cryp_cpu_start(struct stm32_cryp *cryp)
>   	return 0;
>   }
>   
> +static int stm32_cryp_cipher_one_req(struct crypto_engine *engine,
> +				     void *areq);

Merge these 2 lines in a single one

> +static int stm32_cryp_prepare_cipher_req(struct crypto_engine *engine,
> +					 void *areq);
> +
>   static int stm32_cryp_cra_init(struct crypto_tfm *tfm)
>   {
> +	struct stm32_cryp_ctx *ctx = crypto_tfm_ctx(tfm);
> +
>   	tfm->crt_ablkcipher.reqsize = sizeof(struct stm32_cryp_reqctx);
>   
> +	ctx->enginectx.op.do_one_request = stm32_cryp_cipher_one_req;
> +	ctx->enginectx.op.prepare_request = stm32_cryp_prepare_cipher_req;
> +	ctx->enginectx.op.unprepare_request = NULL;
>   	return 0;
>   }
>   
> @@ -695,14 +706,17 @@ static int stm32_cryp_prepare_req(struct crypto_engine *engine,
>   }
>   
>   static int stm32_cryp_prepare_cipher_req(struct crypto_engine *engine,
> -					 struct ablkcipher_request *req)
> +					 void *areq)
>   {
> +	struct ablkcipher_request *req = container_of(areq, struct ablkcipher_request, base);

 > 80 characters (CHECKPATCH)

> +
>   	return stm32_cryp_prepare_req(engine, req);
>   }
>   
>   static int stm32_cryp_cipher_one_req(struct crypto_engine *engine,
> -				     struct ablkcipher_request *req)
> +				     void *areq)

Merge these 2 lines in a single one

>   {
> +	struct ablkcipher_request *req = container_of(areq, struct ablkcipher_request, base);

 > 80 characters (CHECKPATCH)

>   	struct stm32_cryp_ctx *ctx = crypto_ablkcipher_ctx(
>   			crypto_ablkcipher_reqtfm(req));
>   	struct stm32_cryp *cryp = ctx->cryp;
> @@ -1104,9 +1118,6 @@ static int stm32_cryp_probe(struct platform_device *pdev)
>   		goto err_engine1;
>   	}
>   
> -	cryp->engine->prepare_cipher_request = stm32_cryp_prepare_cipher_req;
> -	cryp->engine->cipher_one_request = stm32_cryp_cipher_one_req;
> -
>   	ret = crypto_engine_start(cryp->engine);
>   	if (ret) {
>   		dev_err(dev, "Could not start crypto engine\n");

^ permalink raw reply

* [PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges
From: Daniel Vetter @ 2018-01-10 14:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180110141226.27826-2-linus.walleij@linaro.org>

On Wed, Jan 10, 2018 at 03:12:24PM +0100, Linus Walleij wrote:
> 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
> + */

Just a style nit: for longer kerneldoc comments for struct members the
in-line style, split up for each member, is imo better.
-Daniel

> +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
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply

* [PATCH 2/2] cpufreq: scpi: remove arm_big_little dependency
From: Viresh Kumar @ 2018-01-10 14:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515516568-31359-3-git-send-email-sudeep.holla@arm.com>

On 09-01-18, 16:49, Sudeep Holla wrote:
> The dependency on physical_package_id from the topology to get the
> cluster identifier is wrong. The concept of cluster used in ARM topology
> is unfortunately not well defined in the architecture, we should avoid
> using it. Further the frequency domain need not be mapped to so called
> "clusters" one to one.
> 
> SCPI already provides means to obtain the frequency domain id from the
> device tree. In order to support some new topologies(e.g. DSU which
> contains 2 frequency domains within the physical cluster), pseudo
> clusters are created to make this driver work which is wrong again.
> 
> In order to solve those issues and also remove dependency of topological
> physical id for frequency domain, this patch removes the arm_big_little
> dependency from scpi driver.
> 
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/cpufreq/scpi-cpufreq.c | 193 +++++++++++++++++++++++++++++++++++++----
>  1 file changed, 178 insertions(+), 15 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply

* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Robin Murphy @ 2018-01-10 14:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180110080027.13879-12-hch@lst.de>

On 10/01/18 08:00, Christoph Hellwig wrote:
> phys_to_dma, dma_to_phys and dma_capable are helpers published by
> architecture code for use of swiotlb and xen-swiotlb only.  Drivers are
> not supposed to use these directly, but use the DMA API instead.
> 
> Move these to a new asm/dma-direct.h helper, included by a
> linux/dma-direct.h wrapper that provides the default linear mapping
> unless the architecture wants to override it.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
[...]
>   drivers/crypto/marvell/cesa.c                      |  1 +
>   drivers/mtd/nand/qcom_nandc.c                      |  1 +

I took a look at these, and it seems their phys_to_dma() usage is doing 
the thing which we subsequently formalised as dma_map_resource(). I've 
had a crack at a quick patch to update the CESA driver; qcom_nandc looks 
slightly more complex in that the changes probably need to span the BAM 
dmaengine driver as well.

In the process, though, I stumbled across gen_pool_dma_alloc() - yuck, 
something needs doing there, for sure...

Robin.

^ permalink raw reply

* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Robin Murphy @ 2018-01-10 15:15 UTC (permalink / raw)
  To: linux-arm-kernel

phys_to_dma() is an internal helper for certain DMA API implementations,
and is not appropriate for drivers to use. It appears that what the CESA
driver really wants to be using is dma_map_resource() - admittedly that
didn't exist when the offending code was first merged, but it does now.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

Found by inspection and compile-tested only

 drivers/crypto/marvell/cesa.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 293832488cc9..f81fa4a3e66b 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -15,6 +15,7 @@
  */
 
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/genalloc.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
@@ -409,8 +410,11 @@ static int mv_cesa_get_sram(struct platform_device *pdev, int idx)
 	if (IS_ERR(engine->sram))
 		return PTR_ERR(engine->sram);
 
-	engine->sram_dma = phys_to_dma(cesa->dev,
-				       (phys_addr_t)res->start);
+	engine->sram_dma = dma_map_resource(cesa->dev, res->start,
+					    cesa->sram_size,
+					    DMA_BIDIRECTIONAL, 0);
+	if (dma_mapping_error(cesa->dev, engine->sram_dma))
+		return -ENOMEM;
 
 	return 0;
 }
@@ -420,11 +424,12 @@ static void mv_cesa_put_sram(struct platform_device *pdev, int idx)
 	struct mv_cesa_dev *cesa = platform_get_drvdata(pdev);
 	struct mv_cesa_engine *engine = &cesa->engines[idx];
 
-	if (!engine->pool)
-		return;
-
-	gen_pool_free(engine->pool, (unsigned long)engine->sram,
-		      cesa->sram_size);
+	if (engine->pool)
+		gen_pool_free(engine->pool, (unsigned long)engine->sram,
+			      cesa->sram_size);
+	else
+		dma_unmap_resource(cesa->dev, engine->sram_dma,
+				   cesa->sram_size, DMA_BIDIRECTIONAL, 0);
 }
 
 static int mv_cesa_probe(struct platform_device *pdev)
-- 
2.13.4.dirty

^ permalink raw reply related

* [PATCH] pwn: stm32: Adopt SPDX identifier
From: Benjamin Gaignard @ 2018-01-10 15:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOFm3uFYjUvnwb2zqdJEuHp4WEnfmxrcZxRta2Cnfz3Q1=55rw@mail.gmail.com>

2017-12-07 11:11 GMT+01:00 Philippe Ombredanne <pombredanne@nexb.com>:
> On Tue, Dec 5, 2017 at 3:57 PM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> Add SPDX identifer
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>>  drivers/pwm/pwm-stm32-lp.c | 3 +--
>>  drivers/pwm/pwm-stm32.c    | 3 +--
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
>> index 1ac9e4384142..cbd271e80c3c 100644
>> --- a/drivers/pwm/pwm-stm32-lp.c
>> +++ b/drivers/pwm/pwm-stm32-lp.c
>> @@ -1,3 +1,4 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>  /*
>>   * STM32 Low-Power Timer PWM driver
>>   *
>> @@ -5,8 +6,6 @@
>>   *
>>   * Author: Gerald Baeza <gerald.baeza@st.com>
>>   *
>> - * License terms: GNU General Public License (GPL), version 2
>> - *
>>   * Inspired by Gerald Baeza's pwm-stm32 driver
>>   */
>>
>> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
>> index 6139512aab7b..be56d7af89c9 100644
>> --- a/drivers/pwm/pwm-stm32.c
>> +++ b/drivers/pwm/pwm-stm32.c
>> @@ -1,10 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>>  /*
>>   * Copyright (C) STMicroelectronics 2016
>>   *
>>   * Author: Gerald Baeza <gerald.baeza@st.com>
>>   *
>> - * License terms: GNU General Public License (GPL), version 2
>> - *
>>   * Inspired by timer-stm32.c from Maxime Coquelin
>>   *             pwm-atmel.c from Bo Shen
>>   */
>> --
>> 2.15.0
>>
>
>
> Thank you for using the simpler SPDX license ids!
>
> Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
>

Gentle ping on this patch before the merge window

> --
> Cordially
> Philippe Ombredanne

^ permalink raw reply

* [PATCH] ARM: socfpga: Configure l2c_aux_val
From: Dinh Nguyen @ 2018-01-10 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515518735-10906-1-git-send-email-thor.thayer@linux.intel.com>



On 01/09/2018 11:25 AM, thor.thayer at linux.intel.com wrote:
> From: Thor Thayer <thor.thayer@linux.intel.com>
> 
> Depending on the execution path, the A10 boot ROM/U-Boot may or
> may not set some bits in the l2c aux ctrl register.  Due to this
> abiguity, linux must explicitly set the register.  This patch
> forces the configuration to match the full boot flow, which
> also matches the setting used in the 3.10-ltsi version of the
> kernel.
> 
> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
> ---
>  arch/arm/mach-socfpga/socfpga.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index dde14f7bf2c3..37d28794f7d4 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -121,7 +121,10 @@ static const char *altera_a10_dt_match[] = {
>  };
>  
>  DT_MACHINE_START(SOCFPGA_A10, "Altera SOCFPGA Arria10")
> -	.l2c_aux_val	= 0,
> +	.l2c_aux_val	= L2C_AUX_CTRL_EVTMON_ENABLE |
> +			  L2C_AUX_CTRL_SHARED_OVERRIDE |
> +			  L310_AUX_CTRL_INSTR_PREFETCH |
> +			  L310_AUX_CTRL_DATA_PREFETCH,

The override bit already getting set in socfpga_arria10.dtsi. If you
want the data/instr prefetch bits, then please add them to the dtsi.

Thanks,
Dinh

^ permalink raw reply

* [PATCH 11/33] dma-mapping: move swiotlb arch helpers to a new header
From: Christoph Hellwig @ 2018-01-10 15:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <b2bd6f4b-a932-5251-517b-83bbccfe7c53@arm.com>

On Wed, Jan 10, 2018 at 09:31:45AM +0000, Vladimir Murzin wrote:
> I know it is copy&paste, but it seems it has off by one error and it should be
> 
> return addr + size - 1 <= *dev->dma_mask;

I've added a new patch to fix the mips dma_capable() definition,
thanks.

^ permalink raw reply

* [asoc:topic/iio 9/11] drivers/iio/adc/stm32-dfsdm-adc.c:241:6: sparse: symbol 'stm32_dfsdm_stop_filter' was not declared. Should it be static?
From: kbuild test robot @ 2018-01-10 15:23 UTC (permalink / raw)
  To: linux-arm-kernel

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/iio
head:   16cbca06fa8288a4f58426fc898b141e12ee8008
commit: e2e6771c646251657fafb2a78db566d5c2c70635 [9/11] IIO: ADC: add STM32 DFSDM sigma delta ADC support
reproduce:
        # apt-get install sparse
        git checkout e2e6771c646251657fafb2a78db566d5c2c70635
        make ARCH=x86_64 allmodconfig
        make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/iio/adc/stm32-dfsdm-adc.c:241:6: sparse: symbol 'stm32_dfsdm_stop_filter' was not declared. Should it be
>> drivers/iio/adc/stm32-dfsdm-adc.c:283:5: sparse: symbol 'stm32_dfsdm_channel_parse_of' was not declared. Should it be

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox