Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed

* [PATCH v2 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
dsa: Document new binding"). The legacy binding node is kept included, but is
marked disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index 71ce201c903e..40ec6d768669 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -351,6 +351,8 @@
 	};
 
 	dsa at 0 {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		dsa,ethernet = <&eth1>;
 		dsa,mii-bus = <&mdio>;
@@ -444,3 +446,66 @@
 		status = "disabled";
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	switch at 4 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <4>;
+		pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
+		pinctrl-names = "default";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan5";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan4";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan3";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "lan2";
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "lan1";
+			};
+
+			port at 5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth1>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			port at 6 {
+				/* 88E1512 external phy */
+				reg = <6>;
+				label = "lan6";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
+};
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 4/8] ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 53 +++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 83ac884c0f8a..42ea8764814c 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -302,6 +302,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -398,3 +400,54 @@
 		spi-max-frequency = <40000000>;
 	};
 };
+
+&mdio {
+	status = "okay";
+
+	switch at 0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan4";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan3";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan2";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "lan1";
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "internet";
+			};
+
+			port at 5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
+};
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 5/8] ARM: dts: kirkwood-dir665: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-dir665.dts | 49 +++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-dir665.dts b/arch/arm/boot/dts/kirkwood-dir665.dts
index 41acbb6dd6ab..4d2b15d6244a 100644
--- a/arch/arm/boot/dts/kirkwood-dir665.dts
+++ b/arch/arm/boot/dts/kirkwood-dir665.dts
@@ -194,6 +194,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -241,6 +243,53 @@
 
 &mdio {
 	status = "okay";
+
+	switch at 0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan4";
+			};
+
+			port at 1 {
+			       reg = <1>;
+			       label = "lan3";
+			};
+
+			port at 2 {
+			       reg = <2>;
+			       label = "lan2";
+			};
+
+			port at 3 {
+			       reg = <3>;
+			       label = "lan1";
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "wan";
+			};
+
+			port at 6 {
+				reg = <6>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 /* eth0 is connected to a Marvell 88E6171 switch, without a PHY. So set
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 6/8] ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-linksys-viper.dts | 49 ++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-linksys-viper.dts b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
index 345fcac48dc7..df7851820507 100644
--- a/arch/arm/boot/dts/kirkwood-linksys-viper.dts
+++ b/arch/arm/boot/dts/kirkwood-linksys-viper.dts
@@ -70,6 +70,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -207,6 +209,53 @@
 
 &mdio {
 	status = "okay";
+
+	switch at 10 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <16>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "ethernet1";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "ethernet2";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "ethernet3";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "ethernet4";
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "internet";
+			};
+
+			port at 5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 &uart0 {
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 7/8] ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 ++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
index 172a38c0b8a9..327023a477b8 100644
--- a/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
+++ b/arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts
@@ -112,6 +112,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -159,6 +161,53 @@
 
 &mdio {
 	status = "okay";
+
+	switch at 0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan1";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan2";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan3";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "lan4";
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "wan";
+			};
+
+			port at 5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
 };
 
 &eth0 {
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 8/8] ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-05 19:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105192957.14304-1-f.fainelli@gmail.com>

Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
Document new binding"). The legacy binding node is kept included, but is marked
disabled.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 ++++++++
 arch/arm/boot/dts/kirkwood-rd88f6281.dtsi   | 44 +++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts b/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
index 1a797381d3d4..6a4a65ec7944 100644
--- a/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
+++ b/arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts
@@ -33,3 +33,14 @@
 &eth1 {
       status = "disabled";
 };
+
+&switch {
+	reg = <0>;
+
+	ports {
+		port at 4 {
+			reg = <4>;
+			label = "wan";
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi b/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
index d5aacf137e40..91f5da5dae5f 100644
--- a/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
+++ b/arch/arm/boot/dts/kirkwood-rd88f6281.dtsi
@@ -54,6 +54,8 @@
 	};
 
 	dsa {
+		status = "disabled";
+
 		compatible = "marvell,dsa";
 		#address-cells = <2>;
 		#size-cells = <0>;
@@ -115,6 +117,48 @@
 
 &mdio {
 	status = "okay";
+
+	switch: switch at 0 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan1";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan2";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan3";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "lan4";
+			};
+
+			port at 5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth0port>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+		};
+	};
 };
 
 &eth0 {
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2017-01-05 19:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2c85559a-dc12-610b-c842-c89d078e1c2a@osg.samsung.com>

On Wed, Jan 04, 2017 at 08:57:47PM -0300, Javier Martinez Canillas wrote:
> Hello Doug,
> 
> On 01/04/2017 06:05 PM, Doug Anderson wrote:
> > Hi,
> > 
> > On Thu, Dec 29, 2016 at 6:17 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On Thu, Dec 15, 2016 at 04:54:30PM -0800, Doug Anderson wrote:
> >>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>> ===================================================================
> >>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
> >>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
> >>>> @@ -24,6 +24,16 @@
> >>>>  };
> >>>>
> >>>>  &cluster_a15_opp_table {
> >>>> +       opp at 2000000000 {
> >>>> +               opp-hz = /bits/ 64 <2000000000>;
> >>>> +               opp-microvolt = <1250000>;
> >>>> +               clock-latency-ns = <140000>;
> >>>> +       };
> >>>> +       opp at 1900000000 {
> >>>> +               opp-hz = /bits/ 64 <1900000000>;
> >>>> +               opp-microvolt = <1250000>;
> >>>> +               clock-latency-ns = <140000>;
> >>>> +       };
> >>>
> >>> I don't think the voltages you listed are high enough for all peach pi
> >>> boards for A15 at 1.9 GHz and 2.0 GHz, at least based on the research
> >>> I did.  See my response to v1.
> >>
> >> I wanted to apply this but saw this remaining issue. Javier tested it
> >> on Peach Pi so is this concern still valid?
> > 
> > I'm not sure.  It's been years since I did anything with exynos, so I
> > won't stand in the way if everyone else agrees that this patch is
> > good, but I will point out that testing on a single Peach Pi board is
> > not really enough given the massive difference in voltage needed
> > between the highest ASV group and the lowest (a whopping 112.5 mV from
> > looking in the Chrome OS source tree).
> > 
> 
> I agree. That's why answered that I wasn't able to find regressions on the
> Peach Pi I've access to, but I couldn't provide a Reviewed-by tag since it
> wasn't clear to me that the values were safe for any Exynos5420/5422/5800.

The value of 1.250 V seems to be covering only half of ASV values for
2.0 GHz so indeed it might be insufficient for some of the chips.
Unfortunately...

Best regards,
Krzysztof

^ permalink raw reply

* [arm:clearfog 21/65] drivers/net/phy/micrel.c:969:2: warning: initialization from incompatible pointer type
From: kbuild test robot @ 2017-01-05 19:41 UTC (permalink / raw)
  To: linux-arm-kernel

tree:   git://git.armlinux.org.uk/~rmk/linux-arm.git clearfog
head:   a0b3b7ea35687eaa7b1836bcdbbe10daf034c621
commit: adb3f9b9239ac1d683db5f1e0ac9435966d02b3d [21/65] net: phy: convert micrel to new read_mmd/write_mmd driver methods
config: openrisc-or1ksim_defconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout adb3f9b9239ac1d683db5f1e0ac9435966d02b3d
        # save the attached .config to linux build tree
        make.cross ARCH=openrisc 

All warnings (new ones prefixed by >>):

>> drivers/net/phy/micrel.c:969:2: warning: initialization from incompatible pointer type

vim +969 drivers/net/phy/micrel.c

   953		.phy_id_mask	= 0x000ffffe,
   954		.name		= "Micrel KSZ9021 Gigabit PHY",
   955		.features	= (PHY_GBIT_FEATURES | SUPPORTED_Pause),
   956		.flags		= PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
   957		.driver_data	= &ksz9021_type,
   958		.config_init	= ksz9021_config_init,
   959		.config_aneg	= genphy_config_aneg,
   960		.read_status	= genphy_read_status,
   961		.ack_interrupt	= kszphy_ack_interrupt,
   962		.config_intr	= kszphy_config_intr,
   963		.get_sset_count = kszphy_get_sset_count,
   964		.get_strings	= kszphy_get_strings,
   965		.get_stats	= kszphy_get_stats,
   966		.suspend	= genphy_suspend,
   967		.resume		= genphy_resume,
   968		.read_mmd	= ksz9021_rd_mmd_phyreg,
 > 969		.write_mmd	= ksz9021_wr_mmd_phyreg,
   970	}, {
   971		.phy_id		= PHY_ID_KSZ9031,
   972		.phy_id_mask	= MICREL_PHY_ID_MASK,
   973		.name		= "Micrel KSZ9031 Gigabit PHY",
   974		.features	= (PHY_GBIT_FEATURES | SUPPORTED_Pause),
   975		.flags		= PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
   976		.driver_data	= &ksz9021_type,
   977		.config_init	= ksz9031_config_init,

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 7274 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/58dd2493/attachment.gz>

^ permalink raw reply

* [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Chris Packham @ 2017-01-05 19:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105130945.GA18033@lunn.ch>

On 06/01/17 02:10, Andrew Lunn wrote:
>> I'd love to see a switchdev driver but it's a huge task (and no I'm not
>> committing to writing it). As it stands Marvell ship a switch SDK
>> largely executes in userspace with a small kernel module providing some
>> linkage to the underlying hardware.
>
> Is there any similarity to the mv88e6xxx family?
>
> If it was similar registers, just a different access mechanising, we
> could probably extend the mv88e6xxx to support MMIO as well as MDIO.

No the prestera family of devices are considerably more powerful (and 
complex) than the linkstreet devices.

^ permalink raw reply

* [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
From: Robert Richter @ 2017-01-05 19:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105122200.GV4930@rric.localdomain>

On 05.01.17 13:22:00, Robert Richter wrote:
> On 05.01.17 12:08:20, Will Deacon wrote:
> > I really can't see how the fix causes a crash, and I couldn't reproduce
> > it on any of my boards, nor could any of the Linaro folk afaik. Are you
> > definitely running mainline with just these two patches from Ard?
> 
> Yes, just both patches applied. Various other solutions were working.

I have retested the same kernel (v4.9 based) as before and now it
boots fine including rtc-efi device registration (it was crashing
there):

 rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0

There could be a difference in firmware and mem setup, though I also
downgraded the firmware to test it, but can't reproduce it anymore. I
could reliable trigger the crash the first time.

FTR the oops.

-Robert


Unable to handle kernel paging request at virtual address 20251000
pgd = ffff000009090000
[20251000] *pgd=0000010ffff90003
, *pud=0000010ffff90003
, *pmd=0000000fdc030003
, *pte=00e8832000250707

Internal error: Oops: 96000047 [#1] SMP
Modules linked in:
CPU: 49 PID: 1 Comm: swapper/0 Tainted: G        W       4.9.0.0.vanilla10-00002-g429605e9ab0a #1
Hardware name: www.cavium.com ThunderX CRB-2S/ThunderX CRB-2S, BIOS 0.3 Sep 13 2016
task: ffff800feee6bc00 task.stack: ffff800fec050000
PC is at 0x201ff820
LR is at 0x201fdfc0
pc : [<00000000201ff820>] lr : [<00000000201fdfc0>] pstate: 20000045
sp : ffff800fec053b70
x29: ffff800fec053bc0 x28: 0000000000000000 
x27: ffff000008ce3e08 x26: ffff000008c52568 
x25: ffff000008bf045c x24: ffff000008bdb828 
x23: 0000000000000000 x22: 0000000000000040 
x21: ffff800fec053bb8 x20: 0000000020251000 
x19: ffff800fec053c20 x18: 0000000000000000 
x17: 0000000000000000 x16: 00000000bbb67a65 
x15: ffffffffffffffff x14: ffff810016ea291c 
x13: ffff810016ea2181 x12: 0000000000000030 
x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f 
x9 : feff716475687163 x8 : ffffffffffffffff 
x7 : 83f0680000000000 x6 : 0000000000000000 
x5 : ffff800fc187aab9 x4 : 0002000000000000 
x3 : ffff800fec053bb8 x2 : 0000000000000000 
x1 : 83f0680000000000 x0 : 0000000020251000 

Process swapper/0 (pid: 1, stack limit = 0xffff800fec050020)
Stack: (0xffff800fec053b70 to 0xffff800fec054000)
3b60:                                   ffff800fec053c20 ffff800fec053c20
3b80: ffff800fec053c10 00000000201fd500 ffff000008e660d0 ffff800fec053c20
3ba0: ffff0000086eb954 ffff0000086eb930 ffff800fec053bc0 ffff0000086eb934
3bc0: ffff800fec053bf0 ffff000008c3eef4 ffff000008e602a0 ffff000008e602b0
3be0: ffff000008e60740 ffff000008e60768 ffff800fec053c30 ffff000008586c88
3c00: 00000000ffffffed ffff00000858023c ffff800fec053c30 ffff000008586c68
3c20: 0000000000000000 ffff000008e602b0 ffff800fec053c60 ffff0000085845d4
3c40: ffff000008e602b0 ffff000009049000 0000000000000000 ffff000008e60768
3c60: ffff800fec053ca0 ffff0000085848ac ffff000008e602b0 ffff000008e60310
3c80: ffff000008e60768 0000000000000000 ffff000008e4d000 ffff000008bdb828
3ca0: ffff800fec053cd0 ffff000008581e08 0000000000000000 ffff000008e60768
3cc0: ffff000008584788 0000000000000000 ffff800fec053d10 ffff000008583c30
3ce0: ffff000008e60768 ffff810fed477c00 ffff000008e4deb0 0000000000000000
3d00: ffff800fe54554a8 ffff810fed478e68 ffff800fec053d30 ffff000008583668
3d20: ffff000008e60768 ffff810fed477c00 ffff800fec053d70 ffff000008585430
3d40: ffff000008e60768 0000000000000000 ffff000008c3eed0 ffff000008e60768
3d60: ffff000008ef0000 0000000000000000 ffff800fec053d90 ffff000008586e3c
3d80: ffff000008e60740 0000000000000000 ffff800fec053dc0 ffff000008c3eec8
3da0: ffff000008c3eea8 ffff800fec050000 0000000000000000 0000000000000006
3dc0: ffff800fec053dd0 ffff000008082d94 ffff800fec053e40 ffff000008bf0d0c
3de0: 00000000000000f3 ffff000008ef0000 ffff000008c52578 0000000000000006
3e00: ffff000008ce3600 0000000000000000 ffff000008da2428 ffff000008ab2fa8
3e20: 0000000000000000 0000000600000006 ffff000008bf045c ffff000008bdb828
3e40: ffff800fec053ea0 ffff00000885e7a0 ffff00000885e788 0000000000000000
3e60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3e80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3ea0: 0000000000000000 ffff000008082b30 ffff00000885e788 0000000000000000
3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000
3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call trace:
Exception stack(0xffff800fec0539a0 to 0xffff800fec053ad0)
39a0: ffff800fec053c20 0001000000000000 ffff800fec053b70 00000000201ff820
39c0: 0000000000000000 ffff810000412890 ffff800fec0539f0 ffff000008405534
39e0: ffff810000412890 ffff810016e90e30 ffff800fec053a20 ffff00000840682c
3a00: 0000000000000000 ffff800fc168f880 0000000000000000 ffff00000840668c
3a20: ffff800fec053ac0 ffff0000084069f8 ffff00000903e7b0 0000000000000001
3a40: 0000000020251000 83f0680000000000 0000000000000000 ffff800fec053bb8
3a60: 0002000000000000 ffff800fc187aab9 0000000000000000 83f0680000000000
3a80: ffffffffffffffff feff716475687163 7f7f7f7f7f7f7f7f 0101010101010101
3aa0: 0000000000000030 ffff810016ea2181 ffff810016ea291c ffffffffffffffff
3ac0: 00000000bbb67a65 0000000000000000
[<00000000201ff820>] 0x201ff820
[<ffff000008c3eef4>] efi_rtc_probe+0x24/0x78
[<ffff000008586c88>] platform_drv_probe+0x60/0xc8
[<ffff0000085845d4>] driver_probe_device+0x26c/0x420
[<ffff0000085848ac>] __driver_attach+0x124/0x128
[<ffff000008581e08>] bus_for_each_dev+0x70/0xb0
[<ffff000008583c30>] driver_attach+0x30/0x40
[<ffff000008583668>] bus_add_driver+0x200/0x2b8
[<ffff000008585430>] driver_register+0x68/0x100
[<ffff000008586e3c>] __platform_driver_probe+0x84/0x128
[<ffff000008c3eec8>] efi_rtc_driver_init+0x20/0x28
[<ffff000008082d94>] do_one_initcall+0x44/0x138
[<ffff000008bf0d0c>] kernel_init_freeable+0x1ac/0x24c
[<ffff00000885e7a0>] kernel_init+0x18/0x110
[<ffff000008082b30>] ret_from_fork+0x10/0x20
Code: f9400000 d5033d9f d65f03c0 d5033e9f (f9000001) 
---[ end trace e420ef9636e3c9b2 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

^ permalink raw reply

* [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Florian Fainelli @ 2017-01-05 19:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <059c78eaa7dd40c9a46cb08616bae2eb@svr-chch-ex1.atlnz.lc>

On 01/05/2017 11:46 AM, Chris Packham wrote:
> On 06/01/17 02:10, Andrew Lunn wrote:
>>> I'd love to see a switchdev driver but it's a huge task (and no I'm not
>>> committing to writing it). As it stands Marvell ship a switch SDK
>>> largely executes in userspace with a small kernel module providing some
>>> linkage to the underlying hardware.
>>
>> Is there any similarity to the mv88e6xxx family?
>>
>> If it was similar registers, just a different access mechanising, we
>> could probably extend the mv88e6xxx to support MMIO as well as MDIO.
> 
> No the prestera family of devices are considerably more powerful (and 
> complex) than the linkstreet devices.

I see, we have a similar situation with some of the Broadcom SoCs, the
BCM534xx/BCM5334x have a completely different integrated switching
engine that is not roboswitch compatible.

Thanks for the information, this is still valuable to have this
supported upstream.
-- 
Florian

^ permalink raw reply

* next-20170105 build: 4 failures 3 warnings (next-20170105)
From: Mark Brown @ 2017-01-05 19:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <E1cP6p1-0007i0-IF@optimist>

On Thu, Jan 05, 2017 at 12:07:08PM +0000, Build bot for Mark Brown wrote:

Since sometime over the Christmas vacation all arm64 configs have been
failing to build due to:

> ../arch/arm64/include/asm/setup.h:14:29: error: redefinition of 'kaslr_offset'

(same error repeating a different number of times for each config).
This is an interaction between Andrew's -current tree and Linus' tree.
Andrew's tree has "arm64: setup: introduce kaslr_offset()"
(1a339a14b1f2c7 in current -next) and Linus' tree has a commit
7ede8665f27cde7d with the same title but a modified version that went to
Linus through Will.  In the version in Andrew's tree kaslr_offset() is
defined in asm/setup.h while in the version in Linus' tree it is
instead defined in asm/memory.h so -next ends up with two definitions of
that function causing the build errors.

I guess the commit in Andrew's tree should be dropped now, reverting it
fixes the builds for me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/c7933fea/attachment.sig>

^ permalink raw reply

* [PATCHv2 0/5] Support for Marvell switches with integrated CPUs
From: Chris Packham @ 2017-01-05 20:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPv3WKcT8MxX+g12C1o81MmQJWRt7Rpd-hgBh8rTpLOS3vdtqA@mail.gmail.com>

On 06/01/17 03:09, Marcin Wojtas wrote:
> Hi Chris,
>
> Thanks a lot for your work and v2. Can you please add changelog
> between patchset versions in your cover letter?

Will do for v3. I did actually include a changelog in the individual 
patches but I can collate that here.

clk: mvebu: support for 98DX3236 SoC
- Update devicetree binding documentation for new compatible string
arm: mvebu: support for SMP on 98DX3336 SoC
- Document new enable-method value
- Correct some references from 98DX4521 to 98DX3236
pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
- include sdio support for the 98DX4251
arm: mvebu: Add device tree for 98DX3236 SoCs
- Update devicetree binding documentation to reflect that 98DX3336 and
   984251 are supersets of 98DX3236.
- disable crypto block
- disable sdio for 98DX3236, enable for 98DX4251
arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
- None

Here's the interdiff

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
b/Documentation/devicetree/bindings/arm/cpus.txt
index a1bcfeed5f24..3c2fd72d0bf9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -202,6 +202,7 @@ nodes to be present and contain the properties 
described below.
                             "marvell,armada-380-smp"
                             "marvell,armada-390-smp"
                             "marvell,armada-xp-smp"
+                           "marvell,98dx3236-smp"
                             "mediatek,mt6589-smp"
                             "mediatek,mt81xx-tz-smp"
                             "qcom,gcc-msm8660"
diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt 
b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
index e7dc9b2dd90b..64e8c73fc5ab 100644
--- a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
@@ -6,5 +6,18 @@ shall have the following property:

  Required root node property:

-compatible: one of "marvell,armadaxp-98dx3236", "marvell,armadaxp-98dx3336"
-            or "marvell,armadaxp-98dx4251"
+compatible: must contain "marvell,armadaxp-98dx3236"
+
+In addition, boards using the Marvell 98DX3336 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx3336"
+
+In addition, boards using the Marvell 98DX4251 SoC shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armadaxp-98dx4251"
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt 
b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
index 99c214660bdc..7f28506eaee7 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -3,6 +3,7 @@ Device Tree Clock bindings for cpu clock of Marvell EBU 
platforms
  Required properties:
  - compatible : shall be one of the following:
         "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
+       "marvell,mv98dx3236-cpu-clock" - cpu clocks for 98DX3236 SoC
  - reg : Address and length of the clock complex register set, followed
          by address and length of the PMU DFS registers
  - #clock-cells : should be set to 1.
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
index 34c1e380adaa..d4e6ecdfc853 100644
--- 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
+++ 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
@@ -4,7 +4,7 @@ Please refer to marvell,mvebu-pinctrl.txt in this 
directory for common binding
  part and usage

  Required properties:
-- compatible: "marvell,98dx3236-pinctrl"
+- compatible: "marvell,98dx3236-pinctrl" or "marvell,98dx4251-pinctrl"
  - reg: register specifier of MPP registers

  This driver supports all 98dx3236, 98dx3336 and 98dx4251 variants
@@ -16,12 +16,12 @@ mpp1          1        gpio, spi0(miso), dev(ad9)
  mpp2          2        gpio, spi0(sck), dev(ad10)
  mpp3          3        gpio, spi0(cs0), dev(ad11)
  mpp4          4        gpio, spi0(cs1), smi(mdc), dev(cs0)
-mpp5          5        gpio, pex(rsto), dev(bootcs)
-mpp6          6        gpio, dev(a2)
-mpp7          7        gpio, dev(ale0)
-mpp8          8        gpio, dev(ale1)
-mpp9          9        gpio, dev(ready0)
-mpp10         10       gpio, dev(ad12)
+mpp5          5        gpio, pex(rsto), sd0(cmd), dev(bootcs)
+mpp6          6        gpio, sd0(clk), dev(a2)
+mpp7          7        gpio, sd0(d0), dev(ale0)
+mpp8          8        gpio, sd0(d1), dev(ale1)
+mpp9          9        gpio, sd0(d2), dev(ready0)
+mpp10         10       gpio, sd0(d3), dev(ad12)
  mpp11         11       gpio, uart1(rxd), uart0(cts), dev(ad13)
  mpp12         12       gpio, uart1(txd), uart0(rts), dev(ad14)
  mpp13         13       gpio, intr(out), dev(ad15)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index bac53f8b44af..61bd3acc5cfe 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -138,6 +138,10 @@
                                 status = "disabled";
                         };

+                       crypto at 90000 {
+                               status = "disabled";
+                       };
+
                         xor at f0900 {
                                 status = "disabled";
                         };
@@ -229,3 +233,15 @@
                 marvell,function = "spi0";
         };
  };
+
+&sdio {
+       status = "disabled";
+};
+
+&crypto_sram0 {
+       status = "disabled";
+};
+
+&crypto_sram1 {
+       status = "disabled";
+};
diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi 
b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
index 5d1da8513fae..5f7edc23d5ae 100644
--- a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
@@ -76,3 +76,17 @@
                 };
         };
  };
+
+&sdio {
+       status = "okay";
+};
+
+&pinctrl {
+       compatible = "marvell,98dx4251-pinctrl";
+
+       sdio_pins: sdio-pins {
+               marvell,pins = "mpp5", "mpp6", "mpp7",
+                              "mpp8", "mpp9", "mpp10";
+               marvell,function = "sd0";
+       };
+};
diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c 
b/arch/arm/mach-mvebu/pmsu-98dx3236.c
index fadc81d0c051..87ca42ef40c7 100644
--- a/arch/arm/mach-mvebu/pmsu-98dx3236.c
+++ b/arch/arm/mach-mvebu/pmsu-98dx3236.c
@@ -1,5 +1,5 @@
  /**
- * CPU resume support for 98DX4521 internal CPU (a.k.a. MSYS).
+ * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
   */

  #define pr_fmt(fmt) "mv98dx3236-resume: " fmt
@@ -38,7 +38,7 @@ static int __init mv98dx3236_resume_init(void)
         if (!np)
                 return 0;

-       pr_info("Initializing 98DX4521 Resume\n");
+       pr_info("Initializing 98DX3236 Resume\n");

         if (of_address_to_resource(np, 0, &res)) {
                 pr_err("unable to get resource\n");
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 2586903c59f0..554eeae8cd21 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -389,21 +389,27 @@ static struct mvebu_mpp_mode 
mv98dx3236_mpp_modes[] = {
         MPP_MODE(5,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
                  MPP_VAR_FUNCTION(0x1, "pex", "rsto", 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "cmd",         V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "bootcs0", 
V_98DX3236_PLUS)),
         MPP_MODE(6,
                  MPP_VAR_FUNCTION(0x0, "gpo", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "clk",         V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "a2", 
V_98DX3236_PLUS)),
         MPP_MODE(7,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d0",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ale0", 
V_98DX3236_PLUS)),
         MPP_MODE(8,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d1",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ale1", 
V_98DX3236_PLUS)),
         MPP_MODE(9,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d2",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ready0", 
V_98DX3236_PLUS)),
         MPP_MODE(10,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
+                MPP_VAR_FUNCTION(0x2, "sd0", "d3",          V_98DX4251),
                  MPP_VAR_FUNCTION(0x4, "dev", "ad12", 
V_98DX3236_PLUS)),
         MPP_MODE(11,
                  MPP_VAR_FUNCTION(0x0, "gpio", NULL, 
V_98DX3236_PLUS),
@@ -501,6 +507,10 @@ static const struct of_device_id 
armada_xp_pinctrl_of_match[] = {
                 .compatible = "marvell,98dx3236-pinctrl",
                 .data       = (void *) V_98DX3236,
         },
+       {
+               .compatible = "marvell,98dx4251-pinctrl",
+               .data       = (void *) V_98DX4251,
+       },
         { },
  };



>
> Best regards,
> Marcin
>
> 2017-01-05 4:36 GMT+01:00 Chris Packham <chris.packham@alliedtelesis.co.nz>:
>> The 98DX3236, 98DX3336 and 98DX4251 are a set of switch ASICs with
>> integrated CPUs. They CPU block is common within these product lines and
>> (as far as I can tell/have been told) is based on the Armada XP. There
>> are a few differences due to the fact they have to squeeze the CPU into
>> the same package as the switch.
>>
>> Chris Packham (4):
>>   clk: mvebu: support for 98DX3236 SoC
>>   arm: mvebu: support for SMP on 98DX3336 SoC
>>   arm: mvebu: Add device tree for 98DX3236 SoCs
>>   arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards
>>
>> Kalyan Kinthada (1):
>>   pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
>>
>>  Documentation/devicetree/bindings/arm/cpus.txt     |   1 +
>>  .../bindings/arm/marvell/98dx3236-resume-ctrl.txt  |  18 ++
>>  .../devicetree/bindings/arm/marvell/98dx3236.txt   |  23 ++
>>  .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   1 +
>>  .../pinctrl/marvell,armada-98dx3236-pinctrl.txt    |  46 ++++
>>  arch/arm/boot/dts/armada-xp-98dx3236.dtsi          | 247 +++++++++++++++++++++
>>  arch/arm/boot/dts/armada-xp-98dx3336.dtsi          |  78 +++++++
>>  arch/arm/boot/dts/armada-xp-98dx4251.dtsi          |  92 ++++++++
>>  arch/arm/boot/dts/db-dxbc2.dts                     | 159 +++++++++++++
>>  arch/arm/boot/dts/db-xc3-24g4xg.dts                | 155 +++++++++++++
>>  arch/arm/mach-mvebu/Makefile                       |   1 +
>>  arch/arm/mach-mvebu/common.h                       |   1 +
>>  arch/arm/mach-mvebu/platsmp.c                      |  43 ++++
>>  arch/arm/mach-mvebu/pmsu-98dx3236.c                |  69 ++++++
>>  drivers/clk/mvebu/Makefile                         |   2 +-
>>  drivers/clk/mvebu/armada-xp.c                      |  42 ++++
>>  drivers/clk/mvebu/clk-cpu.c                        |  33 ++-
>>  drivers/clk/mvebu/mv98dx3236-corediv.c             | 207 +++++++++++++++++
>>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c          | 155 +++++++++++++
>>  19 files changed, 1369 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
>>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
>>  create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
>>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
>>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
>>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
>>  create mode 100644 arch/arm/boot/dts/db-dxbc2.dts
>>  create mode 100644 arch/arm/boot/dts/db-xc3-24g4xg.dts
>>  create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
>>  create mode 100644 drivers/clk/mvebu/mv98dx3236-corediv.c
>>
>> --
>> 2.11.0.24.ge6920cf
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

^ permalink raw reply related

* [nomadik:lis3lv02 5/6] warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet direct dependencies (IIO && ..)
From: kbuild test robot @ 2017-01-05 20:03 UTC (permalink / raw)
  To: linux-arm-kernel

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git lis3lv02
head:   e343deae8006a1fc109534497c943eab51a1c2a8
commit: 0a9710dd480b06b6fefefdedc732020f2297e247 [5/6] iio: accel: st_accel: handle deprecated bindings
config: x86_64-randconfig-x008-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        git checkout 0a9710dd480b06b6fefefdedc732020f2297e247
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS && IIO_ST_SENSORS_I2C)

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 27927 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/31be2ce4/attachment-0001.gz>

^ permalink raw reply

* [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-05 20:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdbX_MuLSCerq08-1VZV6VJfynjkv1QOr7ssOCGvM5aB_Q@mail.gmail.com>

On Tue, Jan 03, 2017 at 09:24:34AM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 4:17 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Fri, Dec 30, 2016 at 02:32:39PM +0100, Linus Walleij wrote:
> >> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> >>
> >> > Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> >> > instead of hardcoded values.
> >> >
> >> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> >>
> >> These look fine, but that this and the other DTS patch through ARM SoC.
> >>
> >> If you also need the headerfile patch (patch 2) to go through ARM SoC
> >> that is fine,
> >> I can take it out of pinctrl if you want.
> >
> > Yes, I need the header. It would be much appreciated if you could
> > provide a tag or stable branch with it.
> 
> Nah better just merge that patch into the ARM SoC tree only.
> 
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> 
> I'll remove it from the pinctrl tree.

Thanks, I see it being dropped.

Andi,
Please fix missing Signed-off-by and resend with Linus' tags for #1 and
#2 and with other accumulated tags.

Best regards,
Krzysztof

^ permalink raw reply

* [PATCHv2 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Chris Packham @ 2017-01-05 20:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170105135837.GC25333@leverpostej>

On 06/01/17 02:59, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:40PM +1300, Chris Packham wrote:
>> +		internal-regs {
>> +			coreclk: mvebu-sar at 18230 {
>> +				compatible = "marvell,mv98dx3236-core-clock";
>> +			};
>> +
>> +			cpuclk: clock-complex at 18700 {
>> +				compatible = "marvell,mv98dx3236-cpu-clock";
>> +			};
>> +
>> +			corediv-clock at 18740 {
>> +				compatible = "marvell,mv98dx3236-corediv-clock";
>> +				reg = <0xf8268 0xc>;
>> +				base = <&dfx>;
>> +				#clock-cells = <1>;
>> +				clocks = <&mainpll>;
>> +				clock-output-names = "nand";
>> +			};
>
> [...]
>
>> +		};
>> +
>> +		dfx-registers {
>> +			compatible = "simple-bus";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
>> +
>> +			dfx: dfx at 0 {
>> +				compatible = "simple-bus";
>> +				reg = <0 0x100000>;
>> +			};
>> +		};
>
> What is this dfx-registers, exactly?

I've been trying to get that info out of Marvell for a while I'm not 
even sure what the "DFX" acronym stands for. The Armdada 38x also has a 
thing called "DFX" but it seems to be quite different to this one. From 
what I can tell it contains common elements used by both the CPU and 
switch chip so there are things related to clocking and IO pad 
configuration. It is necessary for both the switch and CPU to have a 
handle to access it.

> It has no children, so why is it a
> simple-bus?
>
> From the above, and the patch adding the corediv driver, it looks like
> the corediv-clock actually lives in this block, so I don't understand
> why the corediv-clock is sitting in internal-regs with a sideband
> reference to dfx.

Yeah I think the corediv-clock should be a child of this node. I'll move 
it there.

>
> Thanks,
> Mark.
>

^ permalink raw reply

* [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
From: Yury Norov @ 2017-01-05 20:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3703608.GKr1zzErMk@wuerfel>

On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote:
> On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > > On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote:
> > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > > detection of the task type.
> > > > 
> > > > What's wrong with the run-time detection? If it's just to avoid a
> > > > negligible overhead, I would rather keep the code simpler by avoiding
> > > > duplicating the generic compat_sys_ptrace().
> > > 
> > > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
> > 
> > Hmm, I completely forgot about this ;). There is still an advantage to
> > doing run-time checking if we avoid touching core code (less acks to
> > gather and less code duplication).
> > 
> > Let's see what Arnd says but the initial patch looked simpler.
> 
> I don't currently have either version of the patch in my inbox
> (the archive is on a different machine), but in general I'd still
> think it's best to avoid the runtime check for aarch64-ilp32
> altogether. I'd have to look at the overall kernel source to
> see if it's worth avoiding one or two instances though, or
> if there are an overwhelming number of other checks that we
> can't avoid at all.
> 
> Regarding ptrace, I notice that arch/tile doesn't even use
> the compat entry point for its ilp32 user space on 64-bit
> kernels, it just calls the regular 64-bit one. Would that
> help here?

ILP32 tasks has unique context that is not like aarch64 or aarch32,
so we have to have unique ptrace handler. I prepared the patch for
ptrace with runtime ABI detection, as Catalin said, see there:
https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670

If it's OK, I'd like to update submission.

Yury

^ permalink raw reply

* [PATCH] net: phy: dp83867: fix irq generation
From: Grygorii Strashko @ 2017-01-05 20:48 UTC (permalink / raw)
  To: linux-arm-kernel

For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
programmed as an interrupt output instead of a Powerdown input in
Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
current driver doesn't do this and as result IRQs will not be generated by
DP83867 phy even if they are properly configured in DT.

Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
driver will work properly in interrupt enabled mode.

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 drivers/net/phy/dp83867.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 1b63924..e84ae08 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -29,6 +29,7 @@
 #define MII_DP83867_MICR	0x12
 #define MII_DP83867_ISR		0x13
 #define DP83867_CTRL		0x1f
+#define DP83867_CFG3		0x1e
 
 /* Extended Registers */
 #define DP83867_RGMIICTL	0x0032
@@ -98,6 +99,8 @@ static int dp83867_config_intr(struct phy_device *phydev)
 		micr_status |=
 			(MII_DP83867_MICR_AN_ERR_INT_EN |
 			MII_DP83867_MICR_SPEED_CHNG_INT_EN |
+			MII_DP83867_MICR_AUTONEG_COMP_INT_EN |
+			MII_DP83867_MICR_LINK_STS_CHNG_INT_EN |
 			MII_DP83867_MICR_DUP_MODE_CHNG_INT_EN |
 			MII_DP83867_MICR_SLEEP_MODE_CHNG_INT_EN);
 
@@ -214,6 +217,13 @@ static int dp83867_config_init(struct phy_device *phydev)
 		}
 	}
 
+	/* Enable Interrupt output INT_OE in CFG3 register */
+	if (phy_interrupt_is_valid(phydev)) {
+		val = phy_read(phydev, DP83867_CFG3);
+		val |= BIT(7);
+		phy_write(phydev, DP83867_CFG3, val);
+	}
+
 	return 0;
 }
 
-- 
2.10.1.dirty

^ permalink raw reply related

* [PATCHv2 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-05 20:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <dd384eda81d2420dafe740bf5bb4dae0@svr-chch-ex1.atlnz.lc>

On 05/01/17 17:46, Chris Packham wrote:
> On 05/01/17 17:04, Florian Fainelli wrote:
>> Le 01/04/17 ? 19:36, Chris Packham a ?crit :
>>> +}
>>> +
>>> +static int __init mv98dx3236_resume_init(void)
>>> +{
>>> +	struct device_node *np;
>>> +	struct resource res;
>>> +	int ret = 0;
>>> +
>>> +	np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
>>> +	if (!np)
>>> +		return 0;
>>
>> Can't this function be implemented as a smp_ops::smp_init_cpus instead
>> of having this initialization done at arch_initcall time?
>>
>
> I'll look into it. My initial reaction is no because I still need
> armada_xp_smp_init_cpus().
>

I looked at this. I could write a mv98dx3236_smp_init_cpus() that calls 
armada_xp_smp_init_cpus() and inits the resume controller address. My 
original reason for this approach was to parallel mvebu_v7_pmsu_init. I 
won't do anything just yet but is there any downside to the current 
approach?

^ permalink raw reply

* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Suman Anna @ 2017-01-05 21:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483486889-3662-1-git-send-email-spjoshi@codeaurora.org>

On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
> The function wkup_m3_rproc_boot_thread waits for
> asynchronous firmware loading to parse the resource table
> before calling rproc_boot(). However, as the resource table
> parsing has been moved to rproc_boot(), there's no need to
> wait for the asynchronous firmware loading completion.
> So, drop this.
> 
> CC: Dave Gerlach <d-gerlach@ti.com>
> CC: Suman Anna <s-anna@ti.com>
> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>

+ Tony and Santosh, not sure who is picking up the wkup_m3 related patches.

Only one minor nit, I would prefer the patch subject to start with
soc: ti: wkup_m3_ipc: ....

Tested-by: Suman Anna <s-anna@ti.com>

regards
Suman

> ---
> 
> This patch seems to be doing an independent clean up now. Hence
> removing it from the series.
> 
>  drivers/soc/ti/wkup_m3_ipc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
> index 8823cc8..8bfa44b 100644
> --- a/drivers/soc/ti/wkup_m3_ipc.c
> +++ b/drivers/soc/ti/wkup_m3_ipc.c
> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>  	struct device *dev = m3_ipc->dev;
>  	int ret;
>  
> -	wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
> -
>  	init_completion(&m3_ipc->sync_complete);
>  
>  	ret = rproc_boot(m3_ipc->rproc);
> 

^ permalink raw reply

* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Santosh Shilimkar @ 2017-01-05 21:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <482666d0-7915-ead2-c514-2651a4967a43@ti.com>



On 1/5/2017 1:08 PM, Suman Anna wrote:
> On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
>> The function wkup_m3_rproc_boot_thread waits for
>> asynchronous firmware loading to parse the resource table
>> before calling rproc_boot(). However, as the resource table
>> parsing has been moved to rproc_boot(), there's no need to
>> wait for the asynchronous firmware loading completion.
>> So, drop this.
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Suman Anna <s-anna@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>
> + Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
>
I think Tony has queued patches for wakeup_m3 before.

Regards,
Snatosh

^ permalink raw reply

* [PATCH V6 03/10] efi: parse ARM processor error
From: Baicar, Tyler @ 2017-01-05 21:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5852A3CA.807@arm.com>

On 12/15/2016 7:08 AM, James Morse wrote:
> Hi Tyler,
>
> On 07/12/16 21:48, Tyler Baicar wrote:
>> Add support for ARM Common Platform Error Record (CPER).
>> UEFI 2.6 specification adds support for ARM specific
>> processor error information to be reported as part of the
>> CPER records. This provides more detail on for processor error logs.
> Looks good to me, a few minor comments below.
>
> Reviewed-by: James Morse <james.morse@arm.com>
Thanks!
>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
>> index 8fa4e23..1ac2572 100644
>> --- a/drivers/firmware/efi/cper.c
>> +++ b/drivers/firmware/efi/cper.c
>> @@ -184,6 +199,110 @@ static void cper_print_proc_generic(const char *pfx,
>>   		printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
>>   }
>>   
>> +static void cper_print_proc_arm(const char *pfx,
>> +				const struct cper_sec_proc_arm *proc)
>> +{
>> +	int i, len, max_ctx_type;
>> +	struct cper_arm_err_info *err_info;
>> +	struct cper_arm_ctx_info *ctx_info;
>> +	char newpfx[64];
>> +
>> +	printk("%ssection length: %d\n", pfx, proc->section_length);
> Compared to the rest of the file, this:
>> 	printk("%s""section length: %d\n", pfx, proc->section_length);
> would be more in keeping. I guess its done this way to avoid some spurious
> warning about %ssection not being recognised by printk().
Makes sense, I'll make this change next patchset.
>> +	printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
>> +
>> +	len = proc->section_length - (sizeof(*proc) +
>> +		proc->err_info_num * (sizeof(*err_info)));
>> +	if (len < 0) {
>> +		printk("%ssection length is too small\n", pfx);
> This calculation is all based on values in the 'struct cper_sec_proc_arm', is it
> worth making more noise about how the firmware-generated record is incorrectly
> formatted? If we see this message its not the kernel's fault!
I can make the print more clear saying that the firmware-generated 
record is incorrect to make
it clear it is not a kernel issue.
>> +		printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num);
>> +		return;
>> +	}
>> +
>> +	if (proc->validation_bits & CPER_ARM_VALID_MPIDR)
>> +		printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);
>> +	if (proc->validation_bits & CPER_ARM_VALID_AFFINITY_LEVEL)
>> +		printk("%serror affinity level: %d\n", pfx,
>> +			proc->affinity_level);
>> +	if (proc->validation_bits & CPER_ARM_VALID_RUNNING_STATE) {
>> +		printk("%srunning state: %d\n", pfx, proc->running_state);
> This field is described as a bit field in table 260, can we print it as 0x%lx in
> case additional bits are set?
Yes, will do.
>> +		printk("%sPSCI state: %d\n", pfx, proc->psci_state);
>> +	}
>> +
>> +	snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
>> +
>> +	err_info = (struct cper_arm_err_info *)(proc + 1);
>> +	for (i = 0; i < proc->err_info_num; i++) {
>> +		printk("%sError info structure %d:\n", pfx, i);
>> +		printk("%sversion:%d\n", newpfx, err_info->version);
>> +		printk("%slength:%d\n", newpfx, err_info->length);
>> +		if (err_info->validation_bits &
>> +		    CPER_ARM_INFO_VALID_MULTI_ERR) {
>> +			if (err_info->multiple_error == 0)
>> +				printk("%ssingle error\n", newpfx);
>> +			else if (err_info->multiple_error == 1)
>> +				printk("%smultiple errors\n", newpfx);
>> +			else
>> +				printk("%smultiple errors count:%d\n",
>> +				newpfx, err_info->multiple_error);
> This is described as unsigned in table 261.
Will change.
>> +		}
>> +		if (err_info->validation_bits & CPER_ARM_INFO_VALID_FLAGS) {
>> +			if (err_info->flags & CPER_ARM_INFO_FLAGS_FIRST)
>> +				printk("%sfirst error captured\n", newpfx);
>> +			if (err_info->flags & CPER_ARM_INFO_FLAGS_LAST)
>> +				printk("%slast error captured\n", newpfx);
>> +			if (err_info->flags & CPER_ARM_INFO_FLAGS_PROPAGATED)
>> +				printk("%spropagated error captured\n",
>> +				       newpfx);
> Table 261 also has an 'overflow' bit in flags. It may be worth printing a
> warning if this is set:
>> Note: Overflow bit indicates that firmware/hardware error
>> buffers had experience an overflow, and it is possible that
>> some error information has been lost.
I will add that in.
>> +		}
>> +		printk("%serror_type: %d, %s\n", newpfx, err_info->type,
>> +			err_info->type < ARRAY_SIZE(proc_error_type_strs) ?
>> +			proc_error_type_strs[err_info->type] : "unknown");
>> +		if (err_info->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO)
>> +			printk("%serror_info: 0x%016llx\n", newpfx,
>> +			       err_info->error_info);
>> +		if (err_info->validation_bits & CPER_ARM_INFO_VALID_VIRT_ADDR)
>> +			printk("%svirtual fault address: 0x%016llx\n",
>> +				newpfx, err_info->virt_fault_addr);
>> +		if (err_info->validation_bits &
>> +		    CPER_ARM_INFO_VALID_PHYSICAL_ADDR)
>> +			printk("%sphysical fault address: 0x%016llx\n",
>> +				newpfx, err_info->physical_fault_addr);
>> +		err_info += 1;
>> +	}
>> +	ctx_info = (struct cper_arm_ctx_info *)err_info;
>> +	max_ctx_type = (sizeof(arm_reg_ctx_strs) /
>> +			sizeof(arm_reg_ctx_strs[0]) - 1);
> ARRAY_SIZE() - 1?
I'll use ARRAY_SIZE in the next patchset.
>> +	for (i = 0; i < proc->context_info_num; i++) {
>> +		int size = sizeof(*ctx_info) + ctx_info->size;
>> +
>> +		printk("%sContext info structure %d:\n", pfx, i);
>> +		if (len < size) {
>> +			printk("%ssection length is too small\n", newpfx);
>> +			return;
>> +		}
>> +		if (ctx_info->type > max_ctx_type) {
>> +			printk("%sInvalid context type: %d\n",	newpfx,
>> +						ctx_info->type);
>> +			printk("%sMax context type: %d\n", newpfx,
>> +						max_ctx_type);
>> +			return;
>> +		}
>> +		printk("%sregister context type %d: %s\n", newpfx,
>> +			ctx_info->type, arm_reg_ctx_strs[ctx_info->type]);
>> +		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
>> +				(ctx_info + 1), ctx_info->size, 0);
>> +		len -= size;
>> +		ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + size);
>> +	}
>> +
>> +	if (len > 0) {
>> +		printk("%sVendor specific error info has %d bytes:\n", pfx,
>> +		       len);
> %u - just in case it is surprisingly large!
>
Will do.
>> +		print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4, ctx_info,
>> +				len, 0);
>> +	}
>> +}
>> +
>>   static const char * const mem_err_type_strs[] = {
>>   	"unknown",
>>   	"no error",
>> @@ -458,6 +577,15 @@ static void cper_estatus_print_section(
>>   			cper_print_pcie(newpfx, pcie, gdata);
>>   		else
>>   			goto err_section_too_small;
>> +	} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_ARM)) {
>> +		struct cper_sec_proc_arm *arm_err;
>> +
>> +		arm_err = acpi_hest_generic_data_payload(gdata);
>> +		printk("%ssection_type: ARM processor error\n", newpfx);
>> +		if (gdata->error_data_length >= sizeof(*arm_err))
>> +			cper_print_proc_arm(newpfx, arm_err);
>> +		else
>> +			goto err_section_too_small;
>>   	} else
>>   		printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
>>   
> This is the only processor-specific entry in this function,
> CPER_SEC_PROC_{IA,IPF} don't appear anywhere else in the tree.
>
> Is it worth adding an (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)) in
> the if()? This would let the compiler remove cper_print_proc_arm(() on x86/ia64
> systems which won't ever see a record of this type.
Yes, I can add that.

Thank you for the feedback!

-Tyler

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
From: Greg Kroah-Hartman @ 2017-01-05 21:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <3286019.I2UkVCJq41@wuerfel>

On Tue, Jan 03, 2017 at 10:19:29PM +0100, Arnd Bergmann wrote:
> On Tuesday, January 3, 2017 4:24:36 PM CET Greg Kroah-Hartman wrote:
> > On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote:
> > > The icn, act2000 and pcbit drivers are all for very old hardware,
> > > and it is highly unlikely that anyone is actually still using them
> > > on modern kernels, if at all.
> > > 
> > > All three drivers apparently are for hardware that predates PCI
> > > being the common connector, as they are ISA-only and active
> > > PCI ISDN cards were widely available in the 1990s.
> > > 
> > > Looking through the git logs, it I cannot find any indication of a
> > > patch to any of these drivers that has been tested on real hardware,
> > > only cleanups or global API changes.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Karsten Keil <isdn@linux-pingi.de>
> > 
> > This patch got added in the 4.6 kernel release.  As I am now taking
> > patches for 4.11-rc1, I figure it is time to just delete the
> > drivers/staging/i4l/ directory now, given that no one has really done
> > anything with it.  If people show up that wish to maintain it, I'll be
> > glad to revert it, or if someone really screams in the next week.
> > Otherwise it's time to just move on 
> 
> Sounds good to me.

Ok, now deleted!

thanks,

greg k-h

^ permalink raw reply

* [PATCH] MAINTAINERS: Add Aaro Koskinen as TI omap1 SoC co-maintainer
From: Tony Lindgren @ 2017-01-05 21:41 UTC (permalink / raw)
  To: linux-arm-kernel

Aaro has been doing a great job making sure mach-omap1 stays working
with the mainline kernel. So let's add Aaro as omap1 co-maintainer to
the MAINTAINERS file.

Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 MAINTAINERS | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8933,7 +8933,20 @@ M:	Josh Poimboeuf <jpoimboe@redhat.com>
 S:	Supported
 F:	tools/objtool/
 
-OMAP SUPPORT
+OMAP1 SUPPORT
+M:	Aaro Koskinen <aaro.koskinen@iki.fi>
+M:	Tony Lindgren <tony@atomide.com>
+L:	linux-omap at vger.kernel.org
+Q:	http://patchwork.kernel.org/project/linux-omap/list/
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
+S:	Maintained
+F:	arch/arm/mach-omap1/
+F:	arch/arm/plat-omap/
+F:	arch/arm/configs/omap1_defconfig
+F:	drivers/i2c/busses/i2c-omap.c
+F:	include/linux/i2c-omap.h
+
+OMAP2+ SUPPORT
 M:	Tony Lindgren <tony@atomide.com>
 L:	linux-omap at vger.kernel.org
 W:	http://www.muru.com/linux/omap/
@@ -8941,8 +8954,8 @@ W:	http://linux.omap.com/
 Q:	http://patchwork.kernel.org/project/linux-omap/list/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
 S:	Maintained
-F:	arch/arm/*omap*/
-F:	arch/arm/configs/omap1_defconfig
+F:	arch/arm/mach-omap2/
+F:	arch/arm/plat-omap/
 F:	arch/arm/configs/omap2plus_defconfig
 F:	drivers/i2c/busses/i2c-omap.c
 F:	drivers/irqchip/irq-omap-intc.c
-- 
2.11.0

^ permalink raw reply

* [PATCH] ARM: OMAP1: DMA: Correct the number of logical channels
From: Aaro Koskinen @ 2017-01-05 21:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20170103112234.19097-1-peter.ujfalusi@ti.com>

Hi,

On Tue, Jan 03, 2017 at 01:22:34PM +0200, Peter Ujfalusi wrote:
> OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
> OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
> available.
> 
> The wired 17 for the lch_count must have been used to cover the 16 + 1
> dedicated LCD channel, in reality we can only use 9 or 16 channels.
> 
> The d->chan_count is not used by the omap-dma stack, so we can skip the
> setup. chan_count was configured to the number of logical channels and not
> the actual number of physical channels anyways.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>

A.

> ---
>  arch/arm/mach-omap1/dma.c | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index f6ba589cd312..c821c1d5610e 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -32,7 +32,6 @@
>  #include "soc.h"
>  
>  #define OMAP1_DMA_BASE			(0xfffed800)
> -#define OMAP1_LOGICAL_DMA_CH_COUNT	17
>  
>  static u32 enable_1510_mode;
>  
> @@ -348,8 +347,6 @@ static int __init omap1_system_dma_init(void)
>  		goto exit_iounmap;
>  	}
>  
> -	d->lch_count		= OMAP1_LOGICAL_DMA_CH_COUNT;
> -
>  	/* Valid attributes for omap1 plus processors */
>  	if (cpu_is_omap15xx())
>  		d->dev_caps = ENABLE_1510_MODE;
> @@ -366,13 +363,14 @@ static int __init omap1_system_dma_init(void)
>  	d->dev_caps		|= CLEAR_CSR_ON_READ;
>  	d->dev_caps		|= IS_WORD_16;
>  
> -	if (cpu_is_omap15xx())
> -		d->chan_count = 9;
> -	else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
> -		if (!(d->dev_caps & ENABLE_1510_MODE))
> -			d->chan_count = 16;
> +	/* available logical channels */
> +	if (cpu_is_omap15xx()) {
> +		d->lch_count = 9;
> +	} else {
> +		if (d->dev_caps & ENABLE_1510_MODE)
> +			d->lch_count = 9;
>  		else
> -			d->chan_count = 9;
> +			d->lch_count = 16;
>  	}
>  
>  	p = dma_plat_info;
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ 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