Hi,
We have supported the emac for RK3066/RK3188, but the RK3036 have some
configuration different with them. We should let the driver of emac_rockchip
compatible with other Rockchip SoCs.
Xing Zheng (4):
net: ethernet: arc: Probe emac after set RMII clock
net: ethernet: arc: Keep emac compatibility for more Rockchip SoCs
net: ethernet: arc: Add support emac for RK3036
ARM: dts: rockchip: Add support emac for RK3036
arch/arm/boot/dts/rk3036-evb.dts | 25 +++++++++
arch/arm/boot/dts/rk3036-kylin.dts | 23 ++++++++
arch/arm/boot/dts/rk3036.dtsi | 32 +++++++++++
drivers/net/ethernet/arc/Kconfig | 4 +-
drivers/net/ethernet/arc/emac_rockchip.c | 86 ++++++++++++++++++++----------
5 files changed, 140 insertions(+), 30 deletions(-)
--
1.7.9.5
After enter arc_emac_probe, emac will get_phy_id, phy_poll_reset and
other connecting PHY via mdiobus_read, so we need to set correct
ref clock rate for emac before probe emac.
Signed-off-by: Xing Zheng <[email protected]>
---
drivers/net/ethernet/arc/emac_rockchip.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index c31c740..36e9eb1 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -164,10 +164,6 @@ static int emac_rockchip_probe(struct platform_device *pdev)
}
}
- err = arc_emac_probe(ndev, interface);
- if (err)
- goto out_regulator_disable;
-
/* write-enable bits */
data = GRF_MODE_ENABLE_BIT | GRF_SPEED_ENABLE_BIT;
@@ -184,6 +180,13 @@ static int emac_rockchip_probe(struct platform_device *pdev)
err = clk_set_rate(priv->refclk, 50000000);
if (err)
dev_err(dev, "failed to change reference clock rate (%d)\n", err);
+
+ err = arc_emac_probe(ndev, interface);
+ if (err) {
+ dev_err(dev, "failed to probe arc emac (%d)\n", err);
+ goto out_regulator_disable;
+ }
+
return 0;
out_regulator_disable:
--
1.7.9.5
On the RK3066/RK3188, there was fixed GRF offset configuration to set emac
and fixed DIV2 mac TX/RX clock. So, we need to easily set and fit to other
SoCs (RK3036) which maybe have different GRF offset, and need adjust mac
TX/RX clock.
Signed-off-by: Xing Zheng <[email protected]>
---
drivers/net/ethernet/arc/emac_rockchip.c | 66 ++++++++++++++++++++----------
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index 36e9eb1..d1a9c28 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -25,17 +25,13 @@
#include "emac.h"
#define DRV_NAME "rockchip_emac"
-#define DRV_VERSION "1.0"
-
-#define GRF_MODE_MII (1UL << 0)
-#define GRF_MODE_RMII (0UL << 0)
-#define GRF_SPEED_10M (0UL << 1)
-#define GRF_SPEED_100M (1UL << 1)
-#define GRF_SPEED_ENABLE_BIT (1UL << 17)
-#define GRF_MODE_ENABLE_BIT (1UL << 16)
+#define DRV_VERSION "1.1"
struct emac_rockchip_soc_data {
- int grf_offset;
+ unsigned int grf_offset;
+ unsigned int grf_mode_offset;
+ unsigned int grf_speed_offset;
+ bool need_div_macclk;
};
struct rockchip_priv_data {
@@ -44,23 +40,22 @@ struct rockchip_priv_data {
const struct emac_rockchip_soc_data *soc_data;
struct regulator *regulator;
struct clk *refclk;
+ struct clk *macclk;
};
static void emac_rockchip_set_mac_speed(void *priv, unsigned int speed)
{
struct rockchip_priv_data *emac = priv;
+ u32 speed_offset = emac->soc_data->grf_speed_offset;
u32 data;
int err = 0;
- /* write-enable bits */
- data = GRF_SPEED_ENABLE_BIT;
-
switch(speed) {
case 10:
- data |= GRF_SPEED_10M;
+ data = (1 << (speed_offset + 16)) | (0 << speed_offset);
break;
case 100:
- data |= GRF_SPEED_100M;
+ data = (1 << (speed_offset + 16)) | (1 << speed_offset);
break;
default:
pr_err("speed %u not supported\n", speed);
@@ -73,8 +68,14 @@ static void emac_rockchip_set_mac_speed(void *priv, unsigned int speed)
}
static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
- { .grf_offset = 0x154 }, /* rk3066 */
- { .grf_offset = 0x0a4 }, /* rk3188 */
+ {
+ .grf_offset = 0x154, .grf_mode_offset = 0,
+ .grf_speed_offset = 1, .need_div_macclk = 0
+ }, /* rk3066 */
+ {
+ .grf_offset = 0x0a4, .grf_mode_offset = 0,
+ .grf_speed_offset = 1, .need_div_macclk = 0
+ }, /* rk3188 */
};
static const struct of_device_id emac_rockchip_dt_ids[] = {
@@ -110,7 +111,7 @@ static int emac_rockchip_probe(struct platform_device *pdev)
interface = of_get_phy_mode(dev->of_node);
- /* RK3066 and RK3188 SoCs only support RMII */
+ /* RK3036/RK3066/RK3188 SoCs only support RMII */
if (interface != PHY_INTERFACE_MODE_RMII) {
dev_err(dev, "unsupported phy interface mode %d\n", interface);
err = -ENOTSUPP;
@@ -164,11 +165,12 @@ static int emac_rockchip_probe(struct platform_device *pdev)
}
}
- /* write-enable bits */
- data = GRF_MODE_ENABLE_BIT | GRF_SPEED_ENABLE_BIT;
-
- data |= GRF_SPEED_100M;
- data |= GRF_MODE_RMII;
+ /* Set speed 100M */
+ data = (1 << (priv->soc_data->grf_speed_offset + 16)) |
+ (1 << priv->soc_data->grf_speed_offset);
+ /* Set RMII mode */
+ data |= (1 << (priv->soc_data->grf_mode_offset + 16)) |
+ (0 << priv->soc_data->grf_mode_offset);
err = regmap_write(priv->grf, priv->soc_data->grf_offset, data);
if (err) {
@@ -181,6 +183,26 @@ static int emac_rockchip_probe(struct platform_device *pdev)
if (err)
dev_err(dev, "failed to change reference clock rate (%d)\n", err);
+ if (priv->soc_data->need_div_macclk) {
+ priv->macclk = devm_clk_get(dev, "macclk");
+ if (IS_ERR(priv->macclk)) {
+ dev_err(dev, "failed to retrieve mac clock (%ld)\n", PTR_ERR(priv->macclk));
+ err = PTR_ERR(priv->macclk);
+ goto out_regulator_disable;
+ }
+
+ err = clk_prepare_enable(priv->macclk);
+ if (err) {
+ dev_err(dev, "failed to enable mac clock (%d)\n", err);
+ goto out_regulator_disable;
+ }
+
+ /* RMII TX/RX needs always a rate of 25MHz */
+ err = clk_set_rate(priv->macclk, 25000000);
+ if (err)
+ dev_err(dev, "failed to change mac clock rate (%d)\n", err);
+ }
+
err = arc_emac_probe(ndev, interface);
if (err) {
dev_err(dev, "failed to probe arc emac (%d)\n", err);
--
1.7.9.5
The RK3036's GRFs offset are different with RK3066/RK3188, and need to set
mac TX/RX clock before probe emac.
Signed-off-by: Xing Zheng <[email protected]>
---
drivers/net/ethernet/arc/Kconfig | 4 ++--
drivers/net/ethernet/arc/emac_rockchip.c | 9 +++++++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index 52a6b16..6890451 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -34,9 +34,9 @@ config EMAC_ROCKCHIP
select ARC_EMAC_CORE
depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA
---help---
- Support for Rockchip RK3066/RK3188 EMAC ethernet controllers.
+ Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
This selects Rockchip SoC glue layer support for the
- emac device driver. This driver is used for RK3066/RK3188
+ emac device driver. This driver is used for RK3036/RK3066/RK3188
EMAC ethernet controller.
endif # NET_VENDOR_ARC
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index d1a9c28..2433eeb 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -69,6 +69,10 @@ static void emac_rockchip_set_mac_speed(void *priv, unsigned int speed)
static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
{
+ .grf_offset = 0x140, .grf_mode_offset = 8,
+ .grf_speed_offset = 9, .need_div_macclk = 1
+ }, /* rk3036 */
+ {
.grf_offset = 0x154, .grf_mode_offset = 0,
.grf_speed_offset = 1, .need_div_macclk = 0
}, /* rk3066 */
@@ -79,8 +83,9 @@ static const struct emac_rockchip_soc_data emac_rockchip_dt_data[] = {
};
static const struct of_device_id emac_rockchip_dt_ids[] = {
- { .compatible = "rockchip,rk3066-emac", .data = &emac_rockchip_dt_data[0] },
- { .compatible = "rockchip,rk3188-emac", .data = &emac_rockchip_dt_data[1] },
+ { .compatible = "rockchip,rk3036-emac", .data = &emac_rockchip_dt_data[0] },
+ { .compatible = "rockchip,rk3066-emac", .data = &emac_rockchip_dt_data[1] },
+ { .compatible = "rockchip,rk3188-emac", .data = &emac_rockchip_dt_data[2] },
{ /* Sentinel */ }
};
--
1.7.9.5
This patch describe the emac, and we need to let mac clock under
the APLL which is able to provide the accurate 50MHz what mac_ref
need.
Signed-off-by: Xing Zheng <[email protected]>
---
arch/arm/boot/dts/rk3036-evb.dts | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/rk3036-kylin.dts | 23 +++++++++++++++++++++++
arch/arm/boot/dts/rk3036.dtsi | 32 ++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
index 28a0336..69b96e6 100644
--- a/arch/arm/boot/dts/rk3036-evb.dts
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -62,3 +62,28 @@
&uart2 {
status = "okay";
};
+
+&emac {
+ assigned-clocks = <&cru SCLK_MACPLL>;
+ assigned-clock-parents = <&cru PLL_APLL>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+ phy = <&phy0>;
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&pinctrl {
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
+ emac {
+ rmii_rst: rmii-rst {
+ rockchip,pins = <2 22 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts
index 992f9ca..3fb1cfe 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -285,7 +285,24 @@
status = "okay";
};
+&emac {
+ assigned-clocks = <&cru SCLK_MACPLL>;
+ assigned-clock-parents = <&cru PLL_APLL>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+ phy = <&phy0>;
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
&pinctrl {
+ pcfg_output_high: pcfg-output-high {
+ output-high;
+ };
+
pmic {
pmic_int: pmic-int {
rockchip,pins = <2 2 RK_FUNC_GPIO &pcfg_pull_default>;
@@ -297,4 +314,10 @@
rockchip,pins = <2 7 RK_FUNC_1 &pcfg_pull_none>;
};
};
+
+ emac {
+ rmii_rst: rmii-rst {
+ rockchip,pins = <2 22 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index b9567c1..0c09fb3 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -186,6 +186,20 @@
status = "disabled";
};
+ emac: ethernet@10200000 {
+ compatible = "rockchip,rk3036-emac", "snps,arc-emac";
+ reg = <0x10200000 0x4000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rockchip,grf = <&grf>;
+ clocks = <&cru HCLK_MAC>, <&cru SCLK_MACREF>, <&cru SCLK_MAC>;
+ clock-names = "hclk", "macref", "macclk";
+ max-speed = <100>;
+ phy-mode = "rmii";
+ status = "disabled";
+ };
+
sdmmc: dwmmc@10214000 {
compatible = "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc";
reg = <0x10214000 0x4000>;
@@ -556,6 +570,24 @@
};
};
+ emac {
+ emac_xfer: emac-xfer {
+ rockchip,pins = <2 10 RK_FUNC_1 &pcfg_pull_none>, /* crs_dvalid */
+ <2 13 RK_FUNC_1 &pcfg_pull_none>, /* tx_en */
+ <2 14 RK_FUNC_1 &pcfg_pull_none>, /* mac_clk */
+ <2 15 RK_FUNC_1 &pcfg_pull_none>, /* rx_err */
+ <2 16 RK_FUNC_1 &pcfg_pull_none>, /* rxd1 */
+ <2 17 RK_FUNC_1 &pcfg_pull_none>, /* rxd0 */
+ <2 18 RK_FUNC_1 &pcfg_pull_none>, /* txd1 */
+ <2 19 RK_FUNC_1 &pcfg_pull_none>; /* txd0 */
+ };
+
+ emac_mdio: emac-mdio {
+ rockchip,pins = <2 12 RK_FUNC_1 &pcfg_pull_none>, /* mac_md */
+ <2 25 RK_FUNC_1 &pcfg_pull_none>; /* mac_mdclk */
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>,
--
1.7.9.5
You have to submit this series properly, the same problem happend twice
now.
When you submit a series you should:
1) Make it clear which tree you expect these changes to be applied
to. Here it is completely ambiguous, do you want it to go into
my networking tree or some other subsystem tree?
2) You MUST keep all parties informed about all patches for a series
like this. That means you cannot drop netdev from patch #4 as
you did both times. Doing this aggravates the situation for
#1 even more, because if a patch is not CC:'d to netdev it does
not enter patchwork. And if it doesn't go into patchwork, I'm
not looking at it.
Thanks.
Hi Dave,
Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
> You have to submit this series properly, the same problem happend twice
> now.
>
> When you submit a series you should:
>
> 1) Make it clear which tree you expect these changes to be applied
> to. Here it is completely ambiguous, do you want it to go into
> my networking tree or some other subsystem tree?
>
> 2) You MUST keep all parties informed about all patches for a series
> like this. That means you cannot drop netdev from patch #4 as
> you did both times. Doing this aggravates the situation for
> #1 even more, because if a patch is not CC:'d to netdev it does
> not enter patchwork. And if it doesn't go into patchwork, I'm
> not looking at it.
I guess that is some unfortunate result of git send-email combined with
get_maintainer.pl . In general I also prefer to see the whole series, but have
gotten such partial series from other maintainers as well in the past, so it
seems to be depending on preferences somewhat.
For the series at hand, the 4th patch is the devicetree addition, which the
expected way is me picking it up, after you are comfortable with the code-
related changes.
Heiko
On December 29, 2015 2:27:55 PM PST, "Heiko Stübner" <[email protected]> wrote:
>Hi Dave,
>
>Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend
>twice
>> now.
>>
>> When you submit a series you should:
>>
>> 1) Make it clear which tree you expect these changes to be applied
>> to. Here it is completely ambiguous, do you want it to go into
>> my networking tree or some other subsystem tree?
>>
>> 2) You MUST keep all parties informed about all patches for a series
>> like this. That means you cannot drop netdev from patch #4 as
>> you did both times. Doing this aggravates the situation for
>> #1 even more, because if a patch is not CC:'d to netdev it does
>> not enter patchwork. And if it doesn't go into patchwork, I'm
>> not looking at it.
>
>I guess that is some unfortunate result of git send-email combined with
>
>get_maintainer.pl . In general I also prefer to see the whole series,
>but have
>gotten such partial series from other maintainers as well in the past,
>so it
>seems to be depending on preferences somewhat.
You could run get_maintainer.pl against the individual patches in the series, merge the cc list somewhere in a file/variable and then do the actual mail submission with that full list for all patches. There could be a way to automate that with a bit of help from git send-email eventually.
--
Florian
On December 27, 2015 11:22:20 PM PST, Xing Zheng <[email protected]> wrote:
>The RK3036's GRFs offset are different with RK3066/RK3188, and need to
>set
>mac TX/RX clock before probe emac.
>
>Signed-off-by: Xing Zheng <[email protected]>
>---
<snip>
> };
>
> static const struct of_device_id emac_rockchip_dt_ids[] = {
>- { .compatible = "rockchip,rk3066-emac", .data =
>&emac_rockchip_dt_data[0] },
>- { .compatible = "rockchip,rk3188-emac", .data =
>&emac_rockchip_dt_data[1] },
>+ { .compatible = "rockchip,rk3036-emac", .data =
>&emac_rockchip_dt_data[0] },
>+ { .compatible = "rockchip,rk3066-emac", .data =
>&emac_rockchip_dt_data[1] },
>+ { .compatible = "rockchip,rk3188-emac", .data =
>&emac_rockchip_dt_data[2] },
> { /* Sentinel */ }
Food for thought, you might want to use an enum here to index emac_rockchip_dt_data which would be less error prone if you add/remove entries in this structure.
--
Florian
Am Dienstag, 29. Dezember 2015, 14:59:59 schrieb Florian Fainelli:
> On December 27, 2015 11:22:20 PM PST, Xing Zheng <[email protected]>
wrote:
> >The RK3036's GRFs offset are different with RK3066/RK3188, and need to
> >set
> >mac TX/RX clock before probe emac.
> >
> >Signed-off-by: Xing Zheng <[email protected]>
> >---
>
> <snip>
>
> > };
> >
> > static const struct of_device_id emac_rockchip_dt_ids[] = {
> >
> >- { .compatible = "rockchip,rk3066-emac", .data =
> >&emac_rockchip_dt_data[0] },
> >- { .compatible = "rockchip,rk3188-emac", .data =
> >&emac_rockchip_dt_data[1] },
> >+ { .compatible = "rockchip,rk3036-emac", .data =
> >&emac_rockchip_dt_data[0] },
> >+ { .compatible = "rockchip,rk3066-emac", .data =
> >&emac_rockchip_dt_data[1] },
> >+ { .compatible = "rockchip,rk3188-emac", .data =
> >&emac_rockchip_dt_data[2] },
> >
> > { /* Sentinel */ }
>
> Food for thought, you might want to use an enum here to index
> emac_rockchip_dt_data which would be less error prone if you add/remove
> entries in this structure.
Or just have the structs separately and not in array-form at all, aka
rk3066_emac_dt_data, rk3036_emac_dt_data.
I don't think the original array really improves anything.
From: Heiko St?bner <[email protected]>
Date: Tue, 29 Dec 2015 23:27:55 +0100
> Hi Dave,
>
> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend twice
>> now.
>>
>> When you submit a series you should:
>>
>> 1) Make it clear which tree you expect these changes to be applied
>> to. Here it is completely ambiguous, do you want it to go into
>> my networking tree or some other subsystem tree?
>>
>> 2) You MUST keep all parties informed about all patches for a series
>> like this. That means you cannot drop netdev from patch #4 as
>> you did both times. Doing this aggravates the situation for
>> #1 even more, because if a patch is not CC:'d to netdev it does
>> not enter patchwork. And if it doesn't go into patchwork, I'm
>> not looking at it.
>
> I guess that is some unfortunate result of git send-email combined with
> get_maintainer.pl . In general I also prefer to see the whole series, but have
> gotten such partial series from other maintainers as well in the past, so it
> seems to be depending on preferences somewhat.
>
> For the series at hand, the 4th patch is the devicetree addition, which the
> expected way is me picking it up, after you are comfortable with the code-
> related changes.
Why would it not be appropriate for a DT file change to go into my tree
if it corresponds to functionality created by the rest of the patches
in the series?
It looks better to put it all together as a unit, via one series, with
a merge commit containing your "[PATCH 0/N]" description in the commit
message.
Hi David,
On Wed, Dec 30, 2015 at 2:48 AM, David Miller <[email protected]> wrote:
> From: Heiko Stübner <[email protected]>
> Date: Tue, 29 Dec 2015 23:27:55 +0100
>> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>>> You have to submit this series properly, the same problem happend twice
>>> now.
>>>
>>> When you submit a series you should:
>>>
>>> 1) Make it clear which tree you expect these changes to be applied
>>> to. Here it is completely ambiguous, do you want it to go into
>>> my networking tree or some other subsystem tree?
>>>
>>> 2) You MUST keep all parties informed about all patches for a series
>>> like this. That means you cannot drop netdev from patch #4 as
>>> you did both times. Doing this aggravates the situation for
>>> #1 even more, because if a patch is not CC:'d to netdev it does
>>> not enter patchwork. And if it doesn't go into patchwork, I'm
>>> not looking at it.
>>
>> I guess that is some unfortunate result of git send-email combined with
>> get_maintainer.pl . In general I also prefer to see the whole series, but have
>> gotten such partial series from other maintainers as well in the past, so it
>> seems to be depending on preferences somewhat.
>>
>> For the series at hand, the 4th patch is the devicetree addition, which the
>> expected way is me picking it up, after you are comfortable with the code-
>> related changes.
>
> Why would it not be appropriate for a DT file change to go into my tree
> if it corresponds to functionality created by the rest of the patches
> in the series?
Because the DT change is very likely to conflict with other DT changes.
That's why typically all DT changes go in through the platform/architecture
maintainer.
> It looks better to put it all together as a unit, via one series, with
> a merge commit containing your "[PATCH 0/N]" description in the commit
> message.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Dec 30, 2015 at 4:17 AM, Geert Uytterhoeven
<[email protected]> wrote:
> Hi David,
>
> On Wed, Dec 30, 2015 at 2:48 AM, David Miller <[email protected]> wrote:
>> From: Heiko Stübner <[email protected]>
>> Date: Tue, 29 Dec 2015 23:27:55 +0100
>>> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>>>> You have to submit this series properly, the same problem happend twice
>>>> now.
>>>>
>>>> When you submit a series you should:
>>>>
>>>> 1) Make it clear which tree you expect these changes to be applied
>>>> to. Here it is completely ambiguous, do you want it to go into
>>>> my networking tree or some other subsystem tree?
>>>>
>>>> 2) You MUST keep all parties informed about all patches for a series
>>>> like this. That means you cannot drop netdev from patch #4 as
>>>> you did both times. Doing this aggravates the situation for
>>>> #1 even more, because if a patch is not CC:'d to netdev it does
>>>> not enter patchwork. And if it doesn't go into patchwork, I'm
>>>> not looking at it.
>>>
>>> I guess that is some unfortunate result of git send-email combined with
>>> get_maintainer.pl . In general I also prefer to see the whole series, but have
>>> gotten such partial series from other maintainers as well in the past, so it
>>> seems to be depending on preferences somewhat.
>>>
>>> For the series at hand, the 4th patch is the devicetree addition, which the
>>> expected way is me picking it up, after you are comfortable with the code-
>>> related changes.
>>
>> Why would it not be appropriate for a DT file change to go into my tree
>> if it corresponds to functionality created by the rest of the patches
>> in the series?
>
> Because the DT change is very likely to conflict with other DT changes.
> That's why typically all DT changes go in through the platform/architecture
> maintainer.
I assume you mean DTS changes only here. Send the DTS changes as a
separate series/patch as there is not inter-dependency (if there is,
there is a problem with the change) with DTS changes. I expect the
sub-arch maintainers to be the main reviewers of DTS files anyway. If
there is a binding doc change, then I'd prefer that to be merged with
the driver.
Rob