Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] crypto: testmgr: Use linear alias for test input
From: Herbert Xu @ 2016-12-21  8:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482190646-7720-1-git-send-email-labbott@redhat.com>

On Mon, Dec 19, 2016 at 03:37:26PM -0800, Laura Abbott wrote:
> Christopher Covington reported a crash on aarch64 on recent Fedora
> kernels:
> 
> kernel BUG at ./include/linux/scatterlist.h:140!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162
> Hardware name: linux,dummy-virt (DT)
> task: ffff80007c650080 task.stack: ffff800008910000
> PC is at sg_init_one+0xa0/0xb8
> LR is at sg_init_one+0x24/0xb8
> ...
> [<ffff000008398db8>] sg_init_one+0xa0/0xb8
> [<ffff000008350a44>] test_acomp+0x10c/0x438
> [<ffff000008350e20>] alg_test_comp+0xb0/0x118
> [<ffff00000834f28c>] alg_test+0x17c/0x2f0
> [<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
> [<ffff0000080dac70>] kthread+0xf8/0x128
> [<ffff000008082ec0>] ret_from_fork+0x10/0x50
> 
> The test vectors used for input are part of the kernel image. These
> inputs are passed as a buffer to sg_init_one which eventually blows up
> with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
> false for the kernel image since virt_to_page will not return the
> correct page. The kernel image is also aliased to the linear map so get
> the linear alias and pass that to the scatterlist instead.
> 
> Reported-by: Christopher Covington <cov@codeaurora.org>
> Fixes: d7db7a882deb ("crypto: acomp - update testmgr with support for acomp")
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> x86 supports virt_addr_valid working on kernel image addresses but arm64 is
> more strict. This is the direction things have been moving with my
> CONFIG_DEBUG_VIRTUAL series for arm64 which is tightening the definition of
> __pa/__pa_symbol.

Please fix this by copying the templates to kmalloced memory like
the other test_* functions.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
From: Romain Perier @ 2016-12-21  8:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161220161714.GD30952@lunn.ch>

Hi,

Le 20/12/2016 ? 17:17, Andrew Lunn a ?crit :
>>>> +		mdio {
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <0>;
>>>> +			reg = <1>;
>>>
>>> what is this reg value for?
>>>
>>>     Andrew
>>>
>>
>> It was required to avoid a warning thrown by the mdio subsystem
>
> Do you remember what the warning was?
>
> This seems odd to me. I don't see why a reg is needed here.
>
> Thanks
> 	Andrew
>

Mhhh, in fact, I did changes to this mdio node, I relocated it...
the warning was probably before the relocation, because I no longer see 
it. So I have removed this reg value.

Thanks,
Romain

^ permalink raw reply
* [PATCH v3 net-next 0/3] Add support for the ethernet switch on the ESPRESSObin
From: Romain Perier @ 2016-12-21  9:00 UTC (permalink / raw)
  To: linux-arm-kernel

This set of patches adds support for the Marvell ethernet switch 88E6341.
It also add the devicetree definition of this switch to the DT board.

Romain Perier (3):
  net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
    num_of_ports
  net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
  arm64: dts: marvell: Add ethernet switch definition for the
    ESPRESSObin

 .../boot/dts/marvell/armada-3720-espressobin.dts   | 66 ++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/chip.c                   | 48 ++++++++++++++--
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h              |  4 +-
 3 files changed, 111 insertions(+), 7 deletions(-)

-- 
2.9.3

^ permalink raw reply
* [PATCH v3 net-next 1/3] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Romain Perier @ 2016-12-21  9:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221090045.474-1-romain.perier@free-electrons.com>

Some Marvell ethernet switches have internal ethernet transceivers with
hardcoded phy addresses. These addresses can be grearer than the number
of ports or its value might be different than the associated port number.
This is for example the case for MV88E6341 that has 6 ports and internal
Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.

This commits fixes the issue by removing the condition in MDIO callbacks.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---

Changes in v2:
 - Added tag "Reviewed-by" by Andrew
 - Fixed typo in the commit log

 drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b5f0e1e..76d944e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2881,9 +2881,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
 	u16 val;
 	int err;
 
-	if (phy >= mv88e6xxx_num_ports(chip))
-		return 0xffff;
-
 	mutex_lock(&chip->reg_lock);
 	err = mv88e6xxx_phy_read(chip, phy, reg, &val);
 	mutex_unlock(&chip->reg_lock);
@@ -2896,9 +2893,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
 	struct mv88e6xxx_chip *chip = bus->priv;
 	int err;
 
-	if (phy >= mv88e6xxx_num_ports(chip))
-		return 0xffff;
-
 	mutex_lock(&chip->reg_lock);
 	err = mv88e6xxx_phy_write(chip, phy, reg, val);
 	mutex_unlock(&chip->reg_lock);
-- 
2.9.3

^ permalink raw reply related
* [PATCH v3 net-next 2/3] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
From: Romain Perier @ 2016-12-21  9:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221090045.474-1-romain.perier@free-electrons.com>

The Marvell 88E6341 device is single-chip, 6-port ethernet switch with
four integrated 10/100/1000Mbps ethernet transceivers and one high speed
SerDes interfaces. It is compatible with switches of family 88E6352.

This commit adds basic support for this switch by describing its
capabilities to the driver.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---

Changes in v3:
 - Added tag "Reviewed-by" by Andrew
 
Changes in v2:
 - Add a dedicated data structure for the operations of the 88E6341
 - Re-ordered PORT_SWITCH_ID_PROD_NUM_6341 in alphabetic order with other
   macros

 drivers/net/dsa/mv88e6xxx/chip.c      | 42 +++++++++++++++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  4 +++-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 76d944e..5e97dc4 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3625,6 +3625,34 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
 	.reset = mv88e6352_g1_reset,
 };
 
+static const struct mv88e6xxx_ops mv88e6341_ops = {
+	/* MV88E6XXX_FAMILY_6352 */
+	.get_eeprom = mv88e6xxx_g2_get_eeprom16,
+	.set_eeprom = mv88e6xxx_g2_set_eeprom16,
+	.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
+	.phy_read = mv88e6xxx_g2_smi_phy_read,
+	.phy_write = mv88e6xxx_g2_smi_phy_write,
+	.port_set_link = mv88e6xxx_port_set_link,
+	.port_set_duplex = mv88e6xxx_port_set_duplex,
+	.port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
+	.port_set_speed = mv88e6352_port_set_speed,
+	.port_tag_remap = mv88e6095_port_tag_remap,
+	.port_set_frame_mode = mv88e6351_port_set_frame_mode,
+	.port_set_egress_unknowns = mv88e6351_port_set_egress_unknowns,
+	.port_set_ether_type = mv88e6351_port_set_ether_type,
+	.port_jumbo_config = mv88e6165_port_jumbo_config,
+	.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
+	.port_pause_config = mv88e6097_port_pause_config,
+	.stats_snapshot = mv88e6320_g1_stats_snapshot,
+	.stats_get_sset_count = mv88e6095_stats_get_sset_count,
+	.stats_get_strings = mv88e6095_stats_get_strings,
+	.stats_get_stats = mv88e6095_stats_get_stats,
+	.g1_set_cpu_port = mv88e6095_g1_set_cpu_port,
+	.g1_set_egress_port = mv88e6095_g1_set_egress_port,
+	.mgmt_rsvd2cpu = mv88e6095_g2_mgmt_rsvd2cpu,
+	.reset = mv88e6352_g1_reset,
+};
+
 static const struct mv88e6xxx_ops mv88e6350_ops = {
 	/* MV88E6XXX_FAMILY_6351 */
 	.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
@@ -4086,6 +4114,20 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
 		.ops = &mv88e6321_ops,
 	},
 
+	[MV88E6341] = {
+		.prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
+		.family = MV88E6XXX_FAMILY_6352,
+		.name = "Marvell 88E6341",
+		.num_databases = 4096,
+		.num_ports = 6,
+		.port_base_addr = 0x10,
+		.global1_addr = 0x1b,
+		.age_time_coeff = 15000,
+		.tag_protocol = DSA_TAG_PROTO_EDSA,
+		.flags = MV88E6XXX_FLAGS_FAMILY_6352,
+		.ops = &mv88e6341_ops,
+	},
+
 	[MV88E6350] = {
 		.prod_num = PORT_SWITCH_ID_PROD_NUM_6350,
 		.family = MV88E6XXX_FAMILY_6351,
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index af54bae..cb55fdb 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -100,6 +100,7 @@
 #define PORT_SWITCH_ID_PROD_NUM_6240	0x240
 #define PORT_SWITCH_ID_PROD_NUM_6290	0x290
 #define PORT_SWITCH_ID_PROD_NUM_6321	0x310
+#define PORT_SWITCH_ID_PROD_NUM_6341	0x340
 #define PORT_SWITCH_ID_PROD_NUM_6352	0x352
 #define PORT_SWITCH_ID_PROD_NUM_6350	0x371
 #define PORT_SWITCH_ID_PROD_NUM_6351	0x375
@@ -432,6 +433,7 @@ enum mv88e6xxx_model {
 	MV88E6290,
 	MV88E6320,
 	MV88E6321,
+	MV88E6341,
 	MV88E6350,
 	MV88E6351,
 	MV88E6352,
@@ -448,7 +450,7 @@ enum mv88e6xxx_family {
 	MV88E6XXX_FAMILY_6185,	/* 6108 6121 6122 6131 6152 6155 6182 6185 */
 	MV88E6XXX_FAMILY_6320,	/* 6320 6321 */
 	MV88E6XXX_FAMILY_6351,	/* 6171 6175 6350 6351 */
-	MV88E6XXX_FAMILY_6352,	/* 6172 6176 6240 6352 */
+	MV88E6XXX_FAMILY_6352,	/* 6172 6176 6240 6341 6352 */
 	MV88E6XXX_FAMILY_6390,  /* 6190 6190X 6191 6290 6390 6390X */
 };
 
-- 
2.9.3

^ permalink raw reply related
* [PATCH v3 net-next 3/3] arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
From: Romain Perier @ 2016-12-21  9:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221090045.474-1-romain.perier@free-electrons.com>

This defines and enables the Marvell ethernet switch MVE886341 on the
Marvell ESPRESSObin board.

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---

Changes in v3:
 - Changed the node switch0 to be at 1
 - Removed reg=<1> from the mdio node, finally that's not required

Changes in v2:
 - EXPRESSObin -> ESPRESSObin
 - phy nodes definition must contain the internal bus address after the @

 .../boot/dts/marvell/armada-3720-espressobin.dts   | 66 ++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 83178d9..12d9f65 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -80,3 +80,69 @@
 &usb3 {
 	status = "okay";
 };
+
+&mdio {
+	switch0: switch0 at 1 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <1>;
+
+		dsa,member = <0 0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				label = "cpu";
+				ethernet = <&eth0>;
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "wan";
+				phy-handle = <&switch0phy0>;
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan0";
+				phy-handle = <&switch0phy1>;
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "lan1";
+				phy-handle = <&switch0phy2>;
+			};
+
+		};
+
+		mdio {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			switch0phy0: switch0phy0 at 11 {
+				reg = <0x11>;
+			};
+			switch0phy1: switch0phy1 at 12 {
+				reg = <0x12>;
+			};
+			switch0phy2: switch0phy2 at 13 {
+				reg = <0x13>;
+			};
+		};
+	};
+};
+
+&eth0 {
+	phy-mode = "rgmii-id";
+	status = "okay";
+
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
-- 
2.9.3

^ permalink raw reply related
* [PATCH v2] rtc: armada38x: Followed the new recommendation for errata implementation
From: Gregory CLEMENT @ 2016-12-21  9:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221004308.terkq5u5pb2hbcbw@piout.net>

Hi Alexandre,
 
 On mer., d?c. 21 2016, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:


I agree with all your remark expect one, see below:
[...]
>>  	rtc_update_irq(rtc->rtc_dev, 1, event);
>>  
>>  	return IRQ_HANDLED;
>> @@ -221,6 +282,11 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
>>  	if (!rtc)
>>  		return -ENOMEM;
>>  
>> +	rtc->val_to_freq = devm_kcalloc(&pdev->dev, SAMPLE_NR,
>> +				sizeof(struct value_to_freq), GFP_KERNEL);
>> +	if (!rtc->val_to_freq)
>> +		return -ENOMEM;
>> +
>
> The whole struct armada38x_rtc is already allocated just before. Maybe
> you can put the whole array inside the structure instead of doing a new
> allocation.

Actually it was done on purpose. Indeed the same RTC IP is used in the
Armada 3700 (a patch is coming soon), and for this IP this issue was
fixed and we do not need to store 100 read. That's why I want to
allocate the array only if needed.

Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply
* [PATCH v3 net-next 1/3] net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >= num_of_ports
From: Gregory CLEMENT @ 2016-12-21  9:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221090045.474-2-romain.perier@free-electrons.com>

Hi Romain,


it seems there is a remaining typo :)

 On mer., d?c. 21 2016, Romain Perier <romain.perier@free-electrons.com> wrote:

> Some Marvell ethernet switches have internal ethernet transceivers with
> hardcoded phy addresses. These addresses can be grearer than the number
                                                  greater
> of ports or its value might be different than the associated port number.
> This is for example the case for MV88E6341 that has 6 ports and internal
> Port 1 to Port4 PHYs mapped at SMI addresses from 0x11 to 0x14.
>
> This commits fixes the issue by removing the condition in MDIO callbacks.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>
> Changes in v2:
>  - Added tag "Reviewed-by" by Andrew
>  - Fixed typo in the commit log
>
>  drivers/net/dsa/mv88e6xxx/chip.c | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index b5f0e1e..76d944e 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2881,9 +2881,6 @@ static int mv88e6xxx_mdio_read(struct mii_bus *bus, int phy, int reg)
>  	u16 val;
>  	int err;
>  
> -	if (phy >= mv88e6xxx_num_ports(chip))
> -		return 0xffff;
> -
>  	mutex_lock(&chip->reg_lock);
>  	err = mv88e6xxx_phy_read(chip, phy, reg, &val);
>  	mutex_unlock(&chip->reg_lock);
> @@ -2896,9 +2893,6 @@ static int mv88e6xxx_mdio_write(struct mii_bus *bus, int phy, int reg, u16 val)
>  	struct mv88e6xxx_chip *chip = bus->priv;
>  	int err;
>  
> -	if (phy >= mv88e6xxx_num_ports(chip))
> -		return 0xffff;
> -
>  	mutex_lock(&chip->reg_lock);
>  	err = mv88e6xxx_phy_write(chip, phy, reg, val);
>  	mutex_unlock(&chip->reg_lock);
> -- 
> 2.9.3
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply
* [PATCH 3/7] iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
From: Maxime Ripard @ 2016-12-21  9:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <b668c7f1-99ac-f2ba-eaab-f3c0f9e1cfb2@free-electrons.com>

Hi,

On Tue, Dec 20, 2016 at 04:20:04PM +0100, Quentin Schulz wrote:
> >> +	select MFD_SUN4I_GPADC if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I
> > 
> > Why did you change the depends on to a select?
> > 
> 
> The "depends on" does not have an if condition but "select" has. See:
> https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt

I think something like that should work:

depends on (MFD_SUN4I_GPADC && MACH_SUN4I) || MACH_SUN8I

> >> +	depends on THERMAL_OF || MACH_SUN4I || MACH_SUN5I || MACH_SUN6I
> > 
> > So you can't disable THERMAL_OF on MACH_SUN8I?
> > 
> 
> Not in the current state. devm_thermal_zone_of_sensor_register from
> sun4i_gpadc_probe_dt returns an error if THERMAL_OF is disabled and
> thus, the probe fails. Maybe it should rather fail silently and let the
> user choose whether (s)he wants the thermal framework to be able to read
> data from this driver?

I'm usually not a big fan of inconsistencies in the behaviour of
drivers, but let's wait for the second version to discuss that.

> >> +	depends on !TOUCHSCREEN_SUN4I
> > 
> > This should be a different patch.
> > 
> >> +	help
> >> +	  Say yes here to build support for Allwinner (A10, A13, A31 and A33)
> >> +	  SoCs GPADC.
> >> +
> >> +	  The ADC on A10, A13 and A31 provides 4 channels which can be used as
> >> +	  an ADC or as a touchscreen input and one channel for thermal sensor.
> >> +	  Their thermal sensor slows down ADC readings and can be disabled by
> > 
> > Again, I'm not sure putting all those details in the Kconfig help
> > really helps. This is only going to grow with more and more cases, and
> > this isn't something really helpful anyway.
> > 
> 
> Are you suggesting to remove completely the paragraph on why it is
> possible to disable CONFIG_THERMAL_OF for the A10, A13 and A31 or only
> to remove the mention to SoCs?

Both actually :)

> >> @@ -246,6 +269,19 @@ static int sun4i_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
> >>  static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> >>  {
> >>  	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> >> +	int ret;
> >> +
> >> +	if (info->use_dt) {
> >> +		pm_runtime_get_sync(indio_dev->dev.parent);
> >> +
> >> +		ret = regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> >> +		if (!ret)
> >> +			pm_runtime_mark_last_busy(indio_dev->dev.parent);
> >> +
> >> +		pm_runtime_put_autosuspend(indio_dev->dev.parent);
> >> +
> >> +		return 0;
> >> +	}
> > 
> > Why is runtime_pm linked to the DT support or not?
> > 
> >>  
> >>  	return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
> >>  }
> 
> The same runtime_pm functions are called when the driver is not probed
> from DT.
> 
> sun4i_gpadc_read will call sun4i_prepare_for_irq which does a
> pm_runtime_get_sync and then at the end of sun4i_gpadc_read,
> pm_runtime_mark_last_busy and pm_runtime_put_autosuspend are called.
> 
> I just noticed I forgot to add a comment on this one. The A33
> documentation tells us there is an interrupt for the thermal sensor but
> after struggling with it, it is just false. I validated my guess with
> Allwinner Linux kernel which does not wait an interrupt to read the data
> register of the thermal sensor.
> 
> sun4i_gpadc_read always wait for an interrupt before reading data regs,
> so I'm just not calling it and doing the "logic" (reading the data reg
> and interfacing with runtime_pm) directly here in sun4i_gpadc_temp.
> 
> I'll add a comment on this one. Maybe I should create a function just
> for the "logic" of the A33 thermal sensor, so it is less weird than
> currently.

Ok. So this is not really about using the DT or not, but rather
whether you're on an A33 or not. You could probably add a broken_irq
field to test against that.

You should probably share the pm_runtim calls too between the two
cases.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161221/bb0d5df4/attachment.sig>

^ permalink raw reply
* [PATCH 1/1] mm: call force_sig_info before prints
From: Russell King - ARM Linux @ 2016-12-21  9:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221055911epcms5p1146cee9212cc17fa8d5b18c49a085def@epcms5p1>

This is unreadable.  Sorry.

On Wed, Dec 21, 2016 at 05:59:11AM +0000, AMIT NAGAL wrote:
> <HTML><HEAD>
> <META content="text/html; charset=utf-8" http-equiv=Content-Type>
> <STYLE id=mysingle_style type=text/css>.search-word {
> 	BACKGROUND-COLOR: #ffee94
> }
> P {
> 	MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> TD {
> 	MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> LI {
> 	MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> BODY {
> 	FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial
> }
> </STYLE>
> 
> <META content=IE=5 http-equiv=X-UA-Compatible>
> <META content=IE=5 http-equiv=X-UA-Compatible>
> <STYLE id=knox_style type=text/css>P {
> 	MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> </STYLE>
> 
> <META content=IE=5 http-equiv=X-UA-Compatible>
> <META name=GENERATOR content="MSHTML 11.00.9600.18500"></HEAD>
> <BODY>
> <P></P>
> <P>Hello,</P><PRE>On Mon, Dec 19, 2016 at 04:07:12PM +0530, Maninder Singh wrote:
> &gt;&gt; prints can delay queuing of signal, so better to print
> &gt;&gt;after force_sig_info.
> &gt;&gt; 
> &gt;&gt; Let's say process generated SIGSEGV , and some other thread sends
> &gt;&gt; SIGKILL to crashing process and it gets queued before SIGSEGV becuase
> &gt;&gt; of little delay due to prints so in this case coredump might not generate.
> 
> &gt; In any case, that's going to be a race - you can't predict exactly when
> &gt; the "other thread" will send the SIGKILL in relation to the SIGSEGV.
> 
> &gt; So, I don't see the point of this change.</PRE><PRE>Actually SIGSEGV queueing gets delayed in __do_user_fault as logs are printed first(show_pte , show_regs).</PRE><PRE>meanwhile if SIGKILL gets queued , SIGSEGV wont be serviced first and coredump will be skipped . </PRE><PRE>so our intention is to queue the SIGSEGV as early as possible . so that the probability of race between</PRE><PRE>SIGKILL and SIGSEGV can be minimized .</PRE><PRE>Amit</PRE><PRE>&nbsp;</PRE><table id=bannersignimg><tr><td><div id="cafe-note-contents" style="margin:10px;font-family:Arial;font-size:10pt;"><p>&nbsp;</p></div></td></tr></table><table id=confidentialsignimg><tr><td><div id="cafe-note-contents" style="margin:10px;font-family:Arial;font-size:10pt;"><p><img unselectable="on" data-cui-image="true" style="display: inline-block; border: 0px solid; width: 520px; height: 144px;" src="cid:cafe_image_0@s-core.co.kr"><br></p></div></td></tr></table></BODY></HTML><img src='http://ext.samsung.net/mail/ext/v1/external/status/update?userid=amit.nagal&do=bWFpbElEPTIwMTYxMjIxMDU1OTExZXBjbXM1cDExNDZjZWU5MjEyY2MxN2ZhOGQ1YjE4YzQ5YTA4NWRlZiZyZWNpcGllbnRBZGRyZXNzPWxpbnV4QGFybWxpbnV4Lm9yZy51aw__' border=0 width=0 height=0 style='display:none'>


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply
* [RFC]arm64: soft lockup on smp_call_function_many()
From: Yisheng Xie @ 2016-12-21  9:37 UTC (permalink / raw)
  To: linux-arm-kernel

The kernel version is 4.1.34. From the log, we can the pc at function
csd_lock_wait().

We have backport the
commit 8053871d0f7f("smp: Fix smp_call_function_single_async() locking").
So the function is:
static void csd_lock_wait(struct call_single_data *csd)
{
         while (smp_load_acquire(&csd->flags) & CSD_FLAG_LOCK)
                 cpu_relax();
}

Any comment is more than welcome!

Thanks,
Yisheng Xie

-----------
[ 1376.188273] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/u64:0:6]
[ 1376.206461]
[ 1376.218555] CPU: 1 PID: 6 Comm: kworker/u64:0 Tainted: G            E   4.1.34 #2
[ 1376.237292] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS 1.31 06/23/2016
[ 1376.256541] task: ffff802fb9383d40 ti: ffff802fb93c0000 task.ti: ffff802fb93c0000
[ 1376.275552] PC is at smp_call_function_many+0x29c/0x308
[ 1376.293554] LR is at smp_call_function_many+0x268/0x308
[ 1376.311766] pc : [<ffff80000015032c>] lr : [<ffff8000001502f8>] pstate: 80000145
[ 1376.332359] sp : ffff802fb93c3920
[ 1376.349112]
[ 1376.364204] Kernel panic - not syncing: softlockup: hung tasks
[ 1376.384471] CPU: 1 PID: 6 Comm: kworker/u64:0 Tainted: G            EL  4.1.34 #2
[ 1376.406785] Hardware name: Huawei Taishan 2180 /BC11SPCC, BIOS 1.31 06/23/2016
[ 1376.428938] Workqueue: cpuset_migrate_mm cpuset_migrate_mm_workfn
[ 1376.450385] Call trace:
[ 1376.468097] [<ffff80000008ade0>] dump_backtrace+0x0/0x1a0
[ 1376.490023] [<ffff80000008afa0>] show_stack+0x20/0x28
[ 1376.512143] [<ffff800000aa2e78>] dump_stack+0x98/0xb8
[ 1376.533792] [<ffff800000a9fa0c>] panic+0x10c/0x26c
[ 1376.555317] [<ffff800000188430>] watchdog+0x0/0x40
[ 1376.576680] [<ffff800000139850>] __run_hrtimer+0x78/0x298
[ 1376.598112] [<ffff800000139d40>] hrtimer_interrupt+0x108/0x278
[ 1376.620450] [<ffff8000008bdf60>] arch_timer_handler_phys+0x38/0x48
[ 1376.644011] [<ffff8000001258b8>] handle_percpu_devid_irq+0x90/0x238
[ 1376.666911] [<ffff800000120848>] generic_handle_irq+0x40/0x58
[ 1376.689875] [<ffff800000120bc0>] __handle_domain_irq+0x68/0xc0
[ 1376.713403] [<ffff80000008265c>] gic_handle_irq+0xc4/0x1c8
[ 1376.736030] Exception stack(0xffff802fb93c3790 to 0xffff802fb93c38d0)
[ 1376.759750] 3780:                                   0000000000001000 0001000000000000
[ 1376.786014] 37a0: ffff802fb93c3920 ffff80000015032c 0000000080000145 0000000000000001
[ 1376.813028] 37c0: ffff80000014f958 0000000000000000 ffff8000010c8cf8 0000000000000000
[ 1376.840077] 37e0: ffff803fbffc5460 ffff803fbffc5448 000000000000001f ffff8000010c7700
[ 1376.868191] 3800: 000000000000001f ffffffff80000000 0000000000000000 0000000000000000
[ 1376.895959] 3820: 0000000000000002 ffff80000055a118 ffff800000231bb0 0000000000000001
[ 1376.923610] 3840: ffff803fbffe6bc0 0008000000000000 0000000000000000 003b31c87bc2eeba
[ 1376.951284] 3860: ffff80000014f330 0000ffff88dee338 0000ffffefb156e0 ffff802fffebf3c0
[ 1376.978782] 3880: ffff802fffebf3c8 ffff8000010c7000 ffff8000010c8cf8 ffff8000010a1380
[ 1377.006734] 38a0: 0000000000000001 ffff80000014f958 0000000000000000 ffff8000010c8cf8
[ 1377.034031] 38c0: 0000000000000080 ffff802fb93c3920
[ 1377.058023] [<ffff80000008381c>] el1_irq+0x9c/0x140
[ 1377.082904] [<ffff800000150474>] kick_all_cpus_sync+0x34/0x40
[ 1377.103398] [<ffff8000000a085c>] pmdp_splitting_flush+0x5c/0x98
[ 1377.123805] [<ffff800000249d90>] split_huge_page_to_list+0xd8/0xa90
[ 1377.146433] [<ffff80000024b18c>] __split_huge_page_pmd+0xf4/0x330
[ 1377.168313] [<ffff800000231d78>] queue_pages_pte_range+0x1c8/0x1d0
[ 1377.193749] [<ffff80000021f9b0>] __walk_page_range+0x158/0x380
[ 1377.215375] [<ffff80000021fc58>] walk_page_range+0x80/0x100
[ 1377.237044] [<ffff800000231ab4>] queue_pages_range+0x94/0xb8
[ 1377.257681] [<ffff800000232de0>] do_migrate_pages+0x1d0/0x250
[ 1377.278889] [<ffff8000001675f0>] cpuset_migrate_mm_workfn+0x30/0x50
[ 1377.298235] [<ffff8000000e6d30>] process_one_work+0x150/0x430
[ 1377.317808] [<ffff8000000e7158>] worker_thread+0x148/0x4b8
[ 1377.337583] [<ffff8000000ed6e8>] kthread+0x100/0x118
[ 1377.357541] SMP: stopping secondary CPUs
[ 1377.376114] SMP: stopping secondary CPUs
[ 1378.445112] SMP: failed to stop secondary CPUs 0-31
[ 1378.467717] Get irq acitve state failed.
[ 1378.487833] Get irq acitve state failed.
[ 1378.507885] Get irq acitve state failed.
[ 1378.524965] Get irq acitve state failed.
[ 1378.541685] Get irq acitve state failed.
[ 1378.557528] Get irq acitve state failed.
[ 1378.575082] Get irq acitve state failed.
[ 1378.591459] Get irq acitve state failed.
[ 1378.606292] Get irq acitve state failed.
[ 1378.620450] Get irq acitve state failed.
[ 1378.635056] Get irq acitve state failed.
[ 1378.649346] Get irq acitve state failed.
[ 1378.664147] Get irq acitve state failed.
[ 1378.678135] Get irq acitve state failed.
[ 1378.690731] Get irq acitve state failed.
[ 1378.704672] Get irq acitve state failed.
[ 1378.717086] Starting crashdump kernel...
[ 1378.729146] ------------[ cut here ]------------

^ permalink raw reply
* [PATCH v3 net-next 3/3] arm64: dts: marvell: Add ethernet switch definition for the ESPRESSObin
From: Gregory CLEMENT @ 2016-12-21  9:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221090045.474-4-romain.perier@free-electrons.com>

Hi Romain,
 
 On mer., d?c. 21 2016, Romain Perier <romain.perier@free-electrons.com> wrote:

> This defines and enables the Marvell ethernet switch MVE886341 on the
> Marvell ESPRESSObin board.

This patch looks OK now.

Applied on mvebu/dt64-4.11

So you can remove it from you next version because I don't want this
patch will be applied through the netdev branch. Indeed I expect more
changes in this file for v4.11 and it will be easier to have the change
in a single branch to avoid the merge conflict.

Thanks,

Gregory


>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>
> Changes in v3:
>  - Changed the node switch0 to be at 1
>  - Removed reg=<1> from the mdio node, finally that's not required
>
> Changes in v2:
>  - EXPRESSObin -> ESPRESSObin
>  - phy nodes definition must contain the internal bus address after the @
>
>  .../boot/dts/marvell/armada-3720-espressobin.dts   | 66 ++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> index 83178d9..12d9f65 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> @@ -80,3 +80,69 @@
>  &usb3 {
>  	status = "okay";
>  };
> +
> +&mdio {
> +	switch0: switch0 at 1 {
> +		compatible = "marvell,mv88e6085";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <1>;
> +
> +		dsa,member = <0 0>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				label = "cpu";
> +				ethernet = <&eth0>;
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +				label = "wan";
> +				phy-handle = <&switch0phy0>;
> +			};
> +
> +			port at 2 {
> +				reg = <2>;
> +				label = "lan0";
> +				phy-handle = <&switch0phy1>;
> +			};
> +
> +			port at 3 {
> +				reg = <3>;
> +				label = "lan1";
> +				phy-handle = <&switch0phy2>;
> +			};
> +
> +		};
> +
> +		mdio {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			switch0phy0: switch0phy0 at 11 {
> +				reg = <0x11>;
> +			};
> +			switch0phy1: switch0phy1 at 12 {
> +				reg = <0x12>;
> +			};
> +			switch0phy2: switch0phy2 at 13 {
> +				reg = <0x13>;
> +			};
> +		};
> +	};
> +};
> +
> +&eth0 {
> +	phy-mode = "rgmii-id";
> +	status = "okay";
> +
> +	fixed-link {
> +		speed = <1000>;
> +		full-duplex;
> +	};
> +};
> -- 
> 2.9.3
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply
* [PATCH v2] rtc: armada38x: Followed the new recommendation for errata implementation
From: Alexandre Belloni @ 2016-12-21  9:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <87tw9xiri9.fsf@free-electrons.com>

On 21/12/2016 at 10:02:54 +0100, Gregory CLEMENT wrote :
> Hi Alexandre,
>  
>  On mer., d?c. 21 2016, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:
> 
> 
> I agree with all your remark expect one, see below:
> [...]
> >>  	rtc_update_irq(rtc->rtc_dev, 1, event);
> >>  
> >>  	return IRQ_HANDLED;
> >> @@ -221,6 +282,11 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
> >>  	if (!rtc)
> >>  		return -ENOMEM;
> >>  
> >> +	rtc->val_to_freq = devm_kcalloc(&pdev->dev, SAMPLE_NR,
> >> +				sizeof(struct value_to_freq), GFP_KERNEL);
> >> +	if (!rtc->val_to_freq)
> >> +		return -ENOMEM;
> >> +
> >
> > The whole struct armada38x_rtc is already allocated just before. Maybe
> > you can put the whole array inside the structure instead of doing a new
> > allocation.
> 
> Actually it was done on purpose. Indeed the same RTC IP is used in the
> Armada 3700 (a patch is coming soon), and for this IP this issue was
> fixed and we do not need to store 100 read. That's why I want to
> allocate the array only if needed.
> 

Fair enough


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply
* [RFC PATCH] Memory hotplug support for arm64 platform
From: Maciej Bielski @ 2016-12-21  9:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <75156ea7-6e74-27e8-bf29-762f79151d23@broadcom.com>

Hi Scott,

Thanks for testing it and providing us the feedback. For replicating the problem you have reported,
could you provide more info on your system configuration, please?
Among others, few questions that we have in mind are:
* What is the RAM size at boot? Is it multiple of 1GB (or precisely `1<<MIN_MEMORY_BLOCK_SIZE`) ?
* Do you run the kernel with `mem=YYY` option?
* Do you follow steps (1) and (2) for performing the hotplug?
* Do you have any other configuration flags enabled except for CONFIG_MEMORY_HOTPLUG?
* Any other non-defaults?

Up to now the patch was passing our simple tests but if we miss something we will be very thankful
if you could help us to sort it out. If you have found something after your deeper analysis, please
keep us informed.


On 20/12/2016 20:12, Scott Branden wrote:
> Hi Maciej,
>
> I have applied that patch ontop of the patches I previously sent out
> and tested.
>
> It does recognized the memory in /proc/iomem but I get memory corruption of the original system
> RAM soon after.  It appears the page allocation gets corrupted.  I will try to dig into it further
> but if somebody else could try it out in their system to see what results they get it would help.
>
> Regards,
>  Scott
>
> On 16-12-14 04:16 AM, Maciej Bielski wrote:
>> This patch relates to the work previously announced in [1]. This builds on the
>> work by Scott Branden [2] and, henceforth, it needs to be applied on top of
>> Scott's patches [2]. Comments are very welcome.
>>
>> Changes from the original patchset and known issues:
>>
>> - Compared to Scott's original patchset, this work adds the mapping of
>>   the new hotplugged pages into the kernel page tables. This is done by
>>   copying the old swapper_pg_dir over a new page, adding the new mappings,
>>   and then switching to the newly built pg_dir (see `hotplug_paging` in
>>   arch/arm64/mmu.c). There might be better ways to to this: suggestions
>>   are more than welcome.
>>
>> - The stub function for `arch_remove_memory` has been removed for now; we
>>   are working in parallel on memory hot remove, and we plan to contribute
>>   it as a separate patch.
>>
>> - Corresponding Kconfig flags have been added;
>>
>> - Note that this patch does not work when NUMA is enabled; in fact,
>>   the function `memory_add_physaddr_to_nid` does not have an
>>   implementation when the NUMA flag is on: this function is supposed to
>>   return the nid the hotplugged memory should be associated with. However
>>   it is not really clear to us  yet what the semantics of this function
>>   in the context of a NUMA system should be. A quick and dirty fix would
>>   be to always attach to the first available NUMA node.
>>
>> - In arch/arm64/mm/init.c `arch_add_memory`, we are doing a hack with the
>>   nomap memory block flags to satisfy preconditions and postconditions of
>>   `__add_pages` and postconditions of `arch_add_memory`. Compared to
>>   memory hotplug implementation for other architectures, the "issue"
>>   seems to be in the implemenation of `pfn_valid`. Suggestions on how
>>   to cleanly avoid this hack are welcome.
>>
>> This patchset can be tested by starting the kernel with the `mem=X` flag, where
>> X is less than the total available physical memory and has to be multiple of
>> MIN_MEMORY_BLOCK_SIZE. We also tested it on a customised version of QEMU
>> capable to emulate physical hotplug on arm64 platform.
>>
>> To enable the feature the CONFIG_MEMORY_HOTPLUG compilation flag
>> needs to be set to true. Then, after memory is physically hotplugged,
>> the standard two steps to make it available (as also documented in
>> Documentation/memory-hotplug.txt) are:
>>
>> (1) Notify memory hot-add
>>      echo '0xYY000000' > /sys/devices/system/memory/probe
>>
>> where 0xYY000000 is the first physical address of the new memory section.
>>
>> (2) Online new memory block(s)
>>     echo online > /sys/devices/system/memory/memoryXXX/state
>>
>> where XXX corresponds to the ids of newly added blocks.
>>
>> Onlining can optionally be automatic at hot-add notification by enabling
>> the global flag:
>>     echo online > /sys/devices/system/memory/auto_online_blocks
>> or by setting the corresponding config flag in the kernel build.
>>
>> Again, any comment is highly appreciated.
>>
>> [1] https://lkml.org/lkml/2016/11/17/49
>> [2] https://lkml.org/lkml/2016/12/1/811
>>
>> Signed-off-by: Maciej Bielski <m.bielski@virtualopensystems.com>
>> Signed-off-by: Andrea Reale <ar@linux.vnet.ibm.com>
>> ---
>>  arch/arm64/Kconfig           |  4 +--
>>  arch/arm64/include/asm/mmu.h |  3 +++
>>  arch/arm64/mm/init.c         | 58 +++++++++++++++++++++++++++++++-------------
>>  arch/arm64/mm/mmu.c          | 24 ++++++++++++++++++
>>  include/linux/memblock.h     |  1 +
>>  mm/memblock.c                | 10 ++++++++
>>  6 files changed, 80 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 2482fdd..bd8ddf2 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -577,9 +577,7 @@ config HOTPLUG_CPU
>>        can be controlled through /sys/devices/system/cpu.
>>
>>  config ARCH_ENABLE_MEMORY_HOTPLUG
>> -    def_bool y
>> -
>> -config ARCH_ENABLE_MEMORY_HOTREMOVE
>> +    depends on !NUMA
>>      def_bool y
>>
>>  # Common NUMA Features
>> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
>> index 8d9fce0..2499745 100644
>> --- a/arch/arm64/include/asm/mmu.h
>> +++ b/arch/arm64/include/asm/mmu.h
>> @@ -36,5 +36,8 @@ extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
>>                     unsigned long virt, phys_addr_t size,
>>                     pgprot_t prot, bool allow_block_mappings);
>>  extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> +extern void hotplug_paging(phys_addr_t start, phys_addr_t size);
>> +#endif
>>
>>  #endif
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 687d087..a7c740e 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -544,37 +544,61 @@ int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
>>      struct zone *zone;
>>      unsigned long start_pfn = start >> PAGE_SHIFT;
>>      unsigned long nr_pages = size >> PAGE_SHIFT;
>> +    unsigned long end_pfn = start_pfn + nr_pages;
>> +    unsigned long max_sparsemem_pfn = 1UL << (MAX_PHYSMEM_BITS-PAGE_SHIFT);
>> +    unsigned long pfn;
>>      int ret;
>>
>> +    if (end_pfn > max_sparsemem_pfn) {
>> +        pr_err("end_pfn too big");
>> +        return -1;
>> +    }
>> +    hotplug_paging(start, size);
>> +
>> +    /*
>> +     * Mark all the page range as unsuable.
>> +     * This is needed because  __add_section (within __add_pages)
>> +     * wants pfn_valid to be false, and in arm64 pfn falid is implemented
>> +     * by just checking at the nomap flag for existing blocks
>> +     */
>> +    memblock_mark_nomap(start, size);
>> +
>>      pgdat = NODE_DATA(nid);
>>
>>      zone = pgdat->node_zones +
>>          zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
>>      ret = __add_pages(nid, zone, start_pfn, nr_pages);
>>
>> -    if (ret)
>> -        pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
>> -            __func__, ret);
>> +    /*
>> +     * Make the pages usable after they have been added.
>> +     * This will make pfn_valid return true
>> +     */
>> +    memblock_clear_nomap(start, size);
>>
>> -    return ret;
>> -}
>> +    /*
>> +     * This is a hack to avoid having to mix arch specific code into arch
>> +     * independent code. SetPageReserved is supposed to be called by __add_zone
>> +     * (within __add_section, within __add_pages). However, when it is called
>> +     * there, it assumes that pfn_valid returns true.  For the way pfn_valid is
>> +     * implemented in arm64 (a check on the nomap flag), the only way to make
>> +     * this evaluate true inside __add_zone is to clear the nomap flags of
>> +     * blocks in architecture independent code.
>> +     *
>> +     * To avoid this, we set the Reserved flag here after we cleared the nomap
>> +     * flag in the line above.
>> +     */
>> +    for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) {
>> +        if (!pfn_valid(pfn))
>> +            continue;
>>
>> -#ifdef CONFIG_MEMORY_HOTREMOVE
>> -int arch_remove_memory(u64 start, u64 size)
>> -{
>> -    unsigned long start_pfn = start >> PAGE_SHIFT;
>> -    unsigned long nr_pages = size >> PAGE_SHIFT;
>> -    struct zone *zone;
>> -    int ret;
>> +        SetPageReserved(pfn_to_page(pfn));
>> +    }
>>
>> -    zone = page_zone(pfn_to_page(start_pfn));
>> -    ret = __remove_pages(zone, start_pfn, nr_pages);
>>      if (ret)
>> -        pr_warn("%s: Problem encountered in __remove_pages() ret=%d\n",
>> +        pr_warn("%s: Problem encountered in __add_pages() ret=%d\n",
>>              __func__, ret);
>>
>>      return ret;
>>  }
>>  #endif
>> -#endif
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 05615a3..9efa7d1 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -493,6 +493,30 @@ void __init paging_init(void)
>>                SWAPPER_DIR_SIZE - PAGE_SIZE);
>>  }
>>
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> +/*
>> + * hotplug_paging() is used by memory hotplug to build new page tables
>> + * for hot added memory.
>> + */
>> +void hotplug_paging(phys_addr_t start, phys_addr_t size)
>> +{
>> +    phys_addr_t pgd_phys = pgd_pgtable_alloc();
>> +    pgd_t *pgd = pgd_set_fixmap(pgd_phys);
>> +
>> +    memcpy(pgd, swapper_pg_dir, PAGE_SIZE);
>> +
>> +    __create_pgd_mapping(pgd, start, __phys_to_virt(start), size,
>> +            PAGE_KERNEL, pgd_pgtable_alloc, false);
>> +
>> +    cpu_replace_ttbr1(__va(pgd_phys));
>> +    memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
>> +    cpu_replace_ttbr1(swapper_pg_dir);
>> +
>> +    pgd_clear_fixmap();
>> +    memblock_free(pgd_phys, PAGE_SIZE);
>> +}
>> +#endif
>> +
>>  /*
>>   * Check whether a kernel address is valid (derived from arch/x86/).
>>   */
>> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>> index 5b759c9..5f78257 100644
>> --- a/include/linux/memblock.h
>> +++ b/include/linux/memblock.h
>> @@ -92,6 +92,7 @@ int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
>>  int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
>>  int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
>>  int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
>> +int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
>>  ulong choose_memblock_flags(void);
>>
>>  /* Low level functions */
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 7608bc3..05e7676 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -814,6 +814,16 @@ int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
>>  }
>>
>>  /**
>> + * memblock_clear_nomap - Clear a flag of MEMBLOCK_NOMAP memory region
>> + * @base: the base phys addr of the region
>> + * @size: the size of the region
>> + */
>> +int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
>> +{
>> +    return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
>> +}
>> +
>> +/**
>>   * __next_reserved_mem_region - next function for for_each_reserved_region()
>>   * @idx: pointer to u64 loop variable
>>   * @out_start: ptr to phys_addr_t for start address of the region, can be %NULL
>>

BR,

-- 
Maciej Bielski

^ permalink raw reply
* [PATCH 0/2] Cosmetic changes for the SPI driver of ARMADA 3700
From: Romain Perier @ 2016-12-21 10:10 UTC (permalink / raw)
  To: linux-arm-kernel

This set of patches fixes coding style issues reported by checkpatch.pl, then it
includes a second patch that replaces raw values by standardized macro constants.

Romain Perier (2):
  spi: armada-3700: Coding style fixes
  spi: armada-3700: Replaced raw values for nbits by the SPI macros

 drivers/spi/spi-armada-3700.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

-- 
2.9.3

^ permalink raw reply
* [PATCH 1/2] spi: armada-3700: Coding style fixes
From: Romain Perier @ 2016-12-21 10:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221101030.10925-1-romain.perier@free-electrons.com>

The following warning are reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis
+static void a3700_spi_transfer_setup(struct spi_device *spi,
+                                   struct spi_transfer *xfer)

WARNING: Missing a blank line after declarations
+                       u32 data = le32_to_cpu(val);
+                       memcpy(a3700_spi->rx_buf, &data, 4);

total: 0 errors, 1 warnings, 1 checks, 923 lines checked

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 drivers/spi/spi-armada-3700.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c
index ec5fb01..0bfe5ff 100644
--- a/drivers/spi/spi-armada-3700.c
+++ b/drivers/spi/spi-armada-3700.c
@@ -420,7 +420,7 @@ static void a3700_spi_fifo_thres_set(struct a3700_spi *a3700_spi,
 }
 
 static void a3700_spi_transfer_setup(struct spi_device *spi,
-				    struct spi_transfer *xfer)
+				     struct spi_transfer *xfer)
 {
 	struct a3700_spi *a3700_spi;
 	unsigned int byte_len;
@@ -561,6 +561,7 @@ static int a3700_spi_fifo_read(struct a3700_spi *a3700_spi)
 		val = spireg_read(a3700_spi, A3700_SPI_DATA_IN_REG);
 		if (a3700_spi->buf_len >= 4) {
 			u32 data = le32_to_cpu(val);
+
 			memcpy(a3700_spi->rx_buf, &data, 4);
 
 			a3700_spi->buf_len -= 4;
-- 
2.9.3

^ permalink raw reply related
* [PATCH 2/2] spi: armada-3700: Replaced raw values for nbits by the SPI macros
From: Romain Perier @ 2016-12-21 10:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221101030.10925-1-romain.perier@free-electrons.com>

Currently, function a3700_spi_pin_mode_set() configures the SPI transfer
mode according to the value passed as second argument. This value is
detected using the raw values from a switch case.

This commit replaces these raw values by the corresponding macro
constants in linux/spi/spi.h

Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
 drivers/spi/spi-armada-3700.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c
index 0bfe5ff..e598421 100644
--- a/drivers/spi/spi-armada-3700.c
+++ b/drivers/spi/spi-armada-3700.c
@@ -170,12 +170,12 @@ static int a3700_spi_pin_mode_set(struct a3700_spi *a3700_spi,
 	val &= ~(A3700_SPI_DATA_PIN0 | A3700_SPI_DATA_PIN1);
 
 	switch (pin_mode) {
-	case 1:
+	case SPI_NBITS_SINGLE:
 		break;
-	case 2:
+	case SPI_NBITS_DUAL:
 		val |= A3700_SPI_DATA_PIN0;
 		break;
-	case 4:
+	case SPI_NBITS_QUAD:
 		val |= A3700_SPI_DATA_PIN1;
 		break;
 	default:
-- 
2.9.3

^ permalink raw reply related
* [PATCH 0/3] arm perf: Support DEBUG_TEST_DRIVER_REMOVE
From: Alexander Stein @ 2016-12-21 10:19 UTC (permalink / raw)
  To: linux-arm-kernel

Using DEBUG_TEST_DRIVER_REMOVE every driver gets probed, removed and probed
again. This breaks drivers without removal function, e.g. arm perf
resulting in the following dump:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x6c/0x7c
sysfs: cannot create duplicate filename '/devices/armv7_cortex_a7'
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.9.0+ #212
Hardware name: Freescale LS1021A
Backtrace:
[<8020c044>] (dump_backtrace) from [<8020c2f0>] (show_stack+0x18/0x1c)
 r7:00000009 r6:60000013 r5:80c1776c r4:00000000
[<8020c2d8>] (show_stack) from [<8046ead8>] (dump_stack+0x94/0xa8)
[<8046ea44>] (dump_stack) from [<8021ecd0>] (__warn+0xec/0x104)
 r7:00000009 r6:8092efc8 r5:00000000 r4:bf04bd80
[<8021ebe4>] (__warn) from [<8021ed28>] (warn_slowpath_fmt+0x40/0x48)
 r9:80a32848 r8:00000000 r7:00000000 r6:bf0ab780 r5:8091d590 r4:bf0df000
[<8021ecec>] (warn_slowpath_fmt) from [<8036d53c>] (sysfs_warn_dup+0x6c/0x7c)
 r3:bf0df000 r2:8092ef94
[<8036d4d0>] (sysfs_warn_dup) from [<8036d628>] (sysfs_create_dir_ns+0x8c/0x9c)
 r6:bf0ab780 r5:bf20ee08 r4:ffffffef
[<8036d59c>] (sysfs_create_dir_ns) from [<80471860>] (kobject_add_internal+0xa8/0x34c)
 r6:bf0aa198 r5:00000000 r4:bf20ee08
[<804717b8>] (kobject_add_internal) from [<80471b54>] (kobject_add+0x50/0x94)
 r7:00000000 r6:00000000 r5:00000000 r4:bf20ee08
[<80471b08>] (kobject_add) from [<80524590>] (device_add+0xe4/0x590)
 r3:00000000 r2:00000000
 r6:bf20ee00 r5:00000000 r4:bf20ee08
[<805244ac>] (device_add) from [<802a38a8>] (pmu_dev_alloc+0x88/0xd8)
 r10:00000091 r9:80a32848 r8:00000000 r7:80a32840 r6:80c0ed3c r5:00000000
 r4:bf1fe800
[<802a3820>] (pmu_dev_alloc) from [<80a0cd20>] (perf_event_sysfs_init+0x5c/0xb4)
 r7:80a32840 r6:00000000 r5:bf1fe800 r4:80c0ede0
[<80a0ccc4>] (perf_event_sysfs_init) from [<80201778>] (do_one_initcall+0x48/0x178)
 r6:80c45000 r5:80a0ccc4 r4:00000006
[<80201730>] (do_one_initcall) from [<80a00ecc>] (kernel_init_freeable+0x168/0x20c)
 r8:80a00610 r7:80a32840 r6:80c45000 r5:80c45000 r4:00000006
[<80a00d64>] (kernel_init_freeable) from [<806febcc>] (kernel_init+0x10/0x11c)
 r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:806febbc
 r4:00000000
[<806febbc>] (kernel_init) from [<80208388>] (ret_from_fork+0x14/0x2c)
 r5:806febbc r4:00000000
---[ end trace 9d251d389382804f ]---

This patchset add a removal support for arm_pmu and perf_events_v7 and while
at it, use devm_ allocators in arm_pmu.

Alexander Stein (3):
  drivers/perf: arm_pmu: Use devm_ allocators
  drivers/perf: arm_pmu: add arm_pmu_device_remove
  arm: perf: Add platform driver removal function

 arch/arm/kernel/perf_event_v7.c |  6 ++++++
 drivers/perf/arm_pmu.c          | 28 ++++++++++++++++++----------
 include/linux/perf/arm_pmu.h    |  2 ++
 3 files changed, 26 insertions(+), 10 deletions(-)

-- 
2.10.2

^ permalink raw reply
* [PATCH 1/3] drivers/perf: arm_pmu: Use devm_ allocators
From: Alexander Stein @ 2016-12-21 10:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221101935.17178-1-alexander.stein@systec-electronic.com>

This eliminates several calls to kfree.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
 drivers/perf/arm_pmu.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index b37b572..a9bbdbf 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -917,7 +917,8 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
 	bool using_spi = false;
 	struct platform_device *pdev = pmu->plat_device;
 
-	irqs = kcalloc(pdev->num_resources, sizeof(*irqs), GFP_KERNEL);
+	irqs = devm_kcalloc(&pdev->dev, pdev->num_resources, sizeof(*irqs),
+			    GFP_KERNEL);
 	if (!irqs)
 		return -ENOMEM;
 
@@ -939,7 +940,6 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
 				pr_err("PPI/SPI IRQ type mismatch for %s!\n",
 					dn->name);
 				of_node_put(dn);
-				kfree(irqs);
 				return -EINVAL;
 			}
 
@@ -988,10 +988,8 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
 			int ret;
 
 			ret = irq_get_percpu_devid_partition(irq, &pmu->supported_cpus);
-			if (ret) {
-				kfree(irqs);
+			if (ret)
 				return ret;
-			}
 		} else {
 			/* Otherwise default to all CPUs */
 			cpumask_setall(&pmu->supported_cpus);
@@ -1001,8 +999,6 @@ static int of_pmu_irq_cfg(struct arm_pmu *pmu)
 	/* If we matched up the IRQ affinities, use them to route the SPIs */
 	if (using_spi && i == pdev->num_resources)
 		pmu->irq_affinity = irqs;
-	else
-		kfree(irqs);
 
 	return 0;
 }
@@ -1017,7 +1013,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 	struct arm_pmu *pmu;
 	int ret = -ENODEV;
 
-	pmu = kzalloc(sizeof(struct arm_pmu), GFP_KERNEL);
+	pmu = devm_kzalloc(&pdev->dev, sizeof(struct arm_pmu), GFP_KERNEL);
 	if (!pmu) {
 		pr_info("failed to allocate PMU device!\n");
 		return -ENOMEM;
@@ -1074,8 +1070,6 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 out_free:
 	pr_info("%s: failed to register PMU devices!\n",
 		of_node_full_name(node));
-	kfree(pmu->irq_affinity);
-	kfree(pmu);
 	return ret;
 }
 
-- 
2.10.2

^ permalink raw reply related
* [PATCH 2/3] drivers/perf: arm_pmu: add arm_pmu_device_remove
From: Alexander Stein @ 2016-12-21 10:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221101935.17178-1-alexander.stein@systec-electronic.com>

Add ARM PMU removal function. This will be required by perf event drivers
when option DEBUG_TEST_DRIVER_REMOVE is enabled.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
 drivers/perf/arm_pmu.c       | 14 ++++++++++++++
 include/linux/perf/arm_pmu.h |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index a9bbdbf..b7ddc4c 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -1022,6 +1022,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 	armpmu_init(pmu);
 
 	pmu->plat_device = pdev;
+	platform_set_drvdata(pdev, pmu);
 
 	if (node && (of_id = of_match_node(of_table, pdev->dev.of_node))) {
 		init_fn = of_id->data;
@@ -1073,6 +1074,19 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 	return ret;
 }
 
+int arm_pmu_device_remove(struct platform_device *pdev)
+{
+	struct arm_pmu *pmu = platform_get_drvdata(pdev);
+
+	__oprofile_cpu_pmu = NULL;
+
+	perf_pmu_unregister(&pmu->pmu);
+
+	cpu_pmu_destroy(pmu);
+
+	return 0;
+}
+
 static int arm_pmu_hp_init(void)
 {
 	int ret;
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 8462da2..8106f27 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -159,6 +159,8 @@ struct pmu_probe_info {
 int arm_pmu_device_probe(struct platform_device *pdev,
 			 const struct of_device_id *of_table,
 			 const struct pmu_probe_info *probe_table);
+int arm_pmu_device_remove(struct platform_device *pdev);
+
 
 #define ARMV8_PMU_PDEV_NAME "armv8-pmu"
 
-- 
2.10.2

^ permalink raw reply related
* [PATCH 3/3] arm: perf: Add platform driver removal function
From: Alexander Stein @ 2016-12-21 10:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221101935.17178-1-alexander.stein@systec-electronic.com>

Despite the driver cannot be built as a module using the option
DEBUG_TEST_DRIVER_REMOVE requires the drivers to actually remove the
device.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
 arch/arm/kernel/perf_event_v7.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index b942349..3ad02a2 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -2026,12 +2026,18 @@ static int armv7_pmu_device_probe(struct platform_device *pdev)
 				    armv7_pmu_probe_table);
 }
 
+static int armv7_pmu_device_remove(struct platform_device *pdev)
+{
+	return arm_pmu_device_remove(pdev);
+}
+
 static struct platform_driver armv7_pmu_driver = {
 	.driver		= {
 		.name	= "armv7-pmu",
 		.of_match_table = armv7_pmu_of_device_ids,
 	},
 	.probe		= armv7_pmu_device_probe,
+	.remove		= armv7_pmu_device_remove,
 };
 
 static int __init register_armv7_pmu_driver(void)
-- 
2.10.2

^ permalink raw reply related
* [PATCH] ARM: dts: turris-omnia: add support for ethernet switch
From: Uwe Kleine-König @ 2016-12-21 10:20 UTC (permalink / raw)
  To: linux-arm-kernel

The Turris Omnia features a Marvell MV88E7176 ethernet switch. Add it to
the dts.

Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Hello,

when the MAC is operated in rgmii mode and the switch in rgmii-id
communication between them works fine. The other way round it doesn't work.
The fixed-link nodes in the cpu port description is necessary to let the
mv88e6xxx driver use the phy-mode description. Is this a bug?

Regarding the binding, I think the label in the port nodes is strange.

	label = "lan2"

for an external port is fine. But

	label = "cpu"

for a port facing a CPU MAC looks wrong, still more as the Turris Omnia has
two ports connected to the SoC and so there are two ports with the same
label. I would suggest to use a separate property for that, e.g.

	cpu-port;

and no label.

Best regards
Uwe

 arch/arm/boot/dts/armada-385-turris-omnia.dts | 101 +++++++++++++++++++++++++-
 1 file changed, 99 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index ab49acb2d452..6722d3243f9b 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -122,7 +122,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&ge0_rgmii_pins>;
 	status = "okay";
-	phy-mode = "rgmii-id";
+	phy-mode = "rgmii";
 
 	fixed-link {
 		speed = <1000>;
@@ -135,7 +135,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&ge1_rgmii_pins>;
 	status = "okay";
-	phy-mode = "rgmii-id";
+	phy-mode = "rgmii";
 
 	fixed-link {
 		speed = <1000>;
@@ -274,6 +274,103 @@
 	};
 
 	/* Switch MV88E7176 at address 0x10 */
+	switch at 10 {
+		compatible = "marvell,mv88e6085";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dsa,member = <0 0>;
+
+		reg = <0x10>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			ports at 0 {
+				reg = <0>;
+				label = "lan0";
+				phy-handle = <&lan0phy>;
+			};
+
+			ports at 1 {
+				reg = <1>;
+				label = "lan1";
+				phy-handle = <&lan1phy>;
+			};
+
+			ports at 2 {
+				reg = <2>;
+				label = "lan2";
+				phy-handle = <&lan2phy>;
+			};
+
+			ports at 3 {
+				reg = <3>;
+				label = "lan3";
+				phy-handle = <&lan3phy>;
+			};
+
+			ports at 4 {
+				reg = <4>;
+				label = "lan4";
+				phy-handle = <&lan4phy>;
+			};
+
+			ports at 5 {
+				reg = <5>;
+				label = "cpu";
+				ethernet = <&eth1>;
+				phy-mode = "rgmii-id";
+
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			ports at 6 {
+				reg = <6>;
+				label = "cpu";
+				ethernet = <&eth0>;
+				phy-mode = "rgmii-id";
+
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+
+		mdio {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			lan0phy: ethernet-phy at 0 {
+				compatible = "ethernet-phy-ieee802.3-c22";
+				reg = <0>;
+			};
+
+			lan1phy: ethernet-phy at 1 {
+				compatible = "ethernet-phy-ieee802.3-c22";
+				reg = <1>;
+			};
+
+			lan2phy: ethernet-phy at 2 {
+				compatible = "ethernet-phy-ieee802.3-c22";
+				reg = <2>;
+			};
+
+			lan3phy: ethernet-phy at 3 {
+				compatible = "ethernet-phy-ieee802.3-c22";
+				reg = <3>;
+			};
+
+			lan4phy: ethernet-phy at 4 {
+				compatible = "ethernet-phy-ieee802.3-c22";
+				reg = <4>;
+			};
+		};
+	};
 };
 
 &pinctrl {
-- 
2.11.0

^ permalink raw reply related
* [PATCHv2 0/3] arm64/clk: update Marvell Armada CP110 system controller driver
From: Thomas Petazzoni @ 2016-12-21 10:26 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

This small set of commits updates the Marvell Armada CP110 system
controller driver, its Device Tree binding, and Device Tree
representation, to take into account three new things:

 - The clock driver now handles clock n?9 (GOP) as a child of clock
   n?18 (controls SD/MMC and GOP)

 - The DT representation is adjusted to name clock n?18 "sd-mmc-gop"
   instead of just "sd-mmc".

 - The clock driver now handles clock n?5 (MG) as a child of clock n?6
   (MG_CORE).

This set of commits is some preparation work to add networking support
for Marvell Armada 7K/8K.

I would expect patches 1 and 2 to be taken by the clock maintainers,
and patch 3 be taken by the Marvell EBU maintainers.

Changes since v1:

 - Addition of the handling of the MG and MG_CORE clocks (n?5 and
   n?6), also needed for the networking support on Marvell Aramda
   7K/8K.

Thanks,

Thomas

Thomas Petazzoni (3):
  dt-bindings: arm: update Armada CP110 system controller binding
  clk: mvebu: adjust clock handling for the CP110 system controller
  arm64: dts: marvell: adjust name of sd-mmc-gop clock in syscon

 .../bindings/arm/marvell/cp110-system-controller0.txt       |  6 +++---
 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi        |  2 +-
 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi         |  2 +-
 drivers/clk/mvebu/cp110-system-controller.c                 | 13 +++++++++++--
 4 files changed, 16 insertions(+), 7 deletions(-)

-- 
2.7.4

^ permalink raw reply
* [PATCHv2 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Thomas Petazzoni @ 2016-12-21 10:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482316017-22154-1-git-send-email-thomas.petazzoni@free-electrons.com>

It turns out that in the CP110 HW block present in Marvell Armada
7K/8K SoCs, gatable clock n?18 not only controls SD/MMC, but also the
GOP block. This commit updates the Device Tree binding for this piece
of hardware accordingly.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../devicetree/bindings/arm/marvell/cp110-system-controller0.txt    | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
index 30c5469..07dbb35 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
@@ -45,7 +45,7 @@ The following clocks are available:
    - 1 15	SATA
    - 1 16	SATA USB
    - 1 17	Main
-   - 1 18	SD/MMC
+   - 1 18	SD/MMC/GOP
    - 1 21	Slow IO (SPI, NOR, BootROM, I2C, UART)
    - 1 22	USB3H0
    - 1 23	USB3H1
@@ -65,7 +65,7 @@ Required properties:
 	"cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
 	"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
 	"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
-	"cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+	"cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
 	"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
 
 Example:
@@ -78,6 +78,6 @@ Example:
 		gate-clock-output-names = "cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
 			"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
 			"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
-			"cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+			"cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
 			"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
 	};
-- 
2.7.4

^ permalink raw reply related
* [PATCHv2 2/3] clk: mvebu: adjust clock handling for the CP110 system controller
From: Thomas Petazzoni @ 2016-12-21 10:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482316017-22154-1-git-send-email-thomas.petazzoni@free-electrons.com>

This commit:

 - makes the GOP_DP (bit 9) gatable clock a child clock of the
   SD_MMC_GOP (bit 18) clock, as it should have been. The clock for bit
   18 was just named SD_MMC, but since it also covers the GOP block, it
   is renamed SD_MMC_GOP.

 - makes the MG (bit 5) gatable clock a child clock of the MG_CORE
   clock (bit 6)

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 drivers/clk/mvebu/cp110-system-controller.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index f2303da..8038b93 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -64,8 +64,11 @@ enum {
 #define CP110_GATE_NAND			2
 #define CP110_GATE_PPV2			3
 #define CP110_GATE_SDIO			4
+#define CP110_GATE_MG			5
+#define CP110_GATE_MG_CORE		6
 #define CP110_GATE_XOR1			7
 #define CP110_GATE_XOR0			8
+#define CP110_GATE_GOP_DP		9
 #define CP110_GATE_PCIE_X1_0		11
 #define CP110_GATE_PCIE_X1_1		12
 #define CP110_GATE_PCIE_X4		13
@@ -73,7 +76,7 @@ enum {
 #define CP110_GATE_SATA			15
 #define CP110_GATE_SATA_USB		16
 #define CP110_GATE_MAIN			17
-#define CP110_GATE_SDMMC		18
+#define CP110_GATE_SDMMC_GOP		18
 #define CP110_GATE_SLOW_IO		21
 #define CP110_GATE_USB3H0		22
 #define CP110_GATE_USB3H1		23
@@ -302,6 +305,11 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
 						      "gate-clock-output-names",
 						      CP110_GATE_MAIN, &parent);
 			break;
+		case CP110_GATE_MG:
+			of_property_read_string_index(np,
+						      "gate-clock-output-names",
+						      CP110_GATE_MG_CORE, &parent);
+			break;
 		case CP110_GATE_NAND:
 			parent = nand_name;
 			break;
@@ -309,9 +317,10 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
 			parent = ppv2_name;
 			break;
 		case CP110_GATE_SDIO:
+		case CP110_GATE_GOP_DP:
 			of_property_read_string_index(np,
 						      "gate-clock-output-names",
-						      CP110_GATE_SDMMC, &parent);
+						      CP110_GATE_SDMMC_GOP, &parent);
 			break;
 		case CP110_GATE_XOR1:
 		case CP110_GATE_XOR0:
-- 
2.7.4

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