* [PATCH 01/10] arm64: add kconfig symbol to configure physical address size
From: Kristina Martsenko @ 2017-12-19 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21d0fcaf-d454-6a75-f617-22b87de0b49f@arm.com>
On 14/12/17 10:22, Suzuki K Poulose wrote:
> On 13/12/17 17:07, Kristina Martsenko wrote:
>> ARMv8.2 introduces support for 52-bit physical addresses. To prepare for
>> supporting this, add a new kconfig symbol to configure the physical
>> address space size. The symbols will be used in subsequent patches.
>> Currently the only choice is 48, a later patch will add the option of 52
>> once the required code is in place.
>>
>> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
>> ---
>> ? arch/arm64/Kconfig | 16 ++++++++++++++++
>> ? 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index a93339f5178f..8dc937823eeb 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -646,6 +646,22 @@ config ARM64_VA_BITS
>> ????? default 47 if ARM64_VA_BITS_47
>> ????? default 48 if ARM64_VA_BITS_48
>> ? +choice
>> +??? prompt "Physical address space size"
>> +??? default ARM64_PA_BITS_48
>> +??? help
>> +????? Choose the maximum physical address range that the kernel will
>> +????? support.
>> +
>> +config ARM64_PA_BITS_48
>> +??? bool "48-bit"
>> +
>> +endchoice
>> +
>> +config ARM64_PA_BITS
>> +??? int
>> +??? default 48 if ARM64_PA_BITS_48
>> +
>> ? config CPU_BIG_ENDIAN
>> ???????? bool "Build big-endian kernel"
>> ???????? help
>>
>
> We could replace most of the hard coded "48" PA limit values to ARM64_PA_BITS,
> now that we have a configurable entity. i.e, you could fold? patch 7 & 8 into
> this one.
Makes sense, I'll merge patches 7 and 8 into this one in v2.
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks!
Kristina
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Arnd Bergmann @ 2017-12-19 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45e2f530-1e72-6933-4367-95aadd709873@st.com>
On Tue, Dec 19, 2017 at 3:43 PM, Ludovic BARRE <ludovic.barre@st.com> wrote:
>
>
> On 12/18/2017 09:24 PM, Arnd Bergmann wrote:
>>
>> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com>
>> wrote:
>>>
>>> From: Ludovic Barre <ludovic.barre@st.com>
>>>
>>> This patch prepares the STM32 machine for the integration of Cortex-A
>>> based microprocessor (MPU), on top of the existing Cortex-M
>>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>>> them. If a hardware block is specific to one family we can use either
>>> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>>>
>>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>>
>>
>> Looks good overall. Two more small comments:
>>
>>
>>>
>>> +if ARCH_STM32
>>> +
>>> config MACH_STM32F429
>>> - bool "STMicrolectronics STM32F429"
>>> - depends on ARCH_STM32
>>> + bool "STMicroelectronics STM32F429"
>>> + depends on ARM_SINGLE_ARMV7M
>>> default y
>>
>>
>> Instead of the explicit dependency for each board, I'd leave the
>> surrounding
>> 'if ARM_SINGLE_ARMV7M'. I think you had in v1.
>
>
> As you suggest, I follow mach-at91 example.
> The point is on "depends on ARM_SINGLE_ARMV7M" ?
> You prefer this way:
> config MACH_STM32F429
> bool "STMicroelectronics STM32F429" if ARM_SINGLE_ARMV7M
> default y
>
No, that would be wrong, that way you would always enable
MACH_STM32F429 when ARM_SINGLE_ARMV7M is turned
off, which is exactly the wrong way round. What I meant is
if ARCH_STM32
if ARM_SINGLE_ARMV7M
config MACH_STM32F429
bool "STMicrolectronics STM32F429"
config MACH_STM32...
...
endif # ARMv7-M
if ARCH_MULTI_V7
config MACH_STM32...
...
endif # ARMv7-A
endif # STM32
Arnd
^ permalink raw reply
* [PATCH 8/8] ARM: dts: am572x-idk: Add cpu0 vdd supply
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add vdd-supply as smps12_reg for cpu0.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/am572x-idk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index a578fe97ba3b..d0daf48346ab 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -127,3 +127,7 @@
status = "okay";
};
};
+
+&cpu0 {
+ vdd-supply = <&smps12_reg>;
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 7/8] ARM: dts: am571x-idk: Add cpu0 vdd supply
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add vdd-supply as smps12_reg for cpu0.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/am571x-idk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index debf9464403e..6d3c83743156 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -117,3 +117,7 @@
pinctrl-1 = <&mmc2_pins_hs>;
pinctrl-2 = <&mmc2_pins_ddr_rev20 &mmc2_iodelay_ddr_conf>;
};
+
+&cpu0 {
+ vdd-supply = <&smps12_reg>;
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 6/8] ARM: dts: dra72-evm-tps65917: Add cpu0 vdd supply
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add vdd-supply as smps12_reg for cpu0.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
index 57bfe5caf5e4..47bb90f41f3f 100644
--- a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
@@ -148,3 +148,7 @@
&mmc1 {
vqmmc-supply = <&ldo1_reg>;
};
+
+&cpu0 {
+ vdd-supply = <&smps1_reg>;
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 5/8] ARM: dts: dra7-evm: Add cpu0 vdd supply
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add vdd-supply as smps123_reg for cpu0.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/dra7-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index ef9c90daa74b..a7385c338ee9 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -361,7 +361,7 @@
};
&cpu0 {
- cpu0-supply = <&smps123_reg>;
+ vdd-supply = <&smps123_reg>;
};
&omap_dwc3_2 {
--
2.15.1
^ permalink raw reply related
* [PATCH 4/8] ARM: dts: am57xx-beagle-x15-common: Add cpu0 vdd supply
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add vdd-supply as smps12_reg for cpu0.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 49aeecd312b4..441c25677679 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -388,7 +388,7 @@
};
&cpu0 {
- cpu0-supply = <&smps12_reg>;
+ vdd-supply = <&smps12_reg>;
voltage-tolerance = <1>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH 3/8] ARM: dts: dra7: Enable 1.5 GHz operation for the CPU
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
After ti-opp-supply driver is in place to provide AVS Class0 and abb
regulator scaling support let's enable 1.5GHz for the cpu.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 33004e7f1ee9..eb68da74f777 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -116,6 +116,13 @@
opp-supported-hw = <0xFF 0x02>;
};
+
+ opp_high at 1500000000 {
+ opp-hz = /bits/ 64 <1500000000>;
+ opp-microvolt = <1210000 950000 1250000>,
+ <1210000 950000 1250000>;
+ opp-supported-hw = <0xFF 0x04>;
+ };
};
/*
--
2.15.1
^ permalink raw reply related
* [PATCH 2/8] ARM: dts: dra7: Add MPU OPP supply node
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add the OPP supply node for the MPU voltage rail to provide the
information needed by the ti-opp-supply driver to enable AVS Class 0.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d9f60144793b..33004e7f1ee9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -2057,6 +2057,19 @@
clocks = <&l3_iclk_div>;
clock-names = "fck";
};
+
+ opp_supply_mpu: opp-supply at 4a003b20 {
+ compatible = "ti,omap5-opp-supply";
+ reg = <0x4a003b20 0xc>;
+ ti,efuse-settings = <
+ /* uV offset */
+ 1060000 0x0
+ 1160000 0x4
+ 1210000 0x8
+ >;
+ ti,absolute-max-voltage-uv = <1500000>;
+ };
+
};
thermal_zones: thermal-zones {
--
2.15.1
^ permalink raw reply related
* [PATCH 1/8] ARM: dts: dra7: Add vbb-supply to cpu and additional voltages
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513697066-27732-1-git-send-email-d-gerlach@ti.com>
Add a vbb-supply phandle to the cpus node and also add an additional
triplet of voltages for each OPP in the operating-points-v2 table to
make use of the multi regulator support in the OPP core and provide the
vbb regulator for use by the ti-opp-supply driver.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ac9216293b7c..d9f60144793b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -92,6 +92,8 @@
cooling-min-level = <0>;
cooling-max-level = <2>;
#cooling-cells = <2>; /* min followed by max */
+
+ vbb-supply = <&abb_mpu>;
};
};
@@ -101,14 +103,17 @@
opp_nom-1000000000 {
opp-hz = /bits/ 64 <1000000000>;
- opp-microvolt = <1060000 850000 1150000>;
+ opp-microvolt = <1060000 850000 1150000>,
+ <1060000 850000 1150000>;
opp-supported-hw = <0xFF 0x01>;
opp-suspend;
};
opp_od-1176000000 {
opp-hz = /bits/ 64 <1176000000>;
- opp-microvolt = <1160000 885000 1160000>;
+ opp-microvolt = <1160000 885000 1160000>,
+ <1160000 885000 1160000>;
+
opp-supported-hw = <0xFF 0x02>;
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH 0/8] ARM: dts: dra7: Add ti-opp-supply nodes and enable 1.5 GHz
From: Dave Gerlach @ 2017-12-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series adds the additional regulators and ti-opp-supply nodes to enable
ABB regulator scaling and AVS Class0 for dra7 and am57 platforms. In addition
to this the 1.5 GHz OPP is enabled for any platforms in the dra7 and am57
family that support it based on the detection done by the ti-cpufreq driver.
Regards,
Dave
Dave Gerlach (8):
ARM: dts: dra7: Add vbb-supply to cpu and additional voltages
ARM: dts: dra7: Add MPU OPP supply node
ARM: dts: dra7: Enable 1.5 GHz operation for the CPU
ARM: dts: am57xx-beagle-x15-common: Add cpu0 vdd supply
ARM: dts: dra7-evm: Add cpu0 vdd supply
ARM: dts: dra72-evm-tps65917: Add cpu0 vdd supply
ARM: dts: am571x-idk: Add cpu0 vdd supply
ARM: dts: am572x-idk: Add cpu0 vdd supply
arch/arm/boot/dts/am571x-idk.dts | 4 ++++
arch/arm/boot/dts/am572x-idk.dts | 4 ++++
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra7.dtsi | 29 +++++++++++++++++++++++--
arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 4 ++++
6 files changed, 41 insertions(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Ladislav Michl @ 2017-12-19 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a62814d7-f2d4-8740-92f5-114992ef5db1@ti.com>
On Tue, Dec 19, 2017 at 01:55:48PM +0530, Keerthy wrote:
> On Tuesday 19 December 2017 10:28 AM, Keerthy wrote:
> > On Monday 18 December 2017 06:25 PM, Keerthy wrote:
> >> On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:
> >>> Keerthy,
> >>>
> >>> On Tue, Dec 12, 2017 at 11:42:16AM +0530, Keerthy wrote:
> >>>> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
> >>>>
> >>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
> >>>> ---
> >>>>
> >>>> Changes in v4:
> >>>>
> >>>> * Switched to dev_get_platdata.
> >>>
> >>> Where do you expect dev.platform_data to be set? PWM driver is failing
> >>> with:
> >>> omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >>> omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> >>>
> >>> Which I fixed with patch bellow, to be able to test your patchset.
> >>
> >> Thanks! I will make the below patch part of my series.
> >>
> >>>
> >>> Also I'm running a bit out of time, so I'll send few clean up
> >>> patches and event capture code to get some feedback early.
> >>>
> >>> Regards,
> >>> ladis
> >>>
> >>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> >>> index 39be39e6a8dd..d3d8a49cae0d 100644
> >>> --- a/drivers/clocksource/timer-dm.c
> >>> +++ b/drivers/clocksource/timer-dm.c
> >>> @@ -773,6 +773,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
> >>> dev_err(dev, "%s: no platform data.\n", __func__);
> >>> return -ENODEV;
> >>> }
> >>> + dev->platform_data = pdata;
> >
> > drivers/clocksource/timer-dm.c: In function 'omap_dm_timer_probe':
> > drivers/clocksource/timer-dm.c:744:21: warning: assignment discards
> > 'const' qualifier from pointer target type
> >
> > This cannot be done as we are assigning a const pointer to a non-const
> > pointer.
Oh, I didn't even assume it as proper fix, just to show what is missing :)
But technically 'struct dmtimer_platform_data *pdata' is a constant which
should not be changed. Also look how all that of_populate chain works -
at the end const pointer is assigned to void* platform_data by simple
(void *) overcast.
> > I will figure out a different way for this fix.
>
> Ladis,
>
> I fixed that:
>
> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> index 1cbd954..e58f555 100644
> --- a/drivers/clocksource/timer-dm.c
> +++ b/drivers/clocksource/timer-dm.c
> @@ -807,17 +807,21 @@ static int omap_dm_timer_probe(struct
> platform_device *pdev)
> struct resource *mem, *irq;
> struct device *dev = &pdev->dev;
> const struct of_device_id *match;
> - const struct dmtimer_platform_data *pdata;
> + struct dmtimer_platform_data *pdata;
> int ret;
>
> match = of_match_device(of_match_ptr(omap_timer_match), dev);
> - pdata = match ? match->data : dev->platform_data;
> + pdata = match ? (struct dmtimer_platform_data *)match->data :
> + dev->platform_data;
All that seems needlesly complicated, what about patch bellow?
> if (!pdata && !dev->of_node) {
> dev_err(dev, "%s: no platform data.\n", __func__);
> return -ENODEV;
> }
>
> + if (!dev->platform_data)
> + dev->platform_data = pdata;
Does the above condition bring us anything?
> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (unlikely(!irq)) {
> dev_err(dev, "%s: no IRQ resource.\n", __func__);
> @@ -946,7 +950,7 @@ static int omap_dm_timer_remove(struct
> platform_device *pdev)
> .write_status = omap_dm_timer_write_status,
> };
>
> -static const struct dmtimer_platform_data omap3plus_pdata = {
> +static struct dmtimer_platform_data omap3plus_pdata = {
> .timer_errata = OMAP_TIMER_ERRATA_I103_I767,
> .timer_ops = &dmtimer_ops,
> };
>
> Can you check at your end if this works for you?
Note, it is untested as I ran out of time and will continue after New Year.
diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index 1cbd95420914..85024f11773a 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -806,14 +806,16 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
struct omap_dm_timer *timer;
struct resource *mem, *irq;
struct device *dev = &pdev->dev;
- const struct of_device_id *match;
const struct dmtimer_platform_data *pdata;
int ret;
- match = of_match_device(of_match_ptr(omap_timer_match), dev);
- pdata = match ? match->data : dev->platform_data;
+ pdata = of_device_get_match_data(dev);
+ if (!pdata)
+ pdata = dev_get_platdata(dev);
+ else
+ dev->platform_data = (void *) pdata;
- if (!pdata && !dev->of_node) {
+ if (!pdata) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
^ permalink raw reply related
* [PATCH v4] staging: fsl-mc: move bus driver out of staging
From: Laurentiu Tudor @ 2017-12-19 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219144802.GA4534@kroah.com>
On 12/19/2017 04:48 PM, Greg KH wrote:
> On Wed, Nov 29, 2017 at 12:08:44PM +0200, laurentiu.tudor at nxp.com wrote:
>> From: Stuart Yoder <stuart.yoder@nxp.com>
>>
>> Move the source files out of staging into their final locations:
>> -include files in drivers/staging/fsl-mc/include go to include/linux/fsl
>> -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
>> -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
>> -README.txt, providing and overview of DPAA goes to
>> Documentation/dpaa2/overview.txt
>>
>> Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
>> Update dpaa2_eth and dpio staging drivers.
>>
>> Signed-off-by: Stuart Yoder <stuyoder@gmail.com>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> [Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> Notes:
>> -v4:
>> - regenerated patch with renames detection disabled (Andrew Lunn)
>> -v3:
>> - rebased
>
> Ok, meta-comments on the structure of the code.
>
> You have 8 .h files that are "private" to your bus logic. That's 7 too
> many, some of them have a bigger license header than actual content :)
>
> Please consolidate into 1.
>
> Also, the headers should be moved to SPDX format to get rid of the
> boilerplate. I _think_ it's BSD/GPL, right? Hard to tell :(
It's 3-clause BSD and GPLv2. Will make it clear when moving to SPDX.
>
> Your "public" .h file does not need to go into a subdirectory, just name
> it fsl-mc.h and put it in include/linux/.
There's already a "fsl" subdirectory in include/linux/ so it seemed to
make sense to use it.
> One comment on the fields in your .h file, all of the user/kernel
> crossing boundry structures need to use the "__" variant of types, like
> "__u8" and the like. You mix and match them for some reason, you need
> to be consistent.
>
> Also, what's up with the .h files in drivers/staging/fsl-bus/include?
> You didn't touch those with this movement, right? Why?
Those are not part of the bus "core". Some of them are part of the DPBP
and DPCON device types APIs and are used by drivers probing on this bus
and the rest are part of the DPIO driver which is also used by other
drivers. Since these devices (DPBP, DPCON, DPIO) are interfaces used by
all the other drivers it made sense to group them together with the bus.
> For this initial move, only move the bus "core" code out, not the other
> stuff like:
>
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 119 +++
>
> these should be a separate file move, right?
This bus uses msi interrupts and this file contains glue code needed to
enable interrupts in the GICv3 irqchip. Without this I don't think the
bus driver can work because itself makes use of interrupts.
>> drivers/staging/fsl-dpaa2/ethernet/README | 2 +-
>
> Why does a README file for a different driver need to be touched?
It mentions a file in the old location of the bus. This is how the diff
looks:
- drivers/staging/fsl-mc/README.txt
+ Documentation/dpaa2/overview.txt
>> drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 +-
>> drivers/staging/fsl-dpaa2/ethernet/dpni.c | 2 +-
>> drivers/staging/fsl-mc/README.txt | 386 ---------
>
> This file gets moved to the Documentation directory, yet it is not tied
> into the documentation build process, that's not good.
Will look into that.
> It doesn't need to have a separate directory either, right?
Agreed, maybe the destination directory isn't the best choice. Maybe
bus-devices/fsl-mc.txt makes more sense? Can you please suggest?
> And speaking of documentation, you have directories in sysfs, yet no
> Documentation/ABI/ files describing them. Please fix that up.
Hmm, I was under the impression that we did have sysfs documentation.
Will look into it.
> that's a good start :)
Yep. :)
---
Thanks & Best Regards, Laurentiu
^ permalink raw reply
* [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API
From: Rob Clark @ 2017-12-19 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170908171830.13813-2-georgi.djakov@linaro.org>
On Fri, Sep 8, 2017 at 1:18 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> This patch introduce a new API to get requirements and configure the
> interconnect buses across the entire chipset to fit with the current demand.
>
> The API is using a consumer/provider-based model, where the providers are
> the interconnect buses and the consumers could be various drivers.
> The consumers request interconnect resources (path) between endpoints and
> set the desired constraints on this data flow path. The providers receive
> requests from consumers and aggregate these requests for all master-slave
> pairs on that path. Then the providers configure each participating in the
> topology node according to the requested data flow path, physical links and
> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> Documentation/interconnect/interconnect.rst | 93 +++++++
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/interconnect/Kconfig | 10 +
> drivers/interconnect/Makefile | 1 +
> drivers/interconnect/interconnect.c | 382 ++++++++++++++++++++++++++++
> include/linux/interconnect-consumer.h | 73 ++++++
> include/linux/interconnect-provider.h | 119 +++++++++
> 8 files changed, 681 insertions(+)
> create mode 100644 Documentation/interconnect/interconnect.rst
> create mode 100644 drivers/interconnect/Kconfig
> create mode 100644 drivers/interconnect/Makefile
> create mode 100644 drivers/interconnect/interconnect.c
> create mode 100644 include/linux/interconnect-consumer.h
> create mode 100644 include/linux/interconnect-provider.h
>
>
[snip]
> +/**
> + * interconnect_set() - set constraints on a path between two endpoints
> + * @path: reference to the path returned by interconnect_get()
> + * @creq: request from the consumer, containing its requirements
> + *
> + * This function is used by an interconnect consumer to express its own needs
> + * in term of bandwidth and QoS for a previously requested path between two
> + * endpoints. The requests are aggregated and each node is updated accordingly.
> + *
> + * Returns 0 on success, or an approproate error code otherwise.
> + */
> +int interconnect_set(struct interconnect_path *path,
> + struct interconnect_creq *creq)
drive-by comment... afaict creq could be 'const'
BR,
-R
^ permalink raw reply
* [PATCH V1 1/1] iommu: Make sure device's ID array elements are unique
From: Tomasz Nowicki @ 2017-12-19 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513696436-31834-1-git-send-email-tomasz.nowicki@caviumnetworks.com>
While iterating over DMA aliases for a PCI device, for some rare cases
(i.e. PCIe-to-PCI/X bridges) we may get exactly the same ID as initial child
device. In turn, the same ID may get registered for a device multiple times.
Eventually IOMMU driver may try to configure the same ID within domain
multiple times too which for some IOMMU drivers is illegal and causes kernel
panic.
Rule out ID duplication prior to device ID array registration.
CC: stable at vger.kernel.org # v4.14+
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
---
drivers/iommu/iommu.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3de5c0b..9b2c138 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1945,6 +1945,31 @@ void iommu_fwspec_free(struct device *dev)
}
EXPORT_SYMBOL_GPL(iommu_fwspec_free);
+static void iommu_fwspec_remove_ids_dup(struct device *dev, u32 *ids,
+ int *num_ids)
+{
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ int i, j, k, valid_ids = *num_ids;
+
+ for (i = 0; i < valid_ids; i++) {
+ for (j = 0; j < fwspec->num_ids; j++) {
+ if (ids[i] != fwspec->ids[j])
+ continue;
+
+ dev_info(dev, "found 0x%x ID duplication, skipped\n",
+ ids[i]);
+
+ for (k = i + 1; k < valid_ids; k++)
+ ids[k - 1] = ids[k];
+
+ valid_ids--;
+ break;
+ }
+ }
+
+ *num_ids = valid_ids;
+}
+
int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
{
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
@@ -1954,6 +1979,9 @@ int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
if (!fwspec)
return -EINVAL;
+ /* Rule out IDs already registered */
+ iommu_fwspec_remove_ids_dup(dev, ids, &num_ids);
+
size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
if (size > sizeof(*fwspec)) {
fwspec = krealloc(dev->iommu_fwspec, size, GFP_KERNEL);
--
2.7.4
^ permalink raw reply related
* [PATCH v3] spi: atmel: Implements transfers with bounce buffer
From: Radu Pirea @ 2017-12-19 15:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables SPI DMA transfers for Atmel SAM9 SoCs and implements a
bounce buffer for transfers which have vmalloc allocated buffers. Those
buffers are not cache coherent even if they have been transformed into sg
lists. UBIFS is affected by this cache coherency issue.
In this patch I also reverted "spi: atmel: fix corrupted data issue on SAM9
family SoCs"(7094576ccdc3acfe1e06a1e2ab547add375baf7f).
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
Changes v3:
-rebased on top of spi: atmel: fixed spin_lock usage inside atmel_spi_remove
-rerun checkpatch.pl and fix errors
Changes v2:
Please ignore the previous version. I messed up with file names.
drivers/spi/spi-atmel.c | 113 +++++++++++++++++++++++++++++++++++-------------
1 file changed, 84 insertions(+), 29 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 6694709..4a11fc0 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -291,6 +291,10 @@ struct atmel_spi {
struct spi_transfer *current_transfer;
int current_remaining_bytes;
int done_status;
+ dma_addr_t dma_addr_rx_bbuf;
+ dma_addr_t dma_addr_tx_bbuf;
+ void *addr_rx_bbuf;
+ void *addr_tx_bbuf;
struct completion xfer_completion;
@@ -436,6 +440,11 @@ static void atmel_spi_unlock(struct atmel_spi *as) __releases(&as->lock)
spin_unlock_irqrestore(&as->lock, as->flags);
}
+static inline bool atmel_spi_is_vmalloc_xfer(struct spi_transfer *xfer)
+{
+ return is_vmalloc_addr(xfer->tx_buf) || is_vmalloc_addr(xfer->rx_buf);
+}
+
static inline bool atmel_spi_use_dma(struct atmel_spi *as,
struct spi_transfer *xfer)
{
@@ -448,7 +457,12 @@ static bool atmel_spi_can_dma(struct spi_master *master,
{
struct atmel_spi *as = spi_master_get_devdata(master);
- return atmel_spi_use_dma(as, xfer);
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5))
+ return atmel_spi_use_dma(as, xfer) &&
+ !atmel_spi_is_vmalloc_xfer(xfer);
+ else
+ return atmel_spi_use_dma(as, xfer);
+
}
static int atmel_spi_dma_slave_config(struct atmel_spi *as,
@@ -594,6 +608,11 @@ static void dma_callback(void *data)
struct spi_master *master = data;
struct atmel_spi *as = spi_master_get_devdata(master);
+ if (is_vmalloc_addr(as->current_transfer->rx_buf) &&
+ IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ memcpy(as->current_transfer->rx_buf, as->addr_rx_bbuf,
+ as->current_transfer->len);
+ }
complete(&as->xfer_completion);
}
@@ -744,17 +763,41 @@ static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
goto err_exit;
/* Send both scatterlists */
- rxdesc = dmaengine_prep_slave_sg(rxchan,
- xfer->rx_sg.sgl, xfer->rx_sg.nents,
- DMA_FROM_DEVICE,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (atmel_spi_is_vmalloc_xfer(xfer) &&
+ IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ rxdesc = dmaengine_prep_slave_single(rxchan,
+ as->dma_addr_rx_bbuf,
+ xfer->len,
+ DMA_FROM_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ } else {
+ rxdesc = dmaengine_prep_slave_sg(rxchan,
+ xfer->rx_sg.sgl,
+ xfer->rx_sg.nents,
+ DMA_FROM_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ }
if (!rxdesc)
goto err_dma;
- txdesc = dmaengine_prep_slave_sg(txchan,
- xfer->tx_sg.sgl, xfer->tx_sg.nents,
- DMA_TO_DEVICE,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (atmel_spi_is_vmalloc_xfer(xfer) &&
+ IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ memcpy(as->addr_tx_bbuf, xfer->tx_buf, xfer->len);
+ txdesc = dmaengine_prep_slave_single(txchan,
+ as->dma_addr_tx_bbuf,
+ xfer->len, DMA_TO_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ } else {
+ txdesc = dmaengine_prep_slave_sg(txchan,
+ xfer->tx_sg.sgl,
+ xfer->tx_sg.nents,
+ DMA_TO_DEVICE,
+ DMA_PREP_INTERRUPT |
+ DMA_CTRL_ACK);
+ }
if (!txdesc)
goto err_dma;
@@ -1426,27 +1469,7 @@ static void atmel_get_caps(struct atmel_spi *as)
as->caps.is_spi2 = version > 0x121;
as->caps.has_wdrbt = version >= 0x210;
-#ifdef CONFIG_SOC_SAM_V4_V5
- /*
- * Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf()
- * since this later function tries to map buffers with dma_map_sg()
- * even if they have not been allocated inside DMA-safe areas.
- * On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for
- * those ARM cores, the data cache follows the PIPT model.
- * Also the L2 cache controller of SAMA5D2 uses the PIPT model too.
- * In case of PIPT caches, there cannot be cache aliases.
- * However on ARM9 cores, the data cache follows the VIVT model, hence
- * the cache aliases issue can occur when buffers are allocated from
- * DMA-unsafe areas, by vmalloc() for instance, where cache coherency is
- * not taken into account or at least not handled completely (cache
- * lines of aliases are not invalidated).
- * This is not a theorical issue: it was reproduced when trying to mount
- * a UBI file-system on a at91sam9g35ek board.
- */
- as->caps.has_dma_support = false;
-#else
as->caps.has_dma_support = version >= 0x212;
-#endif
as->caps.has_pdc_support = version < 0x212;
}
@@ -1592,6 +1615,30 @@ static int atmel_spi_probe(struct platform_device *pdev)
as->use_pdc = true;
}
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ as->addr_rx_bbuf = dma_alloc_coherent(&pdev->dev,
+ SPI_MAX_DMA_XFER,
+ &as->dma_addr_rx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_rx_bbuf) {
+ as->use_dma = false;
+ } else {
+ as->addr_tx_bbuf = dma_alloc_coherent(&pdev->dev,
+ SPI_MAX_DMA_XFER,
+ &as->dma_addr_tx_bbuf,
+ GFP_KERNEL | GFP_DMA);
+ if (!as->addr_tx_bbuf) {
+ as->use_dma = false;
+ dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
+ as->addr_rx_bbuf,
+ as->dma_addr_rx_bbuf);
+ }
+ }
+ if (!as->use_dma)
+ dev_info(master->dev.parent,
+ " can not allocate dma coherent memory\n");
+ }
+
if (as->caps.has_dma_support && !as->use_dma)
dev_info(&pdev->dev, "Atmel SPI Controller using PIO only\n");
@@ -1664,6 +1711,14 @@ static int atmel_spi_remove(struct platform_device *pdev)
if (as->use_dma) {
atmel_spi_stop_dma(master);
atmel_spi_release_dma(master);
+ if (IS_ENABLED(CONFIG_SOC_SAM_V4_V5)) {
+ dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
+ as->addr_tx_bbuf,
+ as->dma_addr_tx_bbuf);
+ dma_free_coherent(&pdev->dev, SPI_MAX_DMA_XFER,
+ as->addr_rx_bbuf,
+ as->dma_addr_rx_bbuf);
+ }
}
spin_lock_irq(&as->lock);
--
2.7.4
^ permalink raw reply related
* [PATCH V1 0/1] Fix kernel panic caused by device ID duplication presented to the IOMMU
From: Tomasz Nowicki @ 2017-12-19 15:13 UTC (permalink / raw)
To: linux-arm-kernel
Here is my lspci output of ThunderX2 for which I am observing kernel panic coming from
SMMUv3 driver -> arm_smmu_write_strtab_ent() -> BUG_ON(ste_live):
# lspci -vt
-[0000:00]-+-00.0-[01-1f]--+ [...]
+ [...]
\-00.0-[1e-1f]----00.0-[1f]----00.0 ASPEED Technology, Inc. ASPEED Graphics Family
ASP device -> 1f:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family
PCI-Express to PCI/PCI-X Bridge -> 1e:00.0 PCI bridge: ASPEED Technology, Inc. AST1150 PCI-to-PCI Bridge
While setting up ASP device SID in IORT dirver:
iort_iommu_configure() -> pci_for_each_dma_alias()
we need to walk up and iterate over each device which alias transaction from
downstream devices.
AST device (1f:00.0) gets BDF=0x1f00 and corresponding SID=0x1f00 from IORT.
Bridge (1e:00.0) is the first alias. Following PCI Express to PCI/PCI-X Bridge
spec: PCIe-to-PCI/X bridges alias transactions from downstream devices using
the subordinate bus number. For bridge (1e:00.0), the subordinate is equal
to 0x1f. This gives BDF=0x1f00 and SID=1f00 which is the same as downstream
device. So it is possible to have two identical SIDs. The question is what we
should do about such case. Presented patch prevents from registering the same
ID so that SMMUv3 is not complaining later on.
Tomasz Nowicki (1):
iommu: Make sure device's ID array elements are unique
drivers/iommu/iommu.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH] ARM: imx: remove unused imx3 pm definitions
From: Fabio Estevam @ 2017-12-19 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513678024-2779-1-git-send-email-martin@kaiser.cx>
On Tue, Dec 19, 2017 at 8:07 AM, Martin Kaiser <martin@kaiser.cx> wrote:
> Remove the defintion of mx3_cpu_lp_set(), this function is not
> implemented anywhere. Remove then mx3_cpu_pwr_mode enum as well,
> it was used only as parameter of mx3_cpu_lp_set().
>
> Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH V4 14/26] pch_gbe: deprecate pci_get_bus_and_slot()
From: David Miller @ 2017-12-19 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef7d09ce-06af-ad3e-1048-3b413cc32e9b@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Tue, 19 Dec 2017 07:17:41 -0500
> Then hard code the domain number as 0 while calling
> pci_get_domain_bus_and_slot() if you know for sure that this device
> will never work on a non-zero domain.
Agreed, it's so much better to be explicit about this.
^ permalink raw reply
* [PATCH] pwm: atmel-tcb: Delete an error message for a failed memory allocation in atmel_tcb_pwm_probe()
From: Nicolas Ferre @ 2017-12-19 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8274c498-1d1b-2ece-365c-98ded714a53c@users.sourceforge.net>
Hi,
On 15/12/2017 at 19:00, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 15 Dec 2017 18:55:11 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
Can you point which coccinelle script highlited this issue?
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/pwm/pwm-atmel-tcb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
> index acd3ce8ecf3f..4fb1be246c44 100644
> --- a/drivers/pwm/pwm-atmel-tcb.c
> +++ b/drivers/pwm/pwm-atmel-tcb.c
> @@ -401,7 +401,6 @@ static int atmel_tcb_pwm_probe(struct platform_device *pdev)
> tcbpwm = devm_kzalloc(&pdev->dev, sizeof(*tcbpwm), GFP_KERNEL);
> if (tcbpwm == NULL) {
> err = -ENOMEM;
> - dev_err(&pdev->dev, "failed to allocate memory\n");
We have this in case of error:
atmel-tcb-pwm pwm: failed to allocate memory
atmel-tcb-pwm: probe of pwm failed with error -12
Which is somehow redundant I admit...
> goto err_free_tc;
> }
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v1] mfd: ab8500: introduce DEFINE_SHOW_ATTRIBUTE() macro
From: Andy Shevchenko @ 2017-12-19 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215105432.pm36mtles7mpvcye@dell>
On Fri, 2017-12-15 at 10:54 +0000, Lee Jones wrote:
> Linus,
>
I suppose you would like to get his attention :-)
> > This macro deduplicates a lot of similar code in the ab8500-
> > debugfs.c module.
> > Targeting to be moved to seq_file.h eventually.
> >
Linus, it would be nice to have this in three for this cycle that will
allow me to move it to seq_file.h in the next one.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v4] staging: fsl-mc: move bus driver out of staging
From: Greg KH @ 2017-12-19 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129100844.19874-1-laurentiu.tudor@nxp.com>
On Wed, Nov 29, 2017 at 12:08:44PM +0200, laurentiu.tudor at nxp.com wrote:
> From: Stuart Yoder <stuart.yoder@nxp.com>
>
> Move the source files out of staging into their final locations:
> -include files in drivers/staging/fsl-mc/include go to include/linux/fsl
> -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
> -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
> -README.txt, providing and overview of DPAA goes to
> Documentation/dpaa2/overview.txt
>
> Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
> Update dpaa2_eth and dpio staging drivers.
>
> Signed-off-by: Stuart Yoder <stuyoder@gmail.com>
> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> [Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Notes:
> -v4:
> - regenerated patch with renames detection disabled (Andrew Lunn)
> -v3:
> - rebased
Ok, meta-comments on the structure of the code.
You have 8 .h files that are "private" to your bus logic. That's 7 too
many, some of them have a bigger license header than actual content :)
Please consolidate into 1.
Also, the headers should be moved to SPDX format to get rid of the
boilerplate. I _think_ it's BSD/GPL, right? Hard to tell :(
Your "public" .h file does not need to go into a subdirectory, just name
it fsl-mc.h and put it in include/linux/.
One comment on the fields in your .h file, all of the user/kernel
crossing boundry structures need to use the "__" variant of types, like
"__u8" and the like. You mix and match them for some reason, you need
to be consistent.
Also, what's up with the .h files in drivers/staging/fsl-bus/include?
You didn't touch those with this movement, right? Why?
For this initial move, only move the bus "core" code out, not the other
stuff like:
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 119 +++
these should be a separate file move, right?
> drivers/staging/fsl-dpaa2/ethernet/README | 2 +-
Why does a README file for a different driver need to be touched?
> drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 2 +-
> drivers/staging/fsl-dpaa2/ethernet/dpni.c | 2 +-
> drivers/staging/fsl-mc/README.txt | 386 ---------
This file gets moved to the Documentation directory, yet it is not tied
into the documentation build process, that's not good. It doesn't need
to have a separate directory either, right?
And speaking of documentation, you have directories in sysfs, yet no
Documentation/ABI/ files describing them. Please fix that up.
that's a good start :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: Vladimir Murzin @ 2017-12-19 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219112954.GA14910@afzalpc>
Hi,
On 19/12/17 11:29, afzal mohammed wrote:
> Hi,
>
> On Tue, Dec 19, 2017 at 10:23:49AM +0000, Vladimir Murzin wrote:
>> With switch to dynamic exception base address setting, VBAR/Hivecs
>> set only for boot CPU, but secondaries stay unaware of that. That
>> might lead to weird effects when trying up to bring up secondaries.
>>
>> Fixes: ad475117d201 ("ARM: 8649/2: nommu: remove Hivecs configuration is asm")
>
> Sorry, it was my incompetence not seeing the secondary CPU's case.
>
> Was the issue observed on Cortex-R ?, and was it occuring with
> CONFIG_CPU_HIGH_VECTOR enabled or disabled ?
I caught it when was trying to setup VBAR and after code inspection I
noticed that setting of Hivecs were changed as well.
>
> Instead of,
>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>
>> +#ifndef CONFIG_MMU
>> +extern unsigned long setup_vectors_base(void);
>> +#else
>> +static inline unsigned long setup_vectors_base(void)
>> +{
>> + return 0;
>> +}
>> +#endif
>
>> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
>
>> + setup_vectors_base();
>
> how about,
>
> if (!IS_ENABLED(CONFIG_MMU))
> setup_vectors_base();
>
> That would avoid #ifdef's. Also as w/ MMU, vector base is not setup
> (always Hivecs), this would make clear that setup_vectors_base() is
> non-existent on MMU on.
Works for me, but I went with plain #ifndef.
Vladimir
>
> Thanks for the fix.
>
> afzal
>
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Ludovic BARRE @ 2017-12-19 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1WzkVQ3591XjVQPLCqP0_zZ4ksqJqWvm7de_OnkE3oaQ@mail.gmail.com>
On 12/18/2017 09:24 PM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> This patch prepares the STM32 machine for the integration of Cortex-A
>> based microprocessor (MPU), on top of the existing Cortex-M
>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>> them. If a hardware block is specific to one family we can use either
>> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>
> Looks good overall. Two more small comments:
>
>
>>
>> +if ARCH_STM32
>> +
>> config MACH_STM32F429
>> - bool "STMicrolectronics STM32F429"
>> - depends on ARCH_STM32
>> + bool "STMicroelectronics STM32F429"
>> + depends on ARM_SINGLE_ARMV7M
>> default y
>
> Instead of the explicit dependency for each board, I'd leave the surrounding
> 'if ARM_SINGLE_ARMV7M'. I think you had in v1.
As you suggest, I follow mach-at91 example.
The point is on "depends on ARM_SINGLE_ARMV7M" ?
You prefer this way:
config MACH_STM32F429
bool "STMicroelectronics STM32F429" if ARM_SINGLE_ARMV7M
default y
BR
Ludo
>
>> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
>> index bd0b7b5..5940af1 100644
>> --- a/arch/arm/mach-stm32/Makefile
>> +++ b/arch/arm/mach-stm32/Makefile
>> @@ -1 +1 @@
>> -obj-y += board-dt.o
>> +obj-$(CONFIG_ARM_SINGLE_ARMV7M) += board-mcu-dt.o
>> diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-mcu-dt.c
>> similarity index 100%
>> rename from arch/arm/mach-stm32/board-dt.c
>> rename to arch/arm/mach-stm32/board-mcu-dt.c
>
> Why the rename? I don't expect the new machines to have any notable
> contents in a board file, if any at all, so just use one file for both.
> I see the board-dt.c file refers to armv7m_restart, we can either put
> that in an #ifdef, or find a way to make it the default for all armv7-m
> platforms that don't provide any other restart method.
>
> Arnd
>
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Alexandre Torgue @ 2017-12-19 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1WzkVQ3591XjVQPLCqP0_zZ4ksqJqWvm7de_OnkE3oaQ@mail.gmail.com>
On 12/18/2017 09:24 PM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> This patch prepares the STM32 machine for the integration of Cortex-A
>> based microprocessor (MPU), on top of the existing Cortex-M
>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>> them. If a hardware block is specific to one family we can use either
>> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>>
>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>
> Looks good overall. Two more small comments:
>
>
>>
>> +if ARCH_STM32
>> +
>> config MACH_STM32F429
>> - bool "STMicrolectronics STM32F429"
>> - depends on ARCH_STM32
>> + bool "STMicroelectronics STM32F429"
>> + depends on ARM_SINGLE_ARMV7M
>> default y
>
> Instead of the explicit dependency for each board, I'd leave the surrounding
> 'if ARM_SINGLE_ARMV7M'. I think you had in v1.
>
>> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
>> index bd0b7b5..5940af1 100644
>> --- a/arch/arm/mach-stm32/Makefile
>> +++ b/arch/arm/mach-stm32/Makefile
>> @@ -1 +1 @@
>> -obj-y += board-dt.o
>> +obj-$(CONFIG_ARM_SINGLE_ARMV7M) += board-mcu-dt.o
>> diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-mcu-dt.c
>> similarity index 100%
>> rename from arch/arm/mach-stm32/board-dt.c
>> rename to arch/arm/mach-stm32/board-mcu-dt.c
>
> Why the rename? I don't expect the new machines to have any notable
> contents in a board file, if any at all, so just use one file for both.
> I see the board-dt.c file refers to armv7m_restart, we can either put
> that in an #ifdef, or find a way to make it the default for all armv7-m
> platforms that don't provide any other restart method.
>
Currently "restart" is not functional on stm32 MCU (at least for
stm32f746, I will check on others MCU). My fear is if Ludovic made some
patches to make "armv7m_restart" the default ".restart" function for all
armv7-m platform, he will not be able to test it on stm32 MCU (as it is
not currently working). I propose to do it in 2 steps:
1-Keep as you suggest only one board-dt.c file for both (MCU and MPU)
and remove ".restart" function.
2-Investigate and send patches around ".restart" for both in an other
series.
regards
Alex
> Arnd
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox