* [PATCH] PCI: Remove unused includes and superfluous struct declaration
From: Krzysztof Wilczynski @ 2019-09-01 11:25 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: devicetree, Lorenzo Pieralisi, Jingoo Han, Joerg Roedel,
linux-pci, linux-kernel, iommu, Rob Herring, Thomas Petazzoni,
Gustavo Pimentel, Frank Rowand, linux-arm-kernel
Remove <linux/pci.h> and <linux/msi.h> from being included
directly as part of the include/linux/of_pci.h, and remove
superfluous declaration of struct of_phandle_args.
Move users of include <linux/of_pci.h> to include <linux/pci.h>
and <linux/msi.h> directly rather than rely on both being
included transitively through <linux/of_pci.h>.
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
---
drivers/iommu/of_iommu.c | 2 ++
drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
drivers/pci/controller/pci-aardvark.c | 1 +
drivers/pci/pci.c | 1 +
drivers/pci/probe.c | 1 +
include/linux/of_pci.h | 4 +---
6 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 614a93aa5305..026ad2b29dcd 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -8,6 +8,8 @@
#include <linux/export.h>
#include <linux/iommu.h>
#include <linux/limits.h>
+#include <linux/pci.h>
+#include <linux/msi.h>
#include <linux/of.h>
#include <linux/of_iommu.h>
#include <linux/of_pci.h>
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index d3156446ff27..7a9bef993e57 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -10,6 +10,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
+#include <linux/msi.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
#include <linux/pci_regs.h>
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fc0fe4d4de49..3a05f6ca95b0 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -16,6 +16,7 @@
#include <linux/pci.h>
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/msi.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 484e35349565..571e7e00984b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -13,6 +13,7 @@
#include <linux/delay.h>
#include <linux/dmi.h>
#include <linux/init.h>
+#include <linux/msi.h>
#include <linux/of.h>
#include <linux/of_pci.h>
#include <linux/pci.h>
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 169943f17a4c..11b11a652d18 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -7,6 +7,7 @@
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/pci.h>
+#include <linux/msi.h>
#include <linux/of_device.h>
#include <linux/of_pci.h>
#include <linux/pci_hotplug.h>
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 21a89c4880fa..7929b4c0e886 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -2,11 +2,9 @@
#ifndef __OF_PCI_H
#define __OF_PCI_H
-#include <linux/pci.h>
-#include <linux/msi.h>
+#include <linux/types.h>
struct pci_dev;
-struct of_phandle_args;
struct device_node;
#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_PCI)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] iio: adc: meson_saradc: Fix memory allocation order
From: Martin Blumenstingl @ 2019-09-01 11:29 UTC (permalink / raw)
To: Remi Pommarel
Cc: Lars-Peter Clausen, Neil Armstrong, linux-iio, Kevin Hilman,
linux-kernel, Elie Roudninski, linux-arm-kernel,
Peter Meerwald-Stadler, Hartmut Knaack, linux-amlogic,
Jonathan Cameron
In-Reply-To: <20190901105410.23567-1-repk@triplefau.lt>
On Sun, Sep 1, 2019 at 12:45 PM Remi Pommarel <repk@triplefau.lt> wrote:
>
> meson_saradc's irq handler uses priv->regmap so make sure that it is
> allocated before the irq get enabled.
>
> This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device
> managed resources are freed in the inverted order they had been
> allocated, priv->regmap was freed before the spurious fake irq that
> CONFIG_DEBUG_SHIRQ adds called the handler.
>
Fixes: 3af109131b7eb8 ("iio: adc: meson-saradc: switch from polling to
interrupt mode")
> Reported-by: Elie Roudninski <xademax@gmail.com>
> Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
thank you for fixing this!
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
From: Martin Blumenstingl @ 2019-09-01 11:37 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Neil Armstrong, Kevin Hilman, linux-kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190828202723.1145-2-linux.amoon@gmail.com>
On Wed, Aug 28, 2019 at 10:27 PM Anand Moon <linux.amoon@gmail.com> wrote:
>
> As per shematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
typo: "schematics"
> fixed regulator output which is supplied by P5V0.
>
> Rename vcc3v3 regulator node to vddio_ao3v3 as per shematics.
typo: "schematics"
according to the schematics there's both:
- VDDIO_AO3V3
- VCC3V3 (which is turned on by VDDIO_AO3V3, see [0])
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 +++++++++++++++++--
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 792698a60a12..98e742bf44c1 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -104,11 +104,34 @@
> regulator-max-microvolt = <1800000>;
> };
>
> - vcc3v3: regulator-vcc3v3 {
> + vddio_ao1v8: regulator-vddio-ao1v8 {
> compatible = "regulator-fixed";
> - regulator-name = "VCC3V3";
> + regulator-name = "VDDIO_AO1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + /* U17 RT9179GB */
> + vin-supply = <&p5v0>;
> + };
> +
> + vddio_ao3v3: regulator-vddio-ao3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_AO3V3";
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + /* U11 MP2161GJ-C499 */
> + vin-supply = <&p5v0>;
> + };
> +
> + vddc_ddr: regulator-vddc-ddr {
> + compatible = "regulator-fixed";
> + regulator-name = "DDR_VDDC";
personally I would call this (along with the node name and alias) DDR3_1V5
odroid-c2_rev0.1_20150930.pdf shows that DDR3_1V5 and DDR_VDDC are
both the same. however, the DDR_VDDC signal name is not used by any
component in the datasheet
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-always-on;
> + /* U15 MP2161GJ-C499 */
> + vin-supply = <&p5v0>;
> };
>
> emmc_pwrseq: emmc-pwrseq {
> @@ -301,7 +324,7 @@
> mmc-hs200-1_8v;
>
> mmc-pwrseq = <&emmc_pwrseq>;
> - vmmc-supply = <&vcc3v3>;
> + vmmc-supply = <&vddio_ao3v3>;
odroid-c2_rev0.1_20150930.pdf uses VCC3V3 as supply
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
From: Martin Blumenstingl @ 2019-09-01 11:41 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Neil Armstrong, Kevin Hilman, linux-kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190828202723.1145-3-linux.amoon@gmail.com>
On Wed, Aug 28, 2019 at 10:27 PM Anand Moon <linux.amoon@gmail.com> wrote:
>
> As per shematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
typo: "schematics"
> is supplied by VDDIO_AO3V3.
please add a short sentence to the description (since you probably
have to re-send a v2) like:
"While here, move the comment name with the signal name in the
schematics above the gpio property to make it consistent with other
regulators"
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
with the patch rebased (see below) and the two issues from above addressed:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 98e742bf44c1..a078a1ee5004 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -67,17 +67,19 @@
> };
>
> tflash_vdd: regulator-tflash_vdd {
> - /*
> - * signal name from schematics: TFLASH_VDD_EN
> - */
> compatible = "regulator-fixed";
>
> regulator-name = "TFLASH_VDD";
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
>
> + /*
> + * signal name from schematics: TFLASH_VDD_EN
> + */
> gpio = <&gpio GPIOY_12 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> + /* U16 RT9179GB */
> + vin-supply = <&vddio_ao3v3>;
> };
>
> tf_io: gpio-regulator-tf_io {
> @@ -95,6 +97,8 @@
>
> states = <3300000 0
> 1800000 1>;
> + /* U12/U13 RT9179GB */
> + vin-supply = <&vddio_ao3v3>;
> };
thank you for the patch but I think it won't apply on top of Neil's
"arm64: dts: meson: fix boards regulators states format" (which was
applied just after you sent this series)
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
From: Martin Blumenstingl @ 2019-09-01 11:44 UTC (permalink / raw)
To: Anand Moon
Cc: devicetree, Neil Armstrong, Kevin Hilman, linux-kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190828202723.1145-4-linux.amoon@gmail.com>
Hi Anand,
On Wed, Aug 28, 2019 at 10:27 PM Anand Moon <linux.amoon@gmail.com> wrote:
>
> As per shematics HDMI_P5V0 is supplied by P5V0 so add missing link.
typo: "schematics"
> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Cc: Jerome Brunet <jbrunet@baylibre.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index a078a1ee5004..47789fd50415 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -213,6 +213,8 @@
> status = "okay";
> pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> pinctrl-names = "default";
> + /* AP2331SA-7 */
> + hdmi-supply = <&p5v0>;
> };
my understanding based on odroid-c2_rev0.1_20150930.pdf is that:
- there's a (fixed) hdmi_p5v0 regulator using p5v0 as input
- the hdmi_p5v0 is the hdmi-supply
it doesn't change the functionality of this patch (since both supplies
are fixed regulators anyways)
you are already doing a nice cleanup with this series, so it would be
a shame to take a shortcut here
Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 2/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to VDDIO_AO3V3 regulator
From: Anand Moon @ 2019-09-01 13:56 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Neil Armstrong, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CAFBinCBA-sQcshd9iAVn=ZDBKkDN3OgJs-WjKEhVLw===b0AdQ@mail.gmail.com>
Hi Martin,
Thanks of your review comments.
On Sun, 1 Sep 2019 at 17:11, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> On Wed, Aug 28, 2019 at 10:27 PM Anand Moon <linux.amoon@gmail.com> wrote:
> >
> > As per shematics TFLASH_VDD, TF_IO, VCC3V3 fixed regulator output which
> typo: "schematics"
>
Ok
> > is supplied by VDDIO_AO3V3.
> please add a short sentence to the description (since you probably
> have to re-send a v2) like:
> "While here, move the comment name with the signal name in the
> schematics above the gpio property to make it consistent with other
> regulators"
>
Ok I will append this in next version.
> > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Cc: Jerome Brunet <jbrunet@baylibre.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> with the patch rebased (see below) and the two issues from above addressed:
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index 98e742bf44c1..a078a1ee5004 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -67,17 +67,19 @@
> > };
> >
> > tflash_vdd: regulator-tflash_vdd {
> > - /*
> > - * signal name from schematics: TFLASH_VDD_EN
> > - */
> > compatible = "regulator-fixed";
> >
> > regulator-name = "TFLASH_VDD";
> > regulator-min-microvolt = <3300000>;
> > regulator-max-microvolt = <3300000>;
> >
> > + /*
> > + * signal name from schematics: TFLASH_VDD_EN
> > + */
> > gpio = <&gpio GPIOY_12 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > + /* U16 RT9179GB */
> > + vin-supply = <&vddio_ao3v3>;
> > };
> >
> > tf_io: gpio-regulator-tf_io {
> > @@ -95,6 +97,8 @@
> >
> > states = <3300000 0
> > 1800000 1>;
> > + /* U12/U13 RT9179GB */
> > + vin-supply = <&vddio_ao3v3>;
> > };
> thank you for the patch but I think it won't apply on top of Neil's
> "arm64: dts: meson: fix boards regulators states format" (which was
> applied just after you sent this series)
>
>
> Martin
Ok will re-base these changes on linux-next next time.
Best Regards
-Anand
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
From: Anand Moon @ 2019-09-01 13:57 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Neil Armstrong, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CAFBinCBWq0LcdA1-a5W06zKp0RzGs5_=Mph6StGKXJ7npCgbfg@mail.gmail.com>
Hi Martin,
Thanks for your review comments.
Their have been some revision changes in S905 Odroid Schematics.
[0] https://dn.odroid.com/S905/Schematic/
Well I have make my changes based on old odroid-c2_rev0.2_20151218.pdf
On Sun, 1 Sep 2019 at 17:07, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> On Wed, Aug 28, 2019 at 10:27 PM Anand Moon <linux.amoon@gmail.com> wrote:
> >
> > As per shematics VDDIO_AO18, VDDIO_AO3V3/VDD3V3 DDR3_1V5/DDR_VDDC:
> typo: "schematics"
>
OK. next time will run spell check before I send these changes.
> > fixed regulator output which is supplied by P5V0.
> >
> > Rename vcc3v3 regulator node to vddio_ao3v3 as per shematics.
> typo: "schematics"
Ok.
>
> according to the schematics there's both:
> - VDDIO_AO3V3
> - VCC3V3 (which is turned on by VDDIO_AO3V3, see [0])
>
From the schematics it seams same.
VDDIO_AO3V3---DMG340LSQN4 (Q4)---VCC3V3
But this name change was done to link TFLASH_VDD_EN to TFLASH_VDD for eMMC
VDDIO_AO3V3-----TFLASH_VDD using TFLASH_VDD_EN gpio pin.
Well I have tested this changes on eMMC module.
> > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Cc: Jerome Brunet <jbrunet@baylibre.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > ---
> > .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 +++++++++++++++++--
> > 1 file changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index 792698a60a12..98e742bf44c1 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -104,11 +104,34 @@
> > regulator-max-microvolt = <1800000>;
> > };
> >
> > - vcc3v3: regulator-vcc3v3 {
> > + vddio_ao1v8: regulator-vddio-ao1v8 {
> > compatible = "regulator-fixed";
> > - regulator-name = "VCC3V3";
> > + regulator-name = "VDDIO_AO1V8";
> > + regulator-min-microvolt = <1800000>;
> > + regulator-max-microvolt = <1800000>;
> > + regulator-always-on;
> > + /* U17 RT9179GB */
> > + vin-supply = <&p5v0>;
> > + };
> > +
> > + vddio_ao3v3: regulator-vddio-ao3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "VDDIO_AO3V3";
> > regulator-min-microvolt = <3300000>;
> > regulator-max-microvolt = <3300000>;
> > + regulator-always-on;
> > + /* U11 MP2161GJ-C499 */
> > + vin-supply = <&p5v0>;
> > + };
> > +
> > + vddc_ddr: regulator-vddc-ddr {
> > + compatible = "regulator-fixed";
> > + regulator-name = "DDR_VDDC";
> personally I would call this (along with the node name and alias) DDR3_1V5
> odroid-c2_rev0.1_20150930.pdf shows that DDR3_1V5 and DDR_VDDC are
> both the same. however, the DDR_VDDC signal name is not used by any
> component in the datasheet
Ok Thanks I will change this to DDR3_1V5 as per the datasheet.
>
> > + regulator-min-microvolt = <1500000>;
> > + regulator-max-microvolt = <1500000>;
> > + regulator-always-on;
> > + /* U15 MP2161GJ-C499 */
> > + vin-supply = <&p5v0>;
> > };
> >
> > emmc_pwrseq: emmc-pwrseq {
> > @@ -301,7 +324,7 @@
> > mmc-hs200-1_8v;
> >
> > mmc-pwrseq = <&emmc_pwrseq>;
> > - vmmc-supply = <&vcc3v3>;
> > + vmmc-supply = <&vddio_ao3v3>;
> odroid-c2_rev0.1_20150930.pdf uses VCC3V3 as supply
>
>
> Martin
Best Regards
-Anand
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 3/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI supply
From: Anand Moon @ 2019-09-01 13:58 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Neil Armstrong, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CAFBinCB9NPtncyJCMWDbbzJnQafeaY5U3XHh=NuRZSCNDdO=Hg@mail.gmail.com>
Hi Martin,
On Sun, 1 Sep 2019 at 17:14, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> Hi Anand,
>
> On Wed, Aug 28, 2019 at 10:27 PM Anand Moon <linux.amoon@gmail.com> wrote:
> >
> > As per shematics HDMI_P5V0 is supplied by P5V0 so add missing link.
> typo: "schematics"
>
> > Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > Cc: Jerome Brunet <jbrunet@baylibre.com>
> > Cc: Neil Armstrong <narmstrong@baylibre.com>
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index a078a1ee5004..47789fd50415 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -213,6 +213,8 @@
> > status = "okay";
> > pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
> > pinctrl-names = "default";
> > + /* AP2331SA-7 */
> > + hdmi-supply = <&p5v0>;
> > };
> my understanding based on odroid-c2_rev0.1_20150930.pdf is that:
> - there's a (fixed) hdmi_p5v0 regulator using p5v0 as input
> - the hdmi_p5v0 is the hdmi-supply
>
> it doesn't change the functionality of this patch (since both supplies
> are fixed regulators anyways)
> you are already doing a nice cleanup with this series, so it would be
> a shame to take a shortcut here
>
I could not find gpio control pin which could be used to enable
hdmi-supply node.
So that the reason for direct linking this to p5v0 node.
But looking back at the schematics it and datasheet their are two more
regulator supplies to HDMI.
HDMITX_AVDD33-1 ---- VDDIO_AO3V3
HDMITX_AVDD18-1 ---- VCC1V8
Need to check the hdmi driver if these need to enable.
Best Regards
-Anand
>
> Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Remi Pommarel @ 2019-09-01 14:23 UTC (permalink / raw)
To: Thomas Petazzoni, Lorenzo Pieralisi, Bjorn Helgaas
Cc: linux-pci, Remi Pommarel, linux-kernel, linux-arm-kernel
advk_pcie_wait_pio() can be called while holding a spinlock (from
pci_bus_read_config_dword()), then depends on jiffies in order to
timeout while polling on PIO state registers. In the case the PIO
transaction failed, the timeout will never happen and will also cause
the cpu to stall.
This decrements a variable and wait instead of using jiffies.
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
---
drivers/pci/controller/pci-aardvark.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fc0fe4d4de49..1fa6d04ad7aa 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -175,7 +175,8 @@
(PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn)) | \
PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
-#define PIO_TIMEOUT_MS 1
+#define PIO_RETRY_CNT 10
+#define PIO_RETRY_DELAY 100 /* 100 us*/
#define LINK_WAIT_MAX_RETRIES 10
#define LINK_WAIT_USLEEP_MIN 90000
@@ -383,17 +384,16 @@ static void advk_pcie_check_pio_status(struct advk_pcie *pcie)
static int advk_pcie_wait_pio(struct advk_pcie *pcie)
{
struct device *dev = &pcie->pdev->dev;
- unsigned long timeout;
+ size_t i;
- timeout = jiffies + msecs_to_jiffies(PIO_TIMEOUT_MS);
-
- while (time_before(jiffies, timeout)) {
+ for (i = 0; i < PIO_RETRY_CNT; ++i) {
u32 start, isr;
start = advk_readl(pcie, PIO_START);
isr = advk_readl(pcie, PIO_ISR);
if (!start && isr)
return 0;
+ udelay(PIO_RETRY_DELAY);
}
dev_err(dev, "config read/write timed out\n");
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] ARM: multi_v7_defconfig: enable NET_SCHED
From: Florian Klink @ 2019-09-01 17:51 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Florian Klink, Toke Høiland-Jørgensen
This enables QoS and/or fair queueing, and allows to build and configure
various schedulers.
Those are widely used already in desktop systems and routers, and
present in x86_64_defconfig as well.
Cc: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Florian Klink <flokli@flokli.de>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6a40bc2ef271..778265f19b8f 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -132,6 +132,7 @@ CONFIG_MODULE_UNLOAD=y
CONFIG_PARTITION_ADVANCED=y
CONFIG_CMDLINE_PARTITION=y
CONFIG_NET=y
+CONFIG_NET_SCHED=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] arm64: defconfig: enable NET_SCHED
From: Florian Klink @ 2019-09-01 17:51 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Florian Klink, Toke Høiland-Jørgensen
In-Reply-To: <20190901175137.32672-1-flokli@flokli.de>
This enables QoS and/or fair queueing, and allows to build and configure
various schedulers.
Those are widely used already in desktop systems and routers, and
present in x86_64_defconfig as well.
Cc: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Florian Klink <flokli@flokli.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..7f8d79d6899c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -135,6 +135,7 @@ CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
+CONFIG_NET_SCHED=y
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* next-20190830 on Droid 4 was Re: [PATCH 0/4] musb host improvments mostly for omap2430 glue
From: Pavel Machek @ 2019-09-01 19:39 UTC (permalink / raw)
To: Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, sre,
nekit1000, mpartap, merlijn
Cc: Jacopo Mondi, Marcel Partap, Greg Kroah-Hartman, Merlijn Wajer,
linux-usb, Sebastian Reichel, NeKit, Michael Scott, linux-omap,
Bin Liu
In-Reply-To: <20190830232058.53414-1-tony@atomide.com>
[-- Attachment #1.1: Type: text/plain, Size: 748 bytes --]
Hi!
> So I ended up cleaning up omap2430 glue layer a bit for host mode with the
> various reproducable errors I was seeing docking droid4 to a lapdock. There
> are a few fixes, and then we end up removing all the devctl register tinkering
> for omap2430 glue layer.
I thought I'd test this, so I took
commit 6d028043b55e54f48fbdf62ea8ce11a4ad830cac
Add linux-next specific files for 20190830
Series (and the other two patches you sent around it) applies ok, but
the result does not boot.
Hmm.
I guess I'll need to resurrect the serial port cable.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next-20190830 on Droid 4 was Re: [PATCH 0/4] musb host improvments mostly for omap2430 glue
From: Pavel Machek @ 2019-09-01 19:49 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacopo Mondi, mpartap, Tony Lindgren, Greg Kroah-Hartman, merlijn,
linux-usb, kernel list, sre, nekit1000, Michael Scott, linux-omap,
Bin Liu, linux-arm-kernel
In-Reply-To: <20190901193925.GA30586@amd>
[-- Attachment #1.1: Type: text/plain, Size: 2423 bytes --]
On Sun 2019-09-01 21:39:25, Pavel Machek wrote:
> Hi!
>
> > So I ended up cleaning up omap2430 glue layer a bit for host mode with the
> > various reproducable errors I was seeing docking droid4 to a lapdock. There
> > are a few fixes, and then we end up removing all the devctl register tinkering
> > for omap2430 glue layer.
>
> I thought I'd test this, so I took
>
> commit 6d028043b55e54f48fbdf62ea8ce11a4ad830cac
> Add linux-next specific files for 20190830
>
> Series (and the other two patches you sent around it) applies ok, but
> the result does not boot.
Hmm. Maybe I'm just having problem with the backlight. I do see
regulator failure:
[ 2.143920] cpcap-usb-phy cpcap-usb-phy.0: using device tree for
GPIO lookup
[ 2.151031] of_get_named_gpiod_flags: parsed 'mode-gpios' property
of node ')
[ 2.166015] gpio gpiochip2: Persistence not supported for GPIO 28
214935] ------------[ cut here ]------------
[ 2.219604] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2040
_regulat0
[ 2.228118] Modules linked in:
[ 2.231201] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.0-rc6-next-20190834
[ 2.238800] Hardware name: Generic OMAP4 (Flattened Device Tree)
[ 2.244873] [<c010f224>] (unwind_backtrace) from [<c010b4fc>]
(show_stack+0x)
[ 2.252655] [<c010b4fc>] (show_stack) from [<c08ca584>]
(dump_stack+0xa8/0xc)
and some drm problems:
[ 59.303253] omap-mcbsp 40124000.mcbsp: CLKS: could not clk_get()
prcm_fck
[ 59.311492] ------------[ cut here ]------------
[ 59.314666] WARNING: CPU: 0 PID: 2704 at
drivers/gpu/drm/omapdrm/dss/hdmi4.c0
[ 59.325866] Modules linked in:
[ 59.328948] CPU: 0 PID: 2704 Comm: alsa-sink-HDMI Tainted: G
W 4
[ 59.337982] Hardware name: Generic OMAP4 (Flattened Device Tree)
[ 59.344757] [<c010f224>] (unwind_backtrace) from [<c010b4fc>]
(show_stack+0x)
[ 59.352569] [<c010b4fc>] (show_stack) from [<c08ca584>]
(dump_stack+0xa8/0xc)
[ 59.359832] [<c08ca584>] (dump_stack) from [<c012de94>]
(__warn+0xc8/0xf0)
But I get login prompt on the serial. And after I do:
root@devuan:/sys/class/leds/lm3532::backlight# echo 255 > brightness
I can even see X are running.
Good so far :-).
Best regards, Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 11/13] power: reset: add driver for mt6323 poweroff
From: Sebastian Reichel @ 2019-09-01 20:11 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-rtc, devicetree, Alexandre Belloni, Eddie Huang,
linux-arm-kernel @ lists . infradead . org Alessandro Zummo,
linux-pm, Sean Wang, Josef Friedl, linux-kernel, Rob Herring,
linux-mediatek, Matthias Brugger, Mark Rutland, Tianping Fang,
Lee Jones, linux-arm-kernel
In-Reply-To: <20190818135611.7776-12-frank-w@public-files.de>
[-- Attachment #1.1: Type: text/plain, Size: 5568 bytes --]
Hi,
On Sun, Aug 18, 2019 at 03:56:09PM +0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add poweroff driver for mt6323 and make Makefile and Kconfig-Entries
>
> Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> changes since v5: split out mfd/mt6397/core.h
> changes since v4: none
> changes since v3: none
> changes since v2: none (=v2 part 5)
> ---
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> drivers/power/reset/Kconfig | 10 +++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/mt6323-poweroff.c | 97 +++++++++++++++++++++++++++
> 3 files changed, 108 insertions(+)
> create mode 100644 drivers/power/reset/mt6323-poweroff.c
>
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index a564237278ff..c721939767eb 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -140,6 +140,16 @@ config POWER_RESET_LTC2952
> This driver supports an external powerdown trigger and board power
> down via the LTC2952. Bindings are made in the device tree.
>
> +config POWER_RESET_MT6323
> + bool "MediaTek MT6323 power-off driver"
> + depends on MFD_MT6397
> + help
> + The power-off driver is responsible for externally shutdown down
> + the power of a remote MediaTek SoC MT6323 is connected to through
> + controlling a tiny circuit BBPU inside MT6323 RTC.
> +
> + Say Y if you have a board where MT6323 could be found.
> +
> config POWER_RESET_QNAP
> bool "QNAP power-off driver"
> depends on OF_GPIO && PLAT_ORION
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 85da3198e4e0..da37f8b851dc 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
> obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> +obj-$(CONFIG_POWER_RESET_MT6323) += mt6323-poweroff.o
> obj-$(CONFIG_POWER_RESET_QCOM_PON) += qcom-pon.o
> obj-$(CONFIG_POWER_RESET_OCELOT_RESET) += ocelot-reset.o
> obj-$(CONFIG_POWER_RESET_PIIX4_POWEROFF) += piix4-poweroff.o
> diff --git a/drivers/power/reset/mt6323-poweroff.c b/drivers/power/reset/mt6323-poweroff.c
> new file mode 100644
> index 000000000000..1caf43d9e46d
> --- /dev/null
> +++ b/drivers/power/reset/mt6323-poweroff.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Power off through MediaTek PMIC
> + *
> + * Copyright (C) 2018 MediaTek Inc.
> + *
> + * Author: Sean Wang <sean.wang@mediatek.com>
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/mt6397/core.h>
> +#include <linux/mfd/mt6397/rtc.h>
> +
> +struct mt6323_pwrc {
> + struct device *dev;
> + struct regmap *regmap;
> + u32 base;
> +};
> +
> +static struct mt6323_pwrc *mt_pwrc;
> +
> +static void mt6323_do_pwroff(void)
> +{
> + struct mt6323_pwrc *pwrc = mt_pwrc;
> + unsigned int val;
> + int ret;
> +
> + regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
> + regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);
> +
> + ret = regmap_read_poll_timeout(pwrc->regmap,
> + pwrc->base + RTC_BBPU, val,
> + !(val & RTC_BBPU_CBUSY),
> + MTK_RTC_POLL_DELAY_US,
> + MTK_RTC_POLL_TIMEOUT);
> + if (ret)
> + dev_err(pwrc->dev, "failed to write BBPU: %d\n", ret);
> +
> + /* Wait some time until system down, otherwise, notice with a warn */
> + mdelay(1000);
> +
> + WARN_ONCE(1, "Unable to power off system\n");
> +}
> +
> +static int mt6323_pwrc_probe(struct platform_device *pdev)
> +{
> + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> + struct mt6323_pwrc *pwrc;
> + struct resource *res;
> +
> + pwrc = devm_kzalloc(&pdev->dev, sizeof(*pwrc), GFP_KERNEL);
> + if (!pwrc)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pwrc->base = res->start;
> + pwrc->regmap = mt6397_chip->regmap;
> + pwrc->dev = &pdev->dev;
> + mt_pwrc = pwrc;
> +
> + pm_power_off = &mt6323_do_pwroff;
> +
> + return 0;
> +}
> +
> +static int mt6323_pwrc_remove(struct platform_device *pdev)
> +{
> + if (pm_power_off == &mt6323_do_pwroff)
> + pm_power_off = NULL;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mt6323_pwrc_dt_match[] = {
> + { .compatible = "mediatek,mt6323-pwrc" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mt6323_pwrc_dt_match);
> +
> +static struct platform_driver mt6323_pwrc_driver = {
> + .probe = mt6323_pwrc_probe,
> + .remove = mt6323_pwrc_remove,
> + .driver = {
> + .name = "mt6323-pwrc",
> + .of_match_table = mt6323_pwrc_dt_match,
> + },
> +};
> +
> +module_platform_driver(mt6323_pwrc_driver);
> +
> +MODULE_DESCRIPTION("Poweroff driver for MT6323 PMIC");
> +MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 12/13] MAINTAINERS: add Mediatek shutdown drivers
From: Sebastian Reichel @ 2019-09-01 20:12 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-rtc, devicetree, Alexandre Belloni, Eddie Huang,
linux-arm-kernel @ lists . infradead . org Alessandro Zummo,
linux-pm, Sean Wang, Josef Friedl, linux-kernel, Rob Herring,
linux-mediatek, Matthias Brugger, Mark Rutland, Tianping Fang,
Lee Jones, linux-arm-kernel
In-Reply-To: <20190818135611.7776-13-frank-w@public-files.de>
[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]
Hi,
On Sun, Aug 18, 2019 at 03:56:10PM +0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add Section in MAINTAINERS file for poweroff driver
>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> changes since v5: none
> changes since v4: none
> changes since v3: moved SOB
> changes since v2: none (=v2 part 6)
> ---
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6426db5198f0..4172a3177633 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10128,6 +10128,13 @@ S: Maintained
> F: drivers/net/dsa/mt7530.*
> F: net/dsa/tag_mtk.c
>
> +MEDIATEK BOARD LEVEL SHUTDOWN DRIVERS
> +M: Sean Wang <sean.wang@mediatek.com>
> +L: linux-pm@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
> +F: drivers/power/reset/mt6323-poweroff.c
> +
> MEDIATEK JPEG DRIVER
> M: Rick Chang <rick.chang@mediatek.com>
> M: Bin Liu <bin.liu@mediatek.com>
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: ep93xx: Repair SPI CS lookup tables
From: Linus Walleij @ 2019-09-01 20:16 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Hartley Sweeten, Russell King, stable, linux-spi,
open list:GPIO SUBSYSTEM, Mark Brown, Lukasz Majewski, Linux ARM
In-Reply-To: <20190831180402.10008-1-alexander.sverdlin@gmail.com>
On Sat, Aug 31, 2019 at 8:05 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> The actual device name of the SPI controller being registered on EP93xx is
> "spi0" (as seen by gpiod_find_lookup_table()). This patch fixes all
> relevant lookup tables and the following failure (seen on EDB9302):
>
> ep93xx-spi ep93xx-spi.0: failed to register SPI master
> ep93xx-spi: probe of ep93xx-spi.0 failed with error -22
>
> Fixes: 1dfbf334f1236 ("spi: ep93xx: Convert to use CS GPIO descriptors")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Sorry for the mistakes and thanks for fixing, much appreciated!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/9] crypto: sha256 - Merge crypto/sha256.h into crypto/sha.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
Hi All,
As promised here is a follow-up series to my earlier sha256 series.
Note I have only compiled and tested this series on x86_64 !!
All changes to architecture specific code on other archs have not even
been tested to compile! With that said most of these changes were done
using my editors search - replace function so things should be fine...
(and FWIW I did do a Kconfig hack to compile test the ccree change).
The first patch in this series rename various file local functions /
arrays to avoid conflicts with the new include/crypto/sha256.h, followed
by a patch merging include/crypto/sha256.h into include/crypto/sha.h.
The last patch makes use of this merging to remove a bit more code
duplication, making sha256_generic use sha256_init and sha224_init from
lib/crypto/sha256.c. An added advantage of this, is that this gives these
2 functions coverage by the crypto selftests.
Regards,
Hans
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/9] crypto: arm - Rename functions to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/arm/crypto/sha256_glue.c | 8 ++++----
arch/arm/crypto/sha256_neon_glue.c | 24 ++++++++++++------------
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/crypto/sha256_glue.c b/arch/arm/crypto/sha256_glue.c
index 70efa9656bff..215497f011f2 100644
--- a/arch/arm/crypto/sha256_glue.c
+++ b/arch/arm/crypto/sha256_glue.c
@@ -39,7 +39,7 @@ int crypto_sha256_arm_update(struct shash_desc *desc, const u8 *data,
}
EXPORT_SYMBOL(crypto_sha256_arm_update);
-static int sha256_final(struct shash_desc *desc, u8 *out)
+static int crypto_sha256_arm_final(struct shash_desc *desc, u8 *out)
{
sha256_base_do_finalize(desc,
(sha256_block_fn *)sha256_block_data_order);
@@ -51,7 +51,7 @@ int crypto_sha256_arm_finup(struct shash_desc *desc, const u8 *data,
{
sha256_base_do_update(desc, data, len,
(sha256_block_fn *)sha256_block_data_order);
- return sha256_final(desc, out);
+ return crypto_sha256_arm_final(desc, out);
}
EXPORT_SYMBOL(crypto_sha256_arm_finup);
@@ -59,7 +59,7 @@ static struct shash_alg algs[] = { {
.digestsize = SHA256_DIGEST_SIZE,
.init = sha256_base_init,
.update = crypto_sha256_arm_update,
- .final = sha256_final,
+ .final = crypto_sha256_arm_final,
.finup = crypto_sha256_arm_finup,
.descsize = sizeof(struct sha256_state),
.base = {
@@ -73,7 +73,7 @@ static struct shash_alg algs[] = { {
.digestsize = SHA224_DIGEST_SIZE,
.init = sha224_base_init,
.update = crypto_sha256_arm_update,
- .final = sha256_final,
+ .final = crypto_sha256_arm_final,
.finup = crypto_sha256_arm_finup,
.descsize = sizeof(struct sha256_state),
.base = {
diff --git a/arch/arm/crypto/sha256_neon_glue.c b/arch/arm/crypto/sha256_neon_glue.c
index a7ce38a36006..38645e415196 100644
--- a/arch/arm/crypto/sha256_neon_glue.c
+++ b/arch/arm/crypto/sha256_neon_glue.c
@@ -25,8 +25,8 @@
asmlinkage void sha256_block_data_order_neon(u32 *digest, const void *data,
unsigned int num_blks);
-static int sha256_update(struct shash_desc *desc, const u8 *data,
- unsigned int len)
+static int crypto_sha256_neon_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len)
{
struct sha256_state *sctx = shash_desc_ctx(desc);
@@ -42,8 +42,8 @@ static int sha256_update(struct shash_desc *desc, const u8 *data,
return 0;
}
-static int sha256_finup(struct shash_desc *desc, const u8 *data,
- unsigned int len, u8 *out)
+static int crypto_sha256_neon_finup(struct shash_desc *desc, const u8 *data,
+ unsigned int len, u8 *out)
{
if (!crypto_simd_usable())
return crypto_sha256_arm_finup(desc, data, len, out);
@@ -59,17 +59,17 @@ static int sha256_finup(struct shash_desc *desc, const u8 *data,
return sha256_base_finish(desc, out);
}
-static int sha256_final(struct shash_desc *desc, u8 *out)
+static int crypto_sha256_neon_final(struct shash_desc *desc, u8 *out)
{
- return sha256_finup(desc, NULL, 0, out);
+ return crypto_sha256_neon_finup(desc, NULL, 0, out);
}
struct shash_alg sha256_neon_algs[] = { {
.digestsize = SHA256_DIGEST_SIZE,
.init = sha256_base_init,
- .update = sha256_update,
- .final = sha256_final,
- .finup = sha256_finup,
+ .update = crypto_sha256_neon_update,
+ .final = crypto_sha256_neon_final,
+ .finup = crypto_sha256_neon_finup,
.descsize = sizeof(struct sha256_state),
.base = {
.cra_name = "sha256",
@@ -81,9 +81,9 @@ struct shash_alg sha256_neon_algs[] = { {
}, {
.digestsize = SHA224_DIGEST_SIZE,
.init = sha224_base_init,
- .update = sha256_update,
- .final = sha256_final,
- .finup = sha256_finup,
+ .update = crypto_sha256_neon_update,
+ .final = crypto_sha256_neon_final,
+ .finup = crypto_sha256_neon_finup,
.descsize = sizeof(struct sha256_state),
.base = {
.cra_name = "sha224",
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/9] crypto: arm64 - Rename functions to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/arm64/crypto/sha256-glue.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/crypto/sha256-glue.c b/arch/arm64/crypto/sha256-glue.c
index 04b9d17b0733..e273faca924f 100644
--- a/arch/arm64/crypto/sha256-glue.c
+++ b/arch/arm64/crypto/sha256-glue.c
@@ -30,15 +30,15 @@ EXPORT_SYMBOL(sha256_block_data_order);
asmlinkage void sha256_block_neon(u32 *digest, const void *data,
unsigned int num_blks);
-static int sha256_update(struct shash_desc *desc, const u8 *data,
- unsigned int len)
+static int crypto_sha256_arm64_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len)
{
return sha256_base_do_update(desc, data, len,
(sha256_block_fn *)sha256_block_data_order);
}
-static int sha256_finup(struct shash_desc *desc, const u8 *data,
- unsigned int len, u8 *out)
+static int crypto_sha256_arm64_finup(struct shash_desc *desc, const u8 *data,
+ unsigned int len, u8 *out)
{
if (len)
sha256_base_do_update(desc, data, len,
@@ -49,17 +49,17 @@ static int sha256_finup(struct shash_desc *desc, const u8 *data,
return sha256_base_finish(desc, out);
}
-static int sha256_final(struct shash_desc *desc, u8 *out)
+static int crypto_sha256_arm64_final(struct shash_desc *desc, u8 *out)
{
- return sha256_finup(desc, NULL, 0, out);
+ return crypto_sha256_arm64_finup(desc, NULL, 0, out);
}
static struct shash_alg algs[] = { {
.digestsize = SHA256_DIGEST_SIZE,
.init = sha256_base_init,
- .update = sha256_update,
- .final = sha256_final,
- .finup = sha256_finup,
+ .update = crypto_sha256_arm64_update,
+ .final = crypto_sha256_arm64_final,
+ .finup = crypto_sha256_arm64_finup,
.descsize = sizeof(struct sha256_state),
.base.cra_name = "sha256",
.base.cra_driver_name = "sha256-arm64",
@@ -69,9 +69,9 @@ static struct shash_alg algs[] = { {
}, {
.digestsize = SHA224_DIGEST_SIZE,
.init = sha224_base_init,
- .update = sha256_update,
- .final = sha256_final,
- .finup = sha256_finup,
+ .update = crypto_sha256_arm64_update,
+ .final = crypto_sha256_arm64_final,
+ .finup = crypto_sha256_arm64_finup,
.descsize = sizeof(struct sha256_state),
.base.cra_name = "sha224",
.base.cra_driver_name = "sha224-arm64",
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/9] crypto: s390 - Rename functions to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/s390/crypto/sha256_s390.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/s390/crypto/sha256_s390.c b/arch/s390/crypto/sha256_s390.c
index af7505148f80..b52c87e44939 100644
--- a/arch/s390/crypto/sha256_s390.c
+++ b/arch/s390/crypto/sha256_s390.c
@@ -17,7 +17,7 @@
#include "sha.h"
-static int sha256_init(struct shash_desc *desc)
+static int s390_sha256_init(struct shash_desc *desc)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
@@ -60,7 +60,7 @@ static int sha256_import(struct shash_desc *desc, const void *in)
static struct shash_alg sha256_alg = {
.digestsize = SHA256_DIGEST_SIZE,
- .init = sha256_init,
+ .init = s390_sha256_init,
.update = s390_sha_update,
.final = s390_sha_final,
.export = sha256_export,
@@ -76,7 +76,7 @@ static struct shash_alg sha256_alg = {
}
};
-static int sha224_init(struct shash_desc *desc)
+static int s390_sha224_init(struct shash_desc *desc)
{
struct s390_sha_ctx *sctx = shash_desc_ctx(desc);
@@ -96,7 +96,7 @@ static int sha224_init(struct shash_desc *desc)
static struct shash_alg sha224_alg = {
.digestsize = SHA224_DIGEST_SIZE,
- .init = sha224_init,
+ .init = s390_sha224_init,
.update = s390_sha_update,
.final = s390_sha_final,
.export = sha256_export,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/9] crypto: x86 - Rename functions to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/x86/crypto/sha256_ssse3_glue.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/crypto/sha256_ssse3_glue.c b/arch/x86/crypto/sha256_ssse3_glue.c
index 73867da3cbee..f9aff31fe59e 100644
--- a/arch/x86/crypto/sha256_ssse3_glue.c
+++ b/arch/x86/crypto/sha256_ssse3_glue.c
@@ -45,8 +45,8 @@ asmlinkage void sha256_transform_ssse3(u32 *digest, const char *data,
u64 rounds);
typedef void (sha256_transform_fn)(u32 *digest, const char *data, u64 rounds);
-static int sha256_update(struct shash_desc *desc, const u8 *data,
- unsigned int len, sha256_transform_fn *sha256_xform)
+static int _sha256_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len, sha256_transform_fn *sha256_xform)
{
struct sha256_state *sctx = shash_desc_ctx(desc);
@@ -84,7 +84,7 @@ static int sha256_finup(struct shash_desc *desc, const u8 *data,
static int sha256_ssse3_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
- return sha256_update(desc, data, len, sha256_transform_ssse3);
+ return _sha256_update(desc, data, len, sha256_transform_ssse3);
}
static int sha256_ssse3_finup(struct shash_desc *desc, const u8 *data,
@@ -151,7 +151,7 @@ asmlinkage void sha256_transform_avx(u32 *digest, const char *data,
static int sha256_avx_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
- return sha256_update(desc, data, len, sha256_transform_avx);
+ return _sha256_update(desc, data, len, sha256_transform_avx);
}
static int sha256_avx_finup(struct shash_desc *desc, const u8 *data,
@@ -233,7 +233,7 @@ asmlinkage void sha256_transform_rorx(u32 *digest, const char *data,
static int sha256_avx2_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
- return sha256_update(desc, data, len, sha256_transform_rorx);
+ return _sha256_update(desc, data, len, sha256_transform_rorx);
}
static int sha256_avx2_finup(struct shash_desc *desc, const u8 *data,
@@ -313,7 +313,7 @@ asmlinkage void sha256_ni_transform(u32 *digest, const char *data,
static int sha256_ni_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
- return sha256_update(desc, data, len, sha256_ni_transform);
+ return _sha256_update(desc, data, len, sha256_ni_transform);
}
static int sha256_ni_finup(struct shash_desc *desc, const u8 *data,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/9] crypto: ccree - Rename arrays to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename the algo_init arrays to cc_algo_init so that they do not conflict
with the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/crypto/ccree/cc_hash.c | 153 +++++++++++++++++----------------
1 file changed, 77 insertions(+), 76 deletions(-)
diff --git a/drivers/crypto/ccree/cc_hash.c b/drivers/crypto/ccree/cc_hash.c
index a6abe4e3bb0e..bc71bdf44a9f 100644
--- a/drivers/crypto/ccree/cc_hash.c
+++ b/drivers/crypto/ccree/cc_hash.c
@@ -25,27 +25,27 @@ struct cc_hash_handle {
struct list_head hash_list;
};
-static const u32 digest_len_init[] = {
+static const u32 cc_digest_len_init[] = {
0x00000040, 0x00000000, 0x00000000, 0x00000000 };
-static const u32 md5_init[] = {
+static const u32 cc_md5_init[] = {
SHA1_H3, SHA1_H2, SHA1_H1, SHA1_H0 };
-static const u32 sha1_init[] = {
+static const u32 cc_sha1_init[] = {
SHA1_H4, SHA1_H3, SHA1_H2, SHA1_H1, SHA1_H0 };
-static const u32 sha224_init[] = {
+static const u32 cc_sha224_init[] = {
SHA224_H7, SHA224_H6, SHA224_H5, SHA224_H4,
SHA224_H3, SHA224_H2, SHA224_H1, SHA224_H0 };
-static const u32 sha256_init[] = {
+static const u32 cc_sha256_init[] = {
SHA256_H7, SHA256_H6, SHA256_H5, SHA256_H4,
SHA256_H3, SHA256_H2, SHA256_H1, SHA256_H0 };
-static const u32 digest_len_sha512_init[] = {
+static const u32 cc_digest_len_sha512_init[] = {
0x00000080, 0x00000000, 0x00000000, 0x00000000 };
-static u64 sha384_init[] = {
+static u64 cc_sha384_init[] = {
SHA384_H7, SHA384_H6, SHA384_H5, SHA384_H4,
SHA384_H3, SHA384_H2, SHA384_H1, SHA384_H0 };
-static u64 sha512_init[] = {
+static u64 cc_sha512_init[] = {
SHA512_H7, SHA512_H6, SHA512_H5, SHA512_H4,
SHA512_H3, SHA512_H2, SHA512_H1, SHA512_H0 };
-static const u32 sm3_init[] = {
+static const u32 cc_sm3_init[] = {
SM3_IVH, SM3_IVG, SM3_IVF, SM3_IVE,
SM3_IVD, SM3_IVC, SM3_IVB, SM3_IVA };
@@ -144,10 +144,11 @@ static void cc_init_req(struct device *dev, struct ahash_req_ctx *state,
if (ctx->hash_mode == DRV_HASH_SHA512 ||
ctx->hash_mode == DRV_HASH_SHA384)
memcpy(state->digest_bytes_len,
- digest_len_sha512_init,
+ cc_digest_len_sha512_init,
ctx->hash_len);
else
- memcpy(state->digest_bytes_len, digest_len_init,
+ memcpy(state->digest_bytes_len,
+ cc_digest_len_init,
ctx->hash_len);
}
@@ -1873,26 +1874,26 @@ int cc_init_hash_sram(struct cc_drvdata *drvdata)
int rc = 0;
/* Copy-to-sram digest-len */
- cc_set_sram_desc(digest_len_init, sram_buff_ofs,
- ARRAY_SIZE(digest_len_init), larval_seq,
+ cc_set_sram_desc(cc_digest_len_init, sram_buff_ofs,
+ ARRAY_SIZE(cc_digest_len_init), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(digest_len_init);
+ sram_buff_ofs += sizeof(cc_digest_len_init);
larval_seq_len = 0;
if (large_sha_supported) {
/* Copy-to-sram digest-len for sha384/512 */
- cc_set_sram_desc(digest_len_sha512_init, sram_buff_ofs,
- ARRAY_SIZE(digest_len_sha512_init),
+ cc_set_sram_desc(cc_digest_len_sha512_init, sram_buff_ofs,
+ ARRAY_SIZE(cc_digest_len_sha512_init),
larval_seq, &larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(digest_len_sha512_init);
+ sram_buff_ofs += sizeof(cc_digest_len_sha512_init);
larval_seq_len = 0;
}
@@ -1900,64 +1901,64 @@ int cc_init_hash_sram(struct cc_drvdata *drvdata)
hash_handle->larval_digest_sram_addr = sram_buff_ofs;
/* Copy-to-sram initial SHA* digests */
- cc_set_sram_desc(md5_init, sram_buff_ofs, ARRAY_SIZE(md5_init),
+ cc_set_sram_desc(cc_md5_init, sram_buff_ofs, ARRAY_SIZE(cc_md5_init),
larval_seq, &larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(md5_init);
+ sram_buff_ofs += sizeof(cc_md5_init);
larval_seq_len = 0;
- cc_set_sram_desc(sha1_init, sram_buff_ofs,
- ARRAY_SIZE(sha1_init), larval_seq,
+ cc_set_sram_desc(cc_sha1_init, sram_buff_ofs,
+ ARRAY_SIZE(cc_sha1_init), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(sha1_init);
+ sram_buff_ofs += sizeof(cc_sha1_init);
larval_seq_len = 0;
- cc_set_sram_desc(sha224_init, sram_buff_ofs,
- ARRAY_SIZE(sha224_init), larval_seq,
+ cc_set_sram_desc(cc_sha224_init, sram_buff_ofs,
+ ARRAY_SIZE(cc_sha224_init), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(sha224_init);
+ sram_buff_ofs += sizeof(cc_sha224_init);
larval_seq_len = 0;
- cc_set_sram_desc(sha256_init, sram_buff_ofs,
- ARRAY_SIZE(sha256_init), larval_seq,
+ cc_set_sram_desc(cc_sha256_init, sram_buff_ofs,
+ ARRAY_SIZE(cc_sha256_init), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(sha256_init);
+ sram_buff_ofs += sizeof(cc_sha256_init);
larval_seq_len = 0;
if (sm3_supported) {
- cc_set_sram_desc(sm3_init, sram_buff_ofs,
- ARRAY_SIZE(sm3_init), larval_seq,
+ cc_set_sram_desc(cc_sm3_init, sram_buff_ofs,
+ ARRAY_SIZE(cc_sm3_init), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(sm3_init);
+ sram_buff_ofs += sizeof(cc_sm3_init);
larval_seq_len = 0;
}
if (large_sha_supported) {
- cc_set_sram_desc((u32 *)sha384_init, sram_buff_ofs,
- (ARRAY_SIZE(sha384_init) * 2), larval_seq,
+ cc_set_sram_desc((u32 *)cc_sha384_init, sram_buff_ofs,
+ (ARRAY_SIZE(cc_sha384_init) * 2), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
goto init_digest_const_err;
- sram_buff_ofs += sizeof(sha384_init);
+ sram_buff_ofs += sizeof(cc_sha384_init);
larval_seq_len = 0;
- cc_set_sram_desc((u32 *)sha512_init, sram_buff_ofs,
- (ARRAY_SIZE(sha512_init) * 2), larval_seq,
+ cc_set_sram_desc((u32 *)cc_sha512_init, sram_buff_ofs,
+ (ARRAY_SIZE(cc_sha512_init) * 2), larval_seq,
&larval_seq_len);
rc = send_request_init(drvdata, larval_seq, larval_seq_len);
if (rc)
@@ -1986,8 +1987,8 @@ static void __init cc_swap_dwords(u32 *buf, unsigned long size)
*/
void __init cc_hash_global_init(void)
{
- cc_swap_dwords((u32 *)&sha384_init, (ARRAY_SIZE(sha384_init) * 2));
- cc_swap_dwords((u32 *)&sha512_init, (ARRAY_SIZE(sha512_init) * 2));
+ cc_swap_dwords((u32 *)&cc_sha384_init, (ARRAY_SIZE(cc_sha384_init) * 2));
+ cc_swap_dwords((u32 *)&cc_sha512_init, (ARRAY_SIZE(cc_sha512_init) * 2));
}
int cc_hash_alloc(struct cc_drvdata *drvdata)
@@ -2006,18 +2007,18 @@ int cc_hash_alloc(struct cc_drvdata *drvdata)
INIT_LIST_HEAD(&hash_handle->hash_list);
drvdata->hash_handle = hash_handle;
- sram_size_to_alloc = sizeof(digest_len_init) +
- sizeof(md5_init) +
- sizeof(sha1_init) +
- sizeof(sha224_init) +
- sizeof(sha256_init);
+ sram_size_to_alloc = sizeof(cc_digest_len_init) +
+ sizeof(cc_md5_init) +
+ sizeof(cc_sha1_init) +
+ sizeof(cc_sha224_init) +
+ sizeof(cc_sha256_init);
if (drvdata->hw_rev >= CC_HW_REV_713)
- sram_size_to_alloc += sizeof(sm3_init);
+ sram_size_to_alloc += sizeof(cc_sm3_init);
if (drvdata->hw_rev >= CC_HW_REV_712)
- sram_size_to_alloc += sizeof(digest_len_sha512_init) +
- sizeof(sha384_init) + sizeof(sha512_init);
+ sram_size_to_alloc += sizeof(cc_digest_len_sha512_init) +
+ sizeof(cc_sha384_init) + sizeof(cc_sha512_init);
sram_buff = cc_sram_alloc(drvdata, sram_size_to_alloc);
if (sram_buff == NULL_SRAM_ADDR) {
@@ -2258,22 +2259,22 @@ static const void *cc_larval_digest(struct device *dev, u32 mode)
{
switch (mode) {
case DRV_HASH_MD5:
- return md5_init;
+ return cc_md5_init;
case DRV_HASH_SHA1:
- return sha1_init;
+ return cc_sha1_init;
case DRV_HASH_SHA224:
- return sha224_init;
+ return cc_sha224_init;
case DRV_HASH_SHA256:
- return sha256_init;
+ return cc_sha256_init;
case DRV_HASH_SHA384:
- return sha384_init;
+ return cc_sha384_init;
case DRV_HASH_SHA512:
- return sha512_init;
+ return cc_sha512_init;
case DRV_HASH_SM3:
- return sm3_init;
+ return cc_sm3_init;
default:
dev_err(dev, "Invalid hash mode (%d)\n", mode);
- return md5_init;
+ return cc_md5_init;
}
}
@@ -2301,40 +2302,40 @@ cc_sram_addr_t cc_larval_digest_addr(void *drvdata, u32 mode)
return (hash_handle->larval_digest_sram_addr);
case DRV_HASH_SHA1:
return (hash_handle->larval_digest_sram_addr +
- sizeof(md5_init));
+ sizeof(cc_md5_init));
case DRV_HASH_SHA224:
return (hash_handle->larval_digest_sram_addr +
- sizeof(md5_init) +
- sizeof(sha1_init));
+ sizeof(cc_md5_init) +
+ sizeof(cc_sha1_init));
case DRV_HASH_SHA256:
return (hash_handle->larval_digest_sram_addr +
- sizeof(md5_init) +
- sizeof(sha1_init) +
- sizeof(sha224_init));
+ sizeof(cc_md5_init) +
+ sizeof(cc_sha1_init) +
+ sizeof(cc_sha224_init));
case DRV_HASH_SM3:
return (hash_handle->larval_digest_sram_addr +
- sizeof(md5_init) +
- sizeof(sha1_init) +
- sizeof(sha224_init) +
- sizeof(sha256_init));
+ sizeof(cc_md5_init) +
+ sizeof(cc_sha1_init) +
+ sizeof(cc_sha224_init) +
+ sizeof(cc_sha256_init));
case DRV_HASH_SHA384:
addr = (hash_handle->larval_digest_sram_addr +
- sizeof(md5_init) +
- sizeof(sha1_init) +
- sizeof(sha224_init) +
- sizeof(sha256_init));
+ sizeof(cc_md5_init) +
+ sizeof(cc_sha1_init) +
+ sizeof(cc_sha224_init) +
+ sizeof(cc_sha256_init));
if (sm3_supported)
- addr += sizeof(sm3_init);
+ addr += sizeof(cc_sm3_init);
return addr;
case DRV_HASH_SHA512:
addr = (hash_handle->larval_digest_sram_addr +
- sizeof(md5_init) +
- sizeof(sha1_init) +
- sizeof(sha224_init) +
- sizeof(sha256_init) +
- sizeof(sha384_init));
+ sizeof(cc_md5_init) +
+ sizeof(cc_sha1_init) +
+ sizeof(cc_sha224_init) +
+ sizeof(cc_sha256_init) +
+ sizeof(cc_sha384_init));
if (sm3_supported)
- addr += sizeof(sm3_init);
+ addr += sizeof(cc_sm3_init);
return addr;
default:
dev_err(dev, "Invalid hash mode (%d)\n", mode);
@@ -2360,7 +2361,7 @@ cc_digest_len_addr(void *drvdata, u32 mode)
#if (CC_DEV_SHA_MAX > 256)
case DRV_HASH_SHA384:
case DRV_HASH_SHA512:
- return digest_len_addr + sizeof(digest_len_init);
+ return digest_len_addr + sizeof(cc_digest_len_init);
#endif
default:
return digest_len_addr; /*to avoid kernel crash*/
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/9] crypto: chelsio - Rename arrays to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename the sha*_init arrays to chcr_sha*_init so that they do not conflict
with the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/crypto/chelsio/chcr_algo.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.h b/drivers/crypto/chelsio/chcr_algo.h
index ee20dd899e83..d1e6b51df0ce 100644
--- a/drivers/crypto/chelsio/chcr_algo.h
+++ b/drivers/crypto/chelsio/chcr_algo.h
@@ -333,26 +333,26 @@ struct phys_sge_pairs {
};
-static const u32 sha1_init[SHA1_DIGEST_SIZE / 4] = {
+static const u32 chcr_sha1_init[SHA1_DIGEST_SIZE / 4] = {
SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4,
};
-static const u32 sha224_init[SHA256_DIGEST_SIZE / 4] = {
+static const u32 chcr_sha224_init[SHA256_DIGEST_SIZE / 4] = {
SHA224_H0, SHA224_H1, SHA224_H2, SHA224_H3,
SHA224_H4, SHA224_H5, SHA224_H6, SHA224_H7,
};
-static const u32 sha256_init[SHA256_DIGEST_SIZE / 4] = {
+static const u32 chcr_sha256_init[SHA256_DIGEST_SIZE / 4] = {
SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7,
};
-static const u64 sha384_init[SHA512_DIGEST_SIZE / 8] = {
+static const u64 chcr_sha384_init[SHA512_DIGEST_SIZE / 8] = {
SHA384_H0, SHA384_H1, SHA384_H2, SHA384_H3,
SHA384_H4, SHA384_H5, SHA384_H6, SHA384_H7,
};
-static const u64 sha512_init[SHA512_DIGEST_SIZE / 8] = {
+static const u64 chcr_sha512_init[SHA512_DIGEST_SIZE / 8] = {
SHA512_H0, SHA512_H1, SHA512_H2, SHA512_H3,
SHA512_H4, SHA512_H5, SHA512_H6, SHA512_H7,
};
@@ -362,21 +362,21 @@ static inline void copy_hash_init_values(char *key, int digestsize)
u8 i;
__be32 *dkey = (__be32 *)key;
u64 *ldkey = (u64 *)key;
- __be64 *sha384 = (__be64 *)sha384_init;
- __be64 *sha512 = (__be64 *)sha512_init;
+ __be64 *sha384 = (__be64 *)chcr_sha384_init;
+ __be64 *sha512 = (__be64 *)chcr_sha512_init;
switch (digestsize) {
case SHA1_DIGEST_SIZE:
for (i = 0; i < SHA1_INIT_STATE; i++)
- dkey[i] = cpu_to_be32(sha1_init[i]);
+ dkey[i] = cpu_to_be32(chcr_sha1_init[i]);
break;
case SHA224_DIGEST_SIZE:
for (i = 0; i < SHA224_INIT_STATE; i++)
- dkey[i] = cpu_to_be32(sha224_init[i]);
+ dkey[i] = cpu_to_be32(chcr_sha224_init[i]);
break;
case SHA256_DIGEST_SIZE:
for (i = 0; i < SHA256_INIT_STATE; i++)
- dkey[i] = cpu_to_be32(sha256_init[i]);
+ dkey[i] = cpu_to_be32(chcr_sha256_init[i]);
break;
case SHA384_DIGEST_SIZE:
for (i = 0; i < SHA384_INIT_STATE; i++)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 7/9] crypto: n2 - Rename arrays to avoid conflict with crypto/sha256.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
Rename the sha*_init arrays to n2_sha*_init so that they do not conflict
with the functions declared in crypto/sha256.h.
Also rename md5_init to n2_md5_init for consistency.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/crypto/n2_core.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 760e72a5893b..c4bf85fc9601 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -1295,20 +1295,20 @@ struct n2_hash_tmpl {
u8 hmac_type;
};
-static const u32 md5_init[MD5_HASH_WORDS] = {
+static const u32 n2_md5_init[MD5_HASH_WORDS] = {
cpu_to_le32(MD5_H0),
cpu_to_le32(MD5_H1),
cpu_to_le32(MD5_H2),
cpu_to_le32(MD5_H3),
};
-static const u32 sha1_init[SHA1_DIGEST_SIZE / 4] = {
+static const u32 n2_sha1_init[SHA1_DIGEST_SIZE / 4] = {
SHA1_H0, SHA1_H1, SHA1_H2, SHA1_H3, SHA1_H4,
};
-static const u32 sha256_init[SHA256_DIGEST_SIZE / 4] = {
+static const u32 n2_sha256_init[SHA256_DIGEST_SIZE / 4] = {
SHA256_H0, SHA256_H1, SHA256_H2, SHA256_H3,
SHA256_H4, SHA256_H5, SHA256_H6, SHA256_H7,
};
-static const u32 sha224_init[SHA256_DIGEST_SIZE / 4] = {
+static const u32 n2_sha224_init[SHA256_DIGEST_SIZE / 4] = {
SHA224_H0, SHA224_H1, SHA224_H2, SHA224_H3,
SHA224_H4, SHA224_H5, SHA224_H6, SHA224_H7,
};
@@ -1316,7 +1316,7 @@ static const u32 sha224_init[SHA256_DIGEST_SIZE / 4] = {
static const struct n2_hash_tmpl hash_tmpls[] = {
{ .name = "md5",
.hash_zero = md5_zero_message_hash,
- .hash_init = md5_init,
+ .hash_init = n2_md5_init,
.auth_type = AUTH_TYPE_MD5,
.hmac_type = AUTH_TYPE_HMAC_MD5,
.hw_op_hashsz = MD5_DIGEST_SIZE,
@@ -1324,7 +1324,7 @@ static const struct n2_hash_tmpl hash_tmpls[] = {
.block_size = MD5_HMAC_BLOCK_SIZE },
{ .name = "sha1",
.hash_zero = sha1_zero_message_hash,
- .hash_init = sha1_init,
+ .hash_init = n2_sha1_init,
.auth_type = AUTH_TYPE_SHA1,
.hmac_type = AUTH_TYPE_HMAC_SHA1,
.hw_op_hashsz = SHA1_DIGEST_SIZE,
@@ -1332,7 +1332,7 @@ static const struct n2_hash_tmpl hash_tmpls[] = {
.block_size = SHA1_BLOCK_SIZE },
{ .name = "sha256",
.hash_zero = sha256_zero_message_hash,
- .hash_init = sha256_init,
+ .hash_init = n2_sha256_init,
.auth_type = AUTH_TYPE_SHA256,
.hmac_type = AUTH_TYPE_HMAC_SHA256,
.hw_op_hashsz = SHA256_DIGEST_SIZE,
@@ -1340,7 +1340,7 @@ static const struct n2_hash_tmpl hash_tmpls[] = {
.block_size = SHA256_BLOCK_SIZE },
{ .name = "sha224",
.hash_zero = sha224_zero_message_hash,
- .hash_init = sha224_init,
+ .hash_init = n2_sha224_init,
.auth_type = AUTH_TYPE_SHA256,
.hmac_type = AUTH_TYPE_RESERVED,
.hw_op_hashsz = SHA256_DIGEST_SIZE,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 8/9] crypto: sha256 - Merge crypto/sha256.h into crypto/sha.h
From: Hans de Goede @ 2019-09-01 20:35 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H . Peter Anvin, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Russell King, Catalin Marinas, Will Deacon,
Gilad Ben-Yossef, Atul Gupta
Cc: linux-s390, linux-efi, Ard Biesheuvel, Marc Zyngier, x86,
linux-kernel, Eric Biggers, Hans de Goede, linux-crypto,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190901203532.2615-1-hdegoede@redhat.com>
The generic sha256 implementation from lib/crypto/sha256.c uses data
structs defined in crypto/sha.h, so lets move the function prototypes
there too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/s390/purgatory/purgatory.c | 2 +-
arch/x86/purgatory/purgatory.c | 2 +-
crypto/sha256_generic.c | 1 -
include/crypto/sha.h | 21 ++++++++++++++++++++
include/crypto/sha256.h | 34 ---------------------------------
lib/crypto/sha256.c | 2 +-
6 files changed, 24 insertions(+), 38 deletions(-)
delete mode 100644 include/crypto/sha256.h
diff --git a/arch/s390/purgatory/purgatory.c b/arch/s390/purgatory/purgatory.c
index a80c78da9985..0a423bcf6746 100644
--- a/arch/s390/purgatory/purgatory.c
+++ b/arch/s390/purgatory/purgatory.c
@@ -9,7 +9,7 @@
#include <linux/kexec.h>
#include <linux/string.h>
-#include <crypto/sha256.h>
+#include <crypto/sha.h>
#include <asm/purgatory.h>
int verify_sha256_digest(void)
diff --git a/arch/x86/purgatory/purgatory.c b/arch/x86/purgatory/purgatory.c
index 7f90a86eff49..3b95410ff0f8 100644
--- a/arch/x86/purgatory/purgatory.c
+++ b/arch/x86/purgatory/purgatory.c
@@ -9,7 +9,7 @@
*/
#include <linux/bug.h>
-#include <crypto/sha256.h>
+#include <crypto/sha.h>
#include <asm/purgatory.h>
#include "../boot/string.h"
diff --git a/crypto/sha256_generic.c b/crypto/sha256_generic.c
index eafd10f9bf86..f2d7095d4f2d 100644
--- a/crypto/sha256_generic.c
+++ b/crypto/sha256_generic.c
@@ -13,7 +13,6 @@
#include <linux/mm.h>
#include <linux/types.h>
#include <crypto/sha.h>
-#include <crypto/sha256.h>
#include <crypto/sha256_base.h>
#include <asm/byteorder.h>
#include <asm/unaligned.h>
diff --git a/include/crypto/sha.h b/include/crypto/sha.h
index 8a46202b1857..535955c84187 100644
--- a/include/crypto/sha.h
+++ b/include/crypto/sha.h
@@ -112,4 +112,25 @@ extern int crypto_sha512_update(struct shash_desc *desc, const u8 *data,
extern int crypto_sha512_finup(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *hash);
+
+/*
+ * Stand-alone implementation of the SHA256 algorithm. It is designed to
+ * have as little dependencies as possible so it can be used in the
+ * kexec_file purgatory. In other cases you should generally use the
+ * hash APIs from include/crypto/hash.h. Especially when hashing large
+ * amounts of data as those APIs may be hw-accelerated.
+ *
+ * For details see lib/crypto/sha256.c
+ */
+
+extern int sha256_init(struct sha256_state *sctx);
+extern int sha256_update(struct sha256_state *sctx, const u8 *input,
+ unsigned int length);
+extern int sha256_final(struct sha256_state *sctx, u8 *hash);
+
+extern int sha224_init(struct sha256_state *sctx);
+extern int sha224_update(struct sha256_state *sctx, const u8 *input,
+ unsigned int length);
+extern int sha224_final(struct sha256_state *sctx, u8 *hash);
+
#endif
diff --git a/include/crypto/sha256.h b/include/crypto/sha256.h
deleted file mode 100644
index a75998d65a41..000000000000
--- a/include/crypto/sha256.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) 2014 Red Hat Inc.
- *
- * Author: Vivek Goyal <vgoyal@redhat.com>
- */
-
-#ifndef SHA256_H
-#define SHA256_H
-
-#include <linux/types.h>
-#include <crypto/sha.h>
-
-/*
- * Stand-alone implementation of the SHA256 algorithm. It is designed to
- * have as little dependencies as possible so it can be used in the
- * kexec_file purgatory. In other cases you should generally use the
- * hash APIs from include/crypto/hash.h. Especially when hashing large
- * amounts of data as those APIs may be hw-accelerated.
- *
- * For details see lib/crypto/sha256.c
- */
-
-extern int sha256_init(struct sha256_state *sctx);
-extern int sha256_update(struct sha256_state *sctx, const u8 *input,
- unsigned int length);
-extern int sha256_final(struct sha256_state *sctx, u8 *hash);
-
-extern int sha224_init(struct sha256_state *sctx);
-extern int sha224_update(struct sha256_state *sctx, const u8 *input,
- unsigned int length);
-extern int sha224_final(struct sha256_state *sctx, u8 *hash);
-
-#endif /* SHA256_H */
diff --git a/lib/crypto/sha256.c b/lib/crypto/sha256.c
index 42d75e490a97..220b74c2bbd8 100644
--- a/lib/crypto/sha256.c
+++ b/lib/crypto/sha256.c
@@ -15,7 +15,7 @@
#include <linux/export.h>
#include <linux/module.h>
#include <linux/string.h>
-#include <crypto/sha256.h>
+#include <crypto/sha.h>
#include <asm/unaligned.h>
static inline u32 Ch(u32 x, u32 y, u32 z)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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