[linux-sunxi] Re: [PATCH v7 0/6] Add support for Orange Pi 3

2019-06-24 Thread David Miller 
From: Ondřej Jirman 
Date: Mon, 24 Jun 2019 19:46:37 +0200

> This series was even longer before, with patches all around for various
> maintainers. I'd expect that relevant maintainers pick the range of patches
> meant for them. I don't know who's exactly responsible for what, but I think,
> this should work:
> 
> - 2 stmmac patches should go together via some networking tree (is there
>   something specific for stmmac?)
> - all DTS patches should go via sunxi
> - hdmi patches via some drm tree

Thank you.  So I'll merge the first two patches that touch the stmmac
driver via my net-next tree.

[linux-sunxi] Re: [PATCH v7 0/6] Add support for Orange Pi 3

2019-06-24 Thread David Miller 
From: meg...@megous.com
Date: Thu, 20 Jun 2019 15:47:42 +0200

> From: Ondrej Jirman 
> 
> This series implements support for Xunlong Orange Pi 3 board.
> 
> - ethernet support (patches 1-3)
> - HDMI support (patches 4-6)
> 
> For some people, ethernet doesn't work after reboot (but works on cold
> boot), when the stmmac driver is built into the kernel. It works when
> the driver is built as a module. It's either some timing issue, or power
> supply issue or a combination of both. Module build induces a power
> cycling of the phy.
> 
> I encourage people with this issue, to build the driver into the kernel,
> and try to alter the reset timings for the phy in DTS or
> startup-delay-us and report the findings.

This is a mixture of networking and non-networking changes so it really
can't go through my tree.

I wonder how you expect this series to be merged?

Thanks.

[linux-sunxi] Re: [PATCH] net: ethernet: stmmac: dwmac-sun8i: enable support of unicast filtering

2019-05-13 Thread David Miller 
From: Corentin Labbe 
Date: Mon, 13 May 2019 13:06:39 +

> When adding more MAC address to a dwmac-sun8i interface, the device goes
> directly in promiscuous mode.
> This is due to IFF_UNICAST_FLT missing flag.
> 
> So since the hardware support unicast filtering, let's add IFF_UNICAST_FLT.
> 
> Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
> Signed-off-by: Corentin Labbe 

Applied with s/address/addresses/

Thanks.

[linux-sunxi] Re: [PATCH 0/5] introduce setbits32/clrbits32/clrsetbits32/setbits64/clrbits64/clrsetbits64 functions

2018-09-07 Thread David Miller 


If you are going to do this, please add for_each_set_bit64() and similar.

For example, see:

https://marc.info/?l=linux-netdev=153633391214025=2

[linux-sunxi] Re: [PATCH] net: stmmac: dwmac-sun8i: fix allwinner,leds-active-low handling

2017-11-30 Thread David Miller 
From: Corentin Labbe 
Date: Tue, 28 Nov 2017 17:48:22 +0100

> The driver expect "allwinner,leds-active-low" to be in PHY node, but
> the binding doc expect it to be in MAC node.
> 
> Since all board DT use it also in MAC node, the driver need to search
> allwinner,leds-active-low in MAC node.
> 
> Signed-off-by: Corentin Labbe 

I've read over this discussion and I think the thing to do is for me
to simply apply this to 'net' for now.

Thanks.

[linux-sunxi] Re: [PATCH] net-next: stmmac: dwmac-sun8i: fix of_table.cocci warnings

2017-07-31 Thread David Miller 
From: Julia Lawall 
Date: Sat, 29 Jul 2017 17:54:10 +0200 (CEST)

> Make sure (of/i2c/platform)_device_id tables are NULL terminated
> 
> Generated by: scripts/coccinelle/misc/of_table.cocci
> 
> Fixes: d5dbe1976d52 ("net-next: stmmac: dwmac-sun8i: choose internal PHY via 
> compatible")
> CC: Corentin Labbe 
> Signed-off-by: Fengguang Wu 

This change seems to be no longer relevant.

[linux-sunxi] Re: [PATCH 6/6] net: stmmac: revert "support future possible different internal phy mode"

2017-07-06 Thread David Miller 
From: Corentin Labbe 
Date: Thu, 6 Jul 2017 10:51:47 +0200

> On Sun, Jul 02, 2017 at 02:31:59PM +0200, Corentin Labbe wrote:
>> Since internal phy-mode is reserved for non-xMII protocol we cannot use
>> it with dwmac-sun8i
>> This reverts commit 1c2fa5f84683 ("net: stmmac: support future possible 
>> different internal phy mode")
>> 
>> Signed-off-by: Corentin Labbe 
>> ---
> 
> Hello
> 
> This patch was left not applied but all other patch from this serie was.
> Could you apply it, or perhaps you prefer I resend it with some "Fixes:"

You never need to ask questions like this.

If it's not active in my patchwork queue, you must resend.

Thank you.

[linux-sunxi] Re: [PATCH 1/6] net: stmmac: support future possible different internal phy mode

2017-06-29 Thread David Miller 
From: Corentin Labbe <clabbe.montj...@gmail.com>
Date: Thu, 29 Jun 2017 19:02:38 +0200

> On Thu, Jun 29, 2017 at 12:23:49PM -0400, David Miller wrote:
>> From: Corentin Labbe <clabbe.montj...@gmail.com>
>> Date: Tue, 27 Jun 2017 11:28:01 +0200
>> 
>> > The current way to find if the phy is internal is to compare DT phy-mode
>> > and emac_variant/internal_phy.
>> > But it will negate a possible future SoC where an external PHY use the
>> > same phy mode than the internal one.
>> > 
>> > By using phy-mode = "internal" we permit to have an external PHY with
>> > the same mode than the internal one.
>> > 
>> > Reported-by: André Przywara <andre.przyw...@arm.com>
>> > Signed-off-by: Corentin Labbe <clabbe.montj...@gmail.com>
>> 
>> Series applied.
>> 
>> Please provide a proper "[PATCH 0/n] " header posting next time.
> 
> Sorry could you wait for applying, there are a parallel thread 
> (http://www.spinics.net/lists/devicetree/msg183520.html) and it seems finaly 
> that internal could not be the good way to do it.
> 
> Regards
> Sorry again, I should have sent a comment for waiting.

Please send me a revert patch, when I say I've applied it I already pushed
it out to my GIT tree.

[linux-sunxi] Re: [PATCH 1/6] net: stmmac: support future possible different internal phy mode

2017-06-29 Thread David Miller 
From: Corentin Labbe 
Date: Tue, 27 Jun 2017 11:28:01 +0200

> The current way to find if the phy is internal is to compare DT phy-mode
> and emac_variant/internal_phy.
> But it will negate a possible future SoC where an external PHY use the
> same phy mode than the internal one.
> 
> By using phy-mode = "internal" we permit to have an external PHY with
> the same mode than the internal one.
> 
> Reported-by: André Przywara 
> Signed-off-by: Corentin Labbe 

Series applied.

Please provide a proper "[PATCH 0/n] " header posting next time.

[linux-sunxi] Re: [PATCH 0/4] net-next: stmmac: dwmac-sun8i: add support for V3s

2017-06-20 Thread David Miller 
From: Icenowy Zheng 
Date: Sat, 17 Jun 2017 22:07:33 +0800

> Allwinner V3s features an EMAC like the on in H3, but without external MII
> interfaces, so being not able really to use RMII/RGMII.
> 
> And it has a different default value of syscon (0x38000 instead of 0x58000
> on H3), which shows a problem that the EMAC clock freq should be 24MHz.
> (Both H3 and V3s SoCs doesn't have extra xtal input for EPHY, and the
> main xtal is 24MHz. The default value of H3 is set to 24MHz, but the V3s
> default value is set to 25MHz).
> 
> First two patches are device tree binding patches, the third forces
> the frequency to 24MHz and the fourth really add the V3s support.

Series applied to net-next, thanks!

[linux-sunxi] Re: [PATCH] net-next: stmmac: dwmac-sun8i: ensure the EPHY is properly reseted

2017-06-05 Thread David Miller 
From: Icenowy Zheng 
Date: Mon,  5 Jun 2017 01:53:23 +0800

> The EPHY may be already enabled by bootloaders which have Ethernet
> capability (e.g. current U-Boot). Thus it should be reseted properly
> before doing the enabling sequence in the dwmac-sun8i driver, otherwise
> the EMAC reset process may fail if no cable is plugged, and then fail
> the dwmac-sun8i probing.
> 
> Tested on Orange Pi PC, One and Zero. All the boards fail to have
> dwmac-sun8i probed with "EMAC reset timeout" without cable plugged
> before, and with this fix they're now all able to successfully probe the
> EMAC without cable plugged and then use the connection after a cable is
> hot-plugged in.
> 
> Fixes: 9f93ac8d408 ("net-next: stmmac: Add dwmac-sun8i")
> Signed-off-by: Icenowy Zheng 

Applied, thanks.

Re: [linux-sunxi] [PATCH] net-next: stmmac: dwmac-sun8i: ensure the EPHY is properly reseted

2017-06-05 Thread David Miller 
From: Corentin Labbe 
Date: Mon, 5 Jun 2017 13:10:19 +0200

> On Mon, Jun 05, 2017 at 01:53:23AM +0800, Icenowy Zheng wrote:
>> The EPHY may be already enabled by bootloaders which have Ethernet
>> capability (e.g. current U-Boot). Thus it should be reseted properly
>> before doing the enabling sequence in the dwmac-sun8i driver, otherwise
>> the EMAC reset process may fail if no cable is plugged, and then fail
>> the dwmac-sun8i probing.
>> 
>> Tested on Orange Pi PC, One and Zero. All the boards fail to have
>> dwmac-sun8i probed with "EMAC reset timeout" without cable plugged
>> before, and with this fix they're now all able to successfully probe the
>> EMAC without cable plugged and then use the connection after a cable is
>> hot-plugged in.
>> 
>> Fixes: 9f93ac8d408 ("net-next: stmmac: Add dwmac-sun8i")
>> Signed-off-by: Icenowy Zheng 
> 
> Thanks for the fix.
> Tested-by: Corentin Labbe 
> 
> Since I am the writter of the file, does I have the right to:
> Acked-by: Corentin Labbe 
> or
> Reviewed-by: Corentin Labbe 
> ?

Anyone whatsoever may contribute Acked-by and Reviewed-by tags to a
patch posting.

This is all documented in Documentation/process/submitting-patches.rst

[linux-sunxi] Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

2017-06-02 Thread David Miller 
From: Maxime Ripard <maxime.rip...@free-electrons.com>
Date: Fri, 2 Jun 2017 11:13:20 +0200

> On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> > From: Corentin Labbe <clabbe.montj...@gmail.com>
>> > Date: Wed, 31 May 2017 09:18:31 +0200
>> > 
>> > > This patch series add the driver for dwmac-sun8i which handle the 
>> > > Ethernet MAC
>> > > present on Allwinner H3/H5/A83T/A64 SoCs.
>> > 
>> > Series applied, but wow that's a lot of DT file changes :-(
>> 
>> The DT patches should not go through your tree, but arm-soc, so I
>> guess this is not an issue for you?
> 
> Ok, so I saw that you actually merged them. Can you revert or drop
> that merge for the DT part?
> 
> This will generate a lot of conflicts with our tree, and I'm not sure
> this would be efficient to make you take all the entirely unrelated to
> next patches.

Please tell me which specific changes to revert.

Thank you.

[linux-sunxi] Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

2017-06-02 Thread David Miller 
From: Maxime Ripard <maxime.rip...@free-electrons.com>
Date: Fri, 2 Jun 2017 08:37:52 +0200

> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
>> From: Corentin Labbe <clabbe.montj...@gmail.com>
>> Date: Wed, 31 May 2017 09:18:31 +0200
>> 
>> > This patch series add the driver for dwmac-sun8i which handle the Ethernet 
>> > MAC
>> > present on Allwinner H3/H5/A83T/A64 SoCs.
>> 
>> Series applied, but wow that's a lot of DT file changes :-(
> 
> The DT patches should not go through your tree, but arm-soc, so I
> guess this is not an issue for you?

I already applied them, so if that is the intention, too late.

This needs to be explicitly stated in the header posting.  Otherwise
I assume the entire series is meant to go into my tree.

Also, saying "net-next" in the patch subjects means it's targetting my
tree.

[linux-sunxi] Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver

2017-06-01 Thread David Miller 
From: Corentin Labbe 
Date: Wed, 31 May 2017 09:18:31 +0200

> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.

Series applied, but wow that's a lot of DT file changes :-(

[linux-sunxi] Re: [PATCH 1/5] ethernet: add sun8i-emac driver

2016-06-03 Thread David Miller 
From: LABBE Corentin 
Date: Fri,  3 Jun 2016 11:56:26 +0200

> +static int nbdesc_tx = 256;
> +module_param(nbdesc_tx, int, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(nbdesc_tx, "Number of descriptors in the TX list");
> +static int nbdesc_rx = 128;
> +module_param(nbdesc_rx, int, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(nbdesc_rx, "Number of descriptors in the RX list");

Module parameters are not appropriate.

Please use the proper ethtool configuration facilities to control
the size of the RX and TX queues.

Thanks.

[linux-sunxi] Re: [PATCH resend] net: sun4i-emac: Properly free resources on probe failure and remove

2015-10-21 Thread David Miller 
From: Hans de Goede 
Date: Tue, 20 Oct 2015 10:42:24 +0200

> Fix sun4i-emac not releasing the following resources:
> -iomapped memory not released on probe-failure nor on remove
> -clock not getting disabled on probe-failure nor on remove
> -sram not being released on remove
> 
> And while at it also add error checking to the clk_prepare_enable call
> done on probe.
> 
> Signed-off-by: Hans de Goede 

Applied.

[linux-sunxi] Re: [PATCH resend 0/1] net: sun4i-emac: Properly free resources on probe failure

2015-10-20 Thread David Miller 
From: Hans de Goede 
Date: Tue, 20 Oct 2015 10:42:23 +0200
> 
> IIRC you said you would pick this up, but I'm not seeing it in
> net-next, hence this resend.

If it's not in my tree, and it's not active on patchwork, you really
have to resend your patches.

Asking me to dig into submissions made some time in the past doesn't
really work, sorry.

[linux-sunxi] Re: [PATCH] net: sun4i-emac: Claim emac sram

2015-08-25 Thread David Miller 
From: Hans de Goede hdego...@redhat.com
Date: Sun, 23 Aug 2015 20:31:38 +0200

 Claim the emac sram ourselves, rather then relying on the bootloader
 having mapped the sram to the emac controller during boot.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com

Applied to net-next, thanks.