Re: [PATCH 0/3] sh_eth: fix typos/grammar

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 19 May 2018 23:57:50 +0300

> Here's a set of 3 patches against DaveM's 'net-next.git' repo plus the 
> R8A77980
> support patches posted earlier. They fix the comments typos/grammar and 
> another
> typo in the EESR bit...

Series applied.

Re: [PATCH v2 0/3] Add Renesas R8A77980 GEther support

[David Miller]

From: Sergei Shtylyov 
Date: Fri, 18 May 2018 21:28:29 +0300

> Here's a set of 3 patches against DaveM's 'net-next.git' repo. They 
> (gradually)
> add R8A77980 GEther support to the 'sh_eth' driver, starting with couple new
> register bits/values introduced with this chip, and ending with adding a new
> 'struct sh_eth_cpu_data' instance connected to the new DT "compatible" prop
> value...

Series applied, thanks.

Re: [PATCH v2] sh_eth: Change platform check to CONFIG_ARCH_RENESAS

[David Miller]

From: Geert Uytterhoeven 
Date: Fri, 18 May 2018 12:52:51 +0200

> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
> 
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check.
> 
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
> 
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Arnd Bergmann 
> Acked-by: Sergei Shtylyov 
> Reviewed-by: Simon Horman 

Applied.

Re: [PATCH 0/3] Add R8A77980 GEther support

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 16 May 2018 22:52:40 +0300

> Here's a set of 3 patches against DaveM's 'net-next.git' repo. They 
> (gradually)
> add R8A77980 GEther support to the 'sh_eth' driver, starting with couple new
> register bits/values introduced with this chip, and ending with adding a new
> 'struct sh_eth_cpu_data' instance connected to the new DT "compatible" prop
> value...
> 
> [1/1] sh_eth: add RGMII support
> [2/3] sh_eth: add EDMR.NBST support
> [3/3] sh_eth: add R8A77980 support

Waiting for a respin of this, correcting the RGMII check in patch #1.

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[David Miller]

From: Florian Fainelli 
Date: Tue, 15 May 2018 16:56:17 -0700

> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent 
> with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.
> 
> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
> 
> Changes in v2:
> 
> - fixed build error in davincin_mdio.c (Grygorii)
> - reworked first patch a bit: commit message, subject and removed useless
>   code comment

Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks.

Re: [PATCH] dt-bindings: net: ravb: Add support for r8a77990 SoC

[David Miller]

From: Yoshihiro Shimoda 
Date: Fri, 11 May 2018 12:18:56 +0900

> Add documentation for r8a77990 compatible string to renesas ravb device
> tree bindings documentation.
> 
> Signed-off-by: Yoshihiro Shimoda 

I'm assuming this isn't targetted at one of my trees.  Just FYI.

Re: [PATCH 8/9] net: flow_dissector: fix typo 'can by' to 'can be'

[David Miller]

From: Wolfram Sang 
Date: Sun,  6 May 2018 13:23:52 +0200

> Signed-off-by: Wolfram Sang 

Applied.

Re: [PATCH 0/2] sh_eth: complain on access to unimplemented TSU registers

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 2 May 2018 22:53:23 +0300

> Here's a set of 2 patches against DaveM's 'net-next.git' repo. The 1st patch
> routes TSU_POST register accesses thru sh_eth_tsu_{read|write}() and the 
> 2nd
> added WARN_ON() unimplemented register to those functions. I'm going to deal 
> with
> TSU_ADR{H|L} registers in a later series...
> 
> [1/2] sh_eth: use TSU register accessors for TSU_POST
> [2/2] sh_eth: WARN_ON() access to unimplemented TSU register

Series applied to net-next, thanks.

Re: [PATCH/RFC net-next 3/5] ravb: do not write 1 to reserved bits

[David Miller]

From: Simon Horman 
Date: Tue, 17 Apr 2018 10:50:28 +0200

> From: Kazuya Mizuguchi 
> 
> This patch corrects writing 1 to reserved bits.
> The write value should be 0.
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Simon Horman 

How are we ending up in situations where the driver is trying to write
non-zero values to those fields in the first place?

The places creating those values should be making sure that the
reserved bits are never set.

If you mask out the reserved bits in the register writing locations,
this just hides bugs.

Re: [PATCH/RFC net-next 4/5] ravb: remove undocumented processing

[David Miller]

From: Simon Horman 
Date: Tue, 17 Apr 2018 10:50:29 +0200

> From: Kazuya Mizuguchi 
> 
> Signed-off-by: Kazuya Mizuguchi 
> Signed-off-by: Simon Horman 

Why?  What was wrong with it?

Need more text and explanations in these commit messages please.

Re: [PATCH] dt-bindings: net: ravb: Add support for r8a77965 SoC

[David Miller]

From: Jacopo Mondi 
Date: Mon, 16 Apr 2018 15:55:17 +0200

> Add documentation for r8a77965 compatible string to renesas ravb device
> tree bindings documentation.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> Acked-by: Sergei Shtylyov 
> ---
> 
> Renesas R-Car M3-N support has been merged for v4.17.
> Document the missing device tree bindings.

Since this is purely a devicetree update, I'm assuming that it doesn't
go through my networking tree.

Re: [PATCH 0/2] sh_eth: remove SH_ETH_OFFSET_INVALID abuses

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 1 Apr 2018 00:15:04 +0300

> Hello!
> 
> Here's a set of 2 patches against DaveM's 'net-next.git' repo. They get rid of
> the abuse of SH_ETH_OFFSET_INVALID for the register existence checks, so that
> only its necessary uses would remain...
> 
> [1/2] sh_eth: add sh_eth_cpu_data::no_xdfar flag
> [2/2] sh_eth: kill useless check in __sh_eth_get_regs()

Series applied, thank you.

Re: [PATCH net-next] dt-bindings: net: renesas-ravb: Add support for r8a77470 SoC

[David Miller]

From: Biju Das 
Date: Thu, 29 Mar 2018 11:02:55 +0100

> Add a new compatible string for the RZ/G1C (R8A77470) SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Fabrizio Castro 

Applied.

Re: [PATCH 0/2] sh_eth: unify the SoC feature checks

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 24 Mar 2018 23:04:53 +0300

> Here's a set of 5 patches against DaveM's 'net-next.git' repo.
> 
> The Ether driver sometimes uses the bit fields in 'struct sh_eth_cpu_data'
> to check which Ether registers exist in a certain SoC and sometimes it uses
> sh_eth_is_{gether|rz_fast_ether}() which basically compares 2 pointers (1 of
> them being constant) -- the latter is definitely not a strongest feature of
> the RISC CPUs (be it SH or ARM), so I decided to get rid of this type of
> the feature checks in favour of the bit fields (I've also made use of a
> 32-bit value and method pointer where appropriate)...

Series applied with patch #4 subject fixed up.

Thank you.

Re: [PATCH] ravb: remove erroneous comment

[David Miller]

From: Niklas Söderlund 
Date: Sat,  3 Mar 2018 23:39:54 +0100

> When addressing a review comment in a early version of the offending
> patch a comment where left in which should have been removed. Remove the
> comment to keep it consistent with the code.
> 
> Fixes: 75efa06f457bbed3 ("ravb: add support for changing MTU")
> Reported-by: Sergei Shtylyov 
> Signed-off-by: Niklas Söderlund 

Applied to net-next, thanks.

Re: [PATCH v2] dt-bindings: net: renesas-ravb: Make stream buffer optional

[David Miller]

From: Geert Uytterhoeven 
Date: Fri,  2 Mar 2018 16:01:48 +0100

> The Stream Buffer for EtherAVB-IF (STBE) is an optional component, and
> is not present on all SoCs.
> 
> Document this in the DT bindings, including a list of SoCs that do have
> it.
> 
> Fixes: 785ec87483d1e24a ("ravb: document R8A77970 bindings")
> Fixes: f231c4178a655b09 ("dt-bindings: net: renesas-ravb: Add support for 
> R8A77995 RAVB")
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> Acked-by: Sergei Shtylyov 
> Reviewed-by: Rob Herring 
> ---
> v2:
>   - Add Reviewed-by, Acked-by,
>   - Add R-Car M3-N.

Applied, thanks Geert.

Re: [PATCH net-next] sh_eth: uninline TSU register accessors

[David Miller]

From: Sergei Shtylyov 
Date: Tue, 27 Feb 2018 14:58:16 +0300

> We have uninlined the sh_eth_{read|write}() functions introduced in the
> commit 4a55530f38e ("net: sh_eth: modify the definitions of register").
> Now remove *inline* from sh_eth_tsu_{read|write}() as  well and move
> these functions from the header to the driver itself. This saves 684
> more bytes of object code (ARM gcc 4.8.5)...
> 
> Signed-off-by: Sergei Shtylyov 

Applied to 'net', as requested in a followup.

Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings

[David Miller]

From: Simon Horman <ho...@verge.net.au>
Date: Mon, 26 Feb 2018 11:58:24 +0100

> On Sat, Feb 24, 2018 at 09:53:17PM -0500, David Miller wrote:
>> From: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>> Date: Sat, 24 Feb 2018 21:01:15 +0300
>> 
>> > On 02/01/2018 11:13 PM, Sergei Shtylyov wrote:
>> > 
>> >> Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB
>> >> device, so document the SoC specific bindings.
>> >> 
>> >> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>> >> 
>> >> ---
>> >> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if 
>> >> it's
>> >> applied to 'net.git' instead. :-)
>> > 
>> >David, I see this patch was marked as "not applicable" in patchwork. 
>> > Why, because
>> > it was posted during the merge window?
>> 
>> No because I thought the relevant architecture tree would take a mere
>> DT update.
> 
> Hi Dave,
> 
> I am happy to take these kinds of changes for the ravb and sh_eth drivers
> if that is your preference. I am also just as happy for you to take them,
> which I think has been the case for similar changes in the past.

No, it's not a problem.  Applied to 'net', thanks.

Re: [PATCH net-next] sh_eth: fix TSU init on SH7734/R8A7740

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 24 Feb 2018 22:41:45 +0300

> It appears that the single port Ether controllers having TSU (like SH7734/
> R8A7740) need the same kind of treating in sh_eth_tsu_init() as R7S72100
> currently has -- they also don't have the TSU registers related e.g. to
> passing the frames between ports. Add the 'sh_eth_cpu_data::dual_port'
> flag and use it as a new criterion for taking a "short path" in the TSU
> init sequence in order to avoid writing to the non-existant registers...
> 
> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
> Signed-off-by: Sergei Shtylyov 

Applied with commit messsage spelling problem fixed.

Thanks.

Re: [PATCH net-next] sh_eth: TSU_QTAG0/1 registers the same as TSU_QTAGM0/1

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 24 Feb 2018 20:28:16 +0300

> The TSU_QTAG0/1 registers found in the Gigabit Ether controllers actually
> have the same long name  as the TSU_QTAGM0/1 registers in the early Ether
> controllers:  Qtag Addition/Deletion Set Register (Port 0/1 to 1/0); thus
> there's no need to make a difference in sh_eth_tsu_init() between those
> controllers. Unfortunately, we can't just remove TSU_QTAG0/1 from the
> register *enum* because that would break the ethtool register dump...
> 
> Fixes: b0ca2a21f769 ("sh_eth: Add support of SH7763 to sh_eth")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH] DT: net: renesas,ravb: document R8A77980 bindings

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 24 Feb 2018 21:01:15 +0300

> On 02/01/2018 11:13 PM, Sergei Shtylyov wrote:
> 
>> Renesas R-Car V3H (R8A77980) SoC has the R-Car gen3 compatible EtherAVB
>> device, so document the SoC specific bindings.
>> 
>> Signed-off-by: Sergei Shtylyov 
>> 
>> ---
>> The patch is against DaveM's 'net-next.git' repo but I wouldn't mind if it's
>> applied to 'net.git' instead. :-)
> 
>David, I see this patch was marked as "not applicable" in patchwork. Why, 
> because
> it was posted during the merge window?

No because I thought the relevant architecture tree would take a mere
DT update.

Re: [PATCH] sh_eth: simplify sh_eth_check_reset()

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 18 Feb 2018 18:21:05 +0300

> The *while* loop in this function  can be turned into a normal *for* loop.
> And getting rid  of the  single return point saves us a few more LoCs...
> 
> Signed-off-by: Sergei Shtylyov 

Applied to net-next, thanks Sergei.

> The patch is against DaveM's 'net-next.git' repo.

It is actually easier for you (and me) if you just indicate this in
your Subject like "[PATCH net-next]" in the future.

Thank you.

Re: [PATCH v2] ravb: add support for changing MTU

[David Miller]

From: Niklas Söderlund 
Date: Fri, 16 Feb 2018 17:10:08 +0100

> Allow for changing the MTU within the limit of the maximum size of a
> descriptor (2048 bytes). Add the callback to change MTU from user-space
> and take the configurable MTU into account when configuring the
> hardware.
> 
> Signed-off-by: Niklas Söderlund 

Applied.

However, most drivers support MTU change while the interface is up and
frankly that is what is most useful for users.

Re: [PATCH v2] sh_eth: Remove obsolete explicit clock handling for WoL

[David Miller]

From: Geert Uytterhoeven 
Date: Mon, 12 Feb 2018 14:42:36 +0100

> Currently, if Wake-on-LAN is enabled, the SH-ETH device's module clock
> is manually kept running during system suspend, to make sure the device
> stays active.
> 
> Since commits 91c719f5ec6671f7 ("soc: renesas: rcar-sysc: Keep wakeup
> sources active during system suspend") and 744dddcae84441b1 ("clk:
> renesas: mstp: Keep wakeup sources active during system suspend"), this
> workaround is no longer needed.  Hence remove all explicit clock
> handling to keep the device active.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Niklas Söderlund 
> Reviewed-by: Sergei Shtylyov 
> ---
> v2:
>   - Add Reviewed-by,
>   - Drop RFC state, now the dependencies are upstream.

Applied.

Re: [PATCH v2] ravb: Remove obsolete explicit clock handling for WoL

[David Miller]

From: Geert Uytterhoeven 
Date: Mon, 12 Feb 2018 14:40:00 +0100

> Currently, if Wake-on-LAN is enabled, the EtherAVB device's module clock
> is manually kept running during system suspend, to make sure the device
> stays active.
> 
> Since commit 91c719f5ec6671f7 ("soc: renesas: rcar-sysc: Keep wakeup
> sources active during system suspend") , this workaround is no longer
> needed.  Hence remove all explicit clock handling to keep the device
> active.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Niklas Söderlund 
> Reviewed-by: Sergei Shtylyov 
> ---
> v2:
>   - Add Reviewed-by,
>   - Rebased,
>   - Drop RFC state, now the dependency is upstream.

Applied.

Re: [PATCH 4/4] net: amd-xgbe: fix comparison to bitshift when dealing with a mask

[David Miller]

From: Wolfram Sang 
Date: Mon,  5 Feb 2018 21:10:01 +0100

> Due to a typo, the mask was destroyed by a comparison instead of a bit
> shift.
> 
> Signed-off-by: Wolfram Sang 

Applied and queued up for -stable, thanks.

Re: [PATCH 0/2] sh_eth: simplify TSU initialization

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 14 Jan 2018 20:47:42 +0300

> Here's a set of 2 patches against DaveM's 'net-next.git' repo. With those,
> I'm somewhat simplifying the TSU init code in the driver probe() method...
> 
> [1/2] sh_eth: gather all TSU init code in one place
> [2/2] sh_eth: get Ether port # only when needed

Series applied, thanks Sergei.

Re: [PATCH] sh_eth: dix dumping ARSTR

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 13 Jan 2018 20:22:01 +0300

> ARSTR  is always located at the start of the TSU register region, thus
> using add_reg()  instead of add_tsu_reg() in __sh_eth_get_regs() to dump it
> causes EDMR or EDSR (depending on the register layout) to be dumped instead
> of ARSTR.  Use the correct condition/macro there...
> 
> Fixes: 6b4b4fead342 ("sh_eth: Implement ethtool register dump operations")
> Signed-off-by: Sergei Shtylyov 

Applied to 'net' with subj. typo fixed :)

Re: [PATCH] net: phy: Fix phy_modify() semantic difference fallout

[David Miller]

From: Geert Uytterhoeven 
Date: Tue,  9 Jan 2018 12:11:21 +0100

> In case of success, the return values of (__)phy_write() and
> (__)phy_modify() are not compatible: (__)phy_write() returns 0, while
> (__)phy_modify() returns the old PHY register value.
> 
> Apparently this change was catered for in drivers/net/phy/marvell.c, but
> not in other source files.
> 
> Hence genphy_restart_aneg() now returns 4416 instead zero, which is
> considered an error:
> 
> ravb e680.ethernet eth0: failed to connect PHY
> IP-Config: Failed to open eth0
> IP-Config: No network devices available
> 
> Fix this by converting positive values to zero in all callers of
> phy_modify().
> 
> Fixes: fea23fb591cce995 ("net: phy: convert read-modify-write to 
> phy_modify()")
> Signed-off-by: Geert Uytterhoeven 
> ---
> Alternatively, __phy_modify() could be changed to follow __phy_write()
> semantics?

I really want a resolution to this quickly, this broke lots of stuff
for people.

__phy_modify() wants to return multiple values, so it should be coded
up to do so explicitly rather than trying to encode two values from
overlapping value spaces in one return value.

That means the original value should be returned by-reference.  And
this will make the error/no-error return value unambiguous.

int __phy_modify(struct phy_device *phydev, u32 regnum, u16 mask, u16 set,
 u16 *orig_val);

Thank you.

Re: [PATCH] sh_eth: fix TXALCR1 offsets

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 07 Jan 2018 00:26:47 +0300

> The  TXALCR1 offsets are incorrect in the register offset tables, most
> probably due to copy error.  Luckily, the driver never uses this
> register. :-)
> 
> Fixes: 4a55530f38e4 ("net: sh_eth: modify the definitions of register")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH] sh_eth: remove sh_eth_plat_data::edmac_endian

[David Miller]

From: Sergei Shtylyov 
Date: Fri, 05 Jan 2018 00:26:46 +0300

> Since the commit 888cc8c20cf ("sh_eth: remove EDMAC_BIG_ENDIAN") (geez,
> I didn't realize that was 2 years ago!) the initializers in the SuperH
> platform code for the 'sh_eth_plat_data::edmac_endian' stopped to matter,
> so we can remove that field for good (not sure if  it  was ever useful --
> SH7786 Ether has been reported  to have the same EDMAC descriptor/register
> endiannes as configured for the SuperH CPU)...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against DaveM's 'net-next.git' repo.
> Not sure who should apply the patch -- will prolly be faster if DaveM does...

Applied, thanks Sergei.

Re: [PATCH] sh_eth: fix SH7757 GEther initialization

[David Miller]

From: Sergei Shtylyov 
Date: Thu, 04 Jan 2018 21:06:49 +0300

> Renesas  SH7757 has 2 Fast and 2 Gigabit Ether controllers, while the
> 'sh_eth' driver can only reset and initialize TSU of the first controller
> pair. Shimoda-san tried to solve that adding the 'needs_init' member to the
> 'struct sh_eth_plat_data', however the platform code still never sets this
> flag. I think  that we can infer this information from the 'devno' variable
> (set  to 'platform_device::id') and reset/init the Ether controller pair
> only for an even 'devno'; therefore 'sh_eth_plat_data::needs_init' can be
> removed...
> 
> Fixes: 150647fb2c31 ("net: sh_eth: change the condition of initialization")
> Signed-off-by: Sergei Shtylyov 

Applied and queued up for -stable.

Re: [PATCH] sh_eth: fix TSU resource handling

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 03 Jan 2018 20:09:49 +0300

> When switching  the driver to the managed device API,  I managed to break
> the  case of a  dual Ether devices sharing a single TSU: the 2nd Ether port
> wouldn't probe. Iwamatsu-san has tried to fix this but his patch was buggy
> and he then dropped the ball...
> 
> The solution is to  limit calling devm_request_mem_region() to the first
> of  the two  ports  sharing the same TSU, so devm_ioremap_resource() can't
> be used anymore for the TSU resource...
> 
> Fixes: d5e07e69218f ("sh_eth: use managed device API")
> Reported-by: Nobuhiro Iwamatsu 
> Signed-off-by: Sergei Shtylyov 

Applied and queued up for -stable, thanks.

Re: [PATCH 0/2] Kill redundant checks in the Renesas Ethernet drivers

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 31 Dec 2017 21:41:34 +0300

> Here's a set of 2 patches against DaveM's 'net-next.git' repo removing
> redundant checks in the driver probe() methods.

Series applied with the "disassembly" typo fixed.

Re: [PATCH] Revert "ravb: add workaround for clock when resuming with WoL enabled"

[David Miller]

From: Geert Uytterhoeven 
Date: Mon, 11 Dec 2017 09:54:09 +0100

> This reverts commit fbf3d034f2ff6264183cfa6845770e8cc2a986c8.
> 
> As of commit 560869100b99a3da ("clk: renesas: cpg-mssr: Restore module
> clocks during resume"), the workaround is no longer needed.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied, thanks.

Re: [PATCH v3] net: sh_eth: do not advertise Gigabit capabilities when not available

[David Miller]

From: Thomas Petazzoni 
Date: Fri,  8 Dec 2017 16:35:40 +0100

> Not all variants of the sh_eth hardware have Gigabit
> support. Unfortunately, the current driver doesn't tell the PHY about
> the limited MAC capabilities. Due to this, if you have a Gigabit
> capable PHY, the PHY will advertise its Gigabit capability and
> establish a link at 1Gbit/s, even though the MAC doesn't support it.
> 
> In order to avoid this, we use the recently introduced
> phy_set_max_speed() to tell the PHY to not advertise speed higher than
> 100 MBit/s.
> 
> Tested on a SH7786 platform, with a Gigabit PHY.
> 
> Signed-off-by: Thomas Petazzoni 

Applied, thanks.

Re: [PATCH 1/2] net: sh_eth: add support for SH7786

[David Miller]

From: Sergei Shtylyov 
Date: Tue, 5 Dec 2017 22:49:10 +0300

> On 12/05/2017 10:04 PM, Sergei Shtylyov wrote:
> 
> This commit adds the sh_eth_cpu_data structure that describes the
> SH7786 variant of the IP.

  The manual seems to be unavailable, so I have to trust you. :-)
>>>
>>> Yes, sadly. However, if you tell me what to double check, I'd be happy
>>> to do so.
>> I have the manual now, will check against it...
>> DaveM, I'm retracting my ACK for the time being.
> 
>Starting to look into the manual, the current patch is wrong. SH7786
>SoC was probably the 1st one to use what we thought was R-Car specific
>register layout. Definite NAK on this version.

Ok.

Re: [PATCH 0/2] net: sh_eth: add support for SH7786 and big-endian

[David Miller]

From: Thomas Petazzoni 
Date: Mon,  4 Dec 2017 15:17:42 +0100

> I've recently been working on an SH7786 based platform, which uses the
> sh_eth network controller. One peculiarity of my setup is that the CPU
> is configured big-endian (even though little-endian is more
> traditional in the Linux SuperH world), and the sh_eth driver was not
> ready for this.
> 
> The first patch simply adds the sh_eth_cpu_data structure that
> describes the SH7786 controller.
> 
> The second patch fixes the driver for big-endian operation. However,
> I'd like this patch to be carefully reviewed by Sergei Shtylyov who
> already did some endianness related changes in this driver. Indeed, my
> change is based on the assumption that the DMA descriptors are in the
> native endianness of the CPU.

Sergei, please let me know when you've re-reviewed this series now
that you have documentation in hand...

Thanks.

Re: [PATCH 0/2] net: sh_eth: DMA mapping API fixes

[David Miller]

From: Thomas Petazzoni 
Date: Mon,  4 Dec 2017 14:33:25 +0100

> Here are two patches that fix how the sh_eth driver is using the DMA
> mapping API: a bogus struct device is used in some places, or a NULL
> struct device is used.

Series applied.

Re: [PATCH v4 0/4] Teach phylib hard-resetting devices

[David Miller]

From: Geert Uytterhoeven 
Date: Mon,  4 Dec 2017 11:34:48 +0100

> This patch series adds optional PHY reset support to phylib.

Patch #1 and #2 applied to net-next, using v4.1 of patch #1.

Thanks.

Re: [PATCH v2] of_mdio: Fix broken PHY IRQ in case of probe deferral

[David Miller]

From: Florian Fainelli 
Date: Sat, 21 Oct 2017 19:01:45 -0700

> Reviewed-by : Florian Fainelli 
> 
> I still can't make sure this is not a problem for multiple PHYs
> hanging off the same bus, but like anything else, we'll deal with
> problems later if they arise.

Thanks Florian.

Applied, thanks everyone.

Re: [PATCH v2] of_mdio: Fix broken PHY IRQ in case of probe deferral

[David Miller]

Second ping, this patch needs a review ASAP.

Geert's hard-resetting PHY changes depend upon this change.

Thank you.

Re: [PATCH] net: ethtool: remove error check for legacy setting transceiver type

[David Miller]

From: Niklas Söderlund 
Date: Fri, 20 Oct 2017 01:32:08 +0200

> Commit 9cab88726929605 ("net: ethtool: Add back transceiver type")
> restores the transceiver type to struct ethtool_link_settings and
> convert_link_ksettings_to_legacy_settings() but forgets to remove the
> error check for the same in convert_legacy_settings_to_link_ksettings().
> This prevents older versions of ethtool to change link settings.
> 
> # ethtool --version
> ethtool version 3.16
> 
> # ethtool -s eth0 autoneg on speed 100 duplex full
> Cannot set new settings: Invalid argument
>   not setting speed
>   not setting duplex
>   not setting autoneg
> 
> While newer versions of ethtool works.
> 
> # ethtool --version
> ethtool version 4.10
> 
> # ethtool -s eth0 autoneg on speed 100 duplex full
> [   57.703268] sh-eth ee70.ethernet eth0: Link is Down
> [   59.618227] sh-eth ee70.ethernet eth0: Link is Up - 100Mbps/Full - 
> flow control rx/tx
> 
> Fixes: 19cab88726929605 ("net: ethtool: Add back transceiver type")
> Signed-off-by: Niklas Söderlund 

Applied.

Re: [PATCH v2] of_mdio: Fix broken PHY IRQ in case of probe deferral

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 18 Oct 2017 13:54:03 +0200

> The actual patch is unchanged since v1, sent on May 18.  Obviously I
> still cannot test it on a system with multiple PHYs, just like v1.
> 
> How can we proceed?

Andrew and Florian, please review this.

Re: [PATCH net-next v2 0/3] net: sh_eth: add R-Car Gen[12] fallback compatibility strings

[David Miller]

From: Simon Horman 
Date: Wed, 18 Oct 2017 09:21:25 +0200

> Add fallback compatibility strings for R-Car Gen 1 and 2.

Series applied to net-next, thanks.

Re: [PATCH] ravb: Consolidate clock handling

[David Miller]

From: Geert Uytterhoeven 
Date: Thu, 12 Oct 2017 10:24:53 +0200

> The module clock is used for two purposes:
>   - Wake-on-LAN (WoL), which is optional,
>   - gPTP Timer Increment (GTI) configuration, which is mandatory.
> 
> As the clock is needed for GTI configuration anyway, WoL is always
> available.  Hence remove duplication and repeated obtaining of the clock
> by making GTI use the stored clock for WoL use.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied.

Re: [PATCH v2 net-next] ravb: RX checksum offload

[David Miller]

From: Simon Horman 
Date: Wed,  4 Oct 2017 09:54:27 +0200

> Add support for RX checksum offload. This is enabled by default and
> may be disabled and re-enabled using ethtool:
> 
>  # ethtool -K eth0 rx off
>  # ethtool -K eth0 rx on
> 
> The RAVB provides a simple checksumming scheme which appears to be
> completely compatible with CHECKSUM_COMPLETE: sum of all packet data after
> the L2 header is appended to packet data; this may be trivially read by the
> driver and used to update the skb accordingly.
> 
> In terms of performance throughput is close to gigabit line-rate both with
> and without RX checksum offload enabled. Perf output, however, appears to
> indicate that significantly less time is spent in do_csum(). This is as
> expected.
 ...
> Signed-off-by: Simon Horman 

Applied, thanks Simon.

Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB

[David Miller]

From: Yoshihiro Shimoda 
Date: Thu, 14 Sep 2017 09:06:38 +0900

> Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
> 
> Acked-by: Geert Uytterhoeven 
> Signed-off-by: Yoshihiro Shimoda 

Applied to net-next.

Re: [PATCH] ravb: document R8A77970 bindings

[David Miller]

From: Sergei Shtylyov 
Date: Tue, 12 Sep 2017 23:02:08 +0300

> R-Car V3M (R8A77970) SoC also has the R-Car gen3 compatible EtherAVB
> device, so document  the SoC specific bindings.
> 
> Signed-off-by: Sergei Shtylyov 

Applied to net-next.

Re: [PATCH v2] net: smsc911x: Quieten netif during suspend

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 13 Sep 2017 19:42:05 +0200

> If the network interface is kept running during suspend, the net core
> may call net_device_ops.ndo_start_xmit() while the Ethernet device is
> still suspended, which may lead to a system crash.
> 
> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
> driven by a PM controlled clock.  If the Ethernet registers are accessed
> while the clock is not running, the system will crash with an imprecise
> external abort.
> 
> As this is a race condition with a small time window, it is not so easy
> to trigger at will.  Using pm_test may increase your chances:
> 
> # echo 0 > /sys/module/printk/parameters/console_suspend
> # echo platform > /sys/power/pm_test
> # echo mem > /sys/power/state
> 
> To fix this, make sure the network interface is quietened during
> suspend.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied.

Re: [PATCH] MAINTAINERS: review Renesas DT bindings as well

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 13 Sep 2017 22:28:53 +0300

> When adding myself  as a reviewer for  the Renesas  Ethernet drivers
> I somehow forgot about the bindings -- I want to review them as well.
> 
> Fixes: 8e6569af3a1b ("MAINTAINERS: add myself as Renesas Ethernet drivers 
> reviewer")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH ] dt-bindings: net: ravb : Add support for r8a7745 SoC

[David Miller]

From: Biju Das 
Date: Tue, 15 Aug 2017 15:40:20 +0100

> Add a new compatible string for the RZ/G1E (R8A7745) SoC.
> 
> Signed-off-by: Biju Das 
> ---
> This patch is tested against linux-next tag next-20170815
> as well as net-next.

Applied.

Re: [PATCH v3 0/2] ravb: add wake-on-lan support via magic packet

[David Miller]

From: Niklas Söderlund 
Date: Tue,  1 Aug 2017 12:14:35 +0200

> WoL is enabled in the suspend callback by setting MagicPacket detection
> and disabling all interrupts expect MagicPacket. In the resume path the
> driver needs to reset the hardware to rearm the WoL logic, this prevents
> the driver from simply restoring the registers and to take advantage of
> that ravb was not suspended to reduce resume time. To reset the
> hardware the driver closes the device, sets it in reset mode and reopens
> the device just like it would do in a normal suspend/resume scenario
> without WoL enabled, but it both closes and opens the device in the
> resume callback since the device needs to be reset for WoL to work.
> 
> One quirk needed for WoL is that the module clock needs to be prevented
> from being switched off by Runtime PM. To keep the clock alive the
> suspend callback need to call clk_enable() directly to increase the
> usage count of the clock. Then when Runtime PM decreases the clock usage
> count it won't reach 0 and be switched off.
> 
> Changes since v2
> - Only do the clock dance to workaround PSCI sleep when resuming if WoL 
>   is enabled. This was a bug in v2 which resulted in a WARN if resuming 
>   from PSCI sleep with WoL disabled, thanks Sergei for pointing this 
>   out!
> - Break out clock dance workaround in separate patch to make it easier 
>   to revert once a fix is upstream for the clock driver as suggested by 
>   Sergei.
> 
> Changes since v1
> - Fix issue where device would fail to resume from PSCI suspend if WoL
>   was enabled, reported by Geert. The fault was that the clock driver
>   thinks the clock is on, but PSCI have disabled it, added workaround
>   for this in ravb driver which can be removed once the clock driver is
>   aware of the PSCI behavior.
> - Only try to restore from wol wake up if netif is running, since this
>   is a condition to enable wol in the first place this was a bug in v1.

Series applied, thanks.

Re: [PATCH net-next repost v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

[David Miller]

From: Biju Das 
Date: Mon, 17 Jul 2017 09:33:52 +0100

> Add a new compatible string for the RZ/G1M (R8A7743) SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 

Applied.

Re: [PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Mon, 12 Jun 2017 10:25:25 -0400 (EDT)

> From: Yuval Shaia <yuval.sh...@oracle.com>
> Date: Mon, 12 Jun 2017 17:15:08 +0300
> 
>> Make return value void since function never return meaningfull value
>> 
>> Signed-off-by: Yuval Shaia <yuval.sh...@oracle.com>
>> Acked-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>> ---
>> v0 ->v1:
>>  * These files were missing in v0
>>  * drivers/net/ethernet/renesas/ravb_main.c
>>  * drivers/net/ethernet/renesas/sh_eth.c
>>  * drivers/net/ethernet/ti/netcp_ethss.c
>>  * Add Acked-by: Sergei Shtylyov
>> v1 -> v2:
>>  * Adjust to net-next tree
> 
> Applied, thank you.

Reverted, please test your build properly:

drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c: In function 
‘xgene_get_link_ksettings’:
drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:134:10: error: void value 
not ignored as it ought to be
   return phy_ethtool_ksettings_get(phydev, cmd);
  ^
drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c:140:11: error: void value 
not ignored as it ought to be
return phy_ethtool_ksettings_get(phydev, cmd);
   ^
scripts/Makefile.build:302: recipe for target 
'drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.o' failed

Re: [PATCH v2] net: phy: Make phy_ethtool_ksettings_get return void

[David Miller]

From: Yuval Shaia 
Date: Mon, 12 Jun 2017 17:15:08 +0300

> Make return value void since function never return meaningfull value
> 
> Signed-off-by: Yuval Shaia 
> Acked-by: Sergei Shtylyov 
> ---
> v0 ->v1:
>   * These files were missing in v0
>   * drivers/net/ethernet/renesas/ravb_main.c
>   * drivers/net/ethernet/renesas/sh_eth.c
>   * drivers/net/ethernet/ti/netcp_ethss.c
>   * Add Acked-by: Sergei Shtylyov
> v1 -> v2:
>   * Adjust to net-next tree

Applied, thank you.

Re: [PATCH v3] sh_eth: add support for changing MTU

[David Miller]

From: Niklas Söderlund 
Date: Mon, 12 Jun 2017 10:39:03 +0200

> The hardware supports the MTU to be changed and the driver it self is
> somewhat prepared to support this. This patch hooks up the callbacks to
> be able to change the MTU from user-space.
> 
> Signed-off-by: Niklas Söderlund 
> Acked-by: Sergei Shtylyov 

Applied to net-next, thanks.

Re: [PATCH v1] net/phy: Make phy_ethtool_ksettings_get return void

[David Miller]

From: Yuval Shaia 
Date: Mon, 12 Jun 2017 10:42:33 +0300

> Make return value void since function never return meaningfull value
> 
> Signed-off-by: Yuval Shaia 
> Acked-by: Sergei Shtylyov 
> ---
> Re-sending since last time forgot to add netdev-list
> v0 ->v1:
>   * These files were missing in v0
>   * drivers/net/ethernet/renesas/ravb_main.c
>   * drivers/net/ethernet/renesas/sh_eth.c
>   * drivers/net/ethernet/ti/netcp_ethss.c
>   * Add Acked-by: Sergei Shtylyov

This doesn't apply cleanly to net-next at all.

Please respin against an uptodate net-next tree, thank you.

Re: [PATCH] ravb: Fix use-after-free on `ifconfig eth0 down`

[David Miller]

From: Eugeniu Rosca 
Date: Tue, 6 Jun 2017 00:08:10 +0200

> Commit a47b70ea86bd ("ravb: unmap descriptors when freeing rings") has
> introduced the issue seen in [1] reproduced on H3ULCB board.
> 
> Fix this by relocating the RX skb ringbuffer free operation, so that
> swiotlb page unmapping can be done first. Freeing of aligned TX buffers
> is not relevant to the issue seen in [1]. Still, reposition TX free
> calls as well, to have all kfree() operations performed consistently
> _after_ dma_unmap_*()/dma_free_*().
> 
> [1] Console screenshot with the problem reproduced:
> 
> salvator-x login: root
> root@salvator-x:~# ifconfig eth0 up
> Micrel KSZ9031 Gigabit PHY e680.ethernet-:00: \
>attached PHY driver [Micrel KSZ9031 Gigabit PHY]   \
>(mii_bus:phy_addr=e680.ethernet-:00, irq=235)
> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> root@salvator-x:~#
> root@salvator-x:~# ifconfig eth0 down
> ==
> BUG: KASAN: use-after-free in swiotlb_tbl_unmap_single+0xc4/0x35c
...
> ==
> Disabling lock debugging due to kernel taint
> root@salvator-x:~#
> 
> Fixes: a47b70ea86bd ("ravb: unmap descriptors when freeing rings")
> Signed-off-by: Eugeniu Rosca 

Applied and queued up for -stable, thanks.

Re: [PATCH 1/2] sh_eth: Use platform device for printing before register_netdev()

[David Miller]

From: Geert Uytterhoeven 
Date: Thu, 18 May 2017 15:01:34 +0200

> The MDIO initialization failure message is printed using the network
> device, before it has been registered, leading to:
> 
>  (null): failed to initialise MDIO
> 
> Use the platform device instead to fix this:
> 
> sh-eth ee70.ethernet: failed to initialise MDIO
> 
> Fixes: daacf03f0bbfefee ("sh_eth: Register MDIO bus before registering the 
> network device")
> Signed-off-by: Geert Uytterhoeven 

Applied.

Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral

[David Miller]

From: Geert Uytterhoeven 
Date: Thu, 18 May 2017 14:59:05 +0200

> If an Ethernet PHY is initialized before the interrupt controller it is
> connected to, a message like the following is printed:
> 
> irq: no irq domain found for /interrupt-controller@e61c !
> 
> However, the actual error is ignored, leading to a non-functional (-1)
> PHY interrupt later:
> 
> Micrel KSZ8041RNLI ee70.ethernet-:01: attached PHY driver 
> [Micrel KSZ8041RNLI] (mii_bus:phy_addr=ee70.ethernet-:01, irq=-1)
> 
> Depending on whether the PHY driver will fall back to polling, Ethernet
> may or may not work.
> 
> To fix this:
>   1. Switch of_mdiobus_register_phy() from irq_of_parse_and_map() to
>  of_irq_get().
>  Unlike the former, the latter returns -EPROBE_DEFER if the
>  interrupt controller is not yet available, so this condition can be
>  detected.
>  Other errors are handled the same as before, i.e. use the passed
>  mdio->irq[addr] as interrupt.
>   2. Propagate and handle errors from of_mdiobus_register_phy() and
>  of_mdiobus_register_device().
> 
> Signed-off-by: Geert Uytterhoeven 

Florian or someone similarly knowledgable, please review.

Re: [PATCH 2/2] sh_eth: Do not print an error message for probe deferral

[David Miller]

From: Geert Uytterhoeven 
Date: Thu, 18 May 2017 15:01:35 +0200

> EPROBE_DEFER is not an error, hence printing an error message like
> 
> sh-eth ee70.ethernet: failed to initialise MDIO
> 
> may confuse the user.
> 
> To fix this, suppress the error message in case of probe deferral.
> While at it, shorten the message, and add the actual error code.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied.

Re: [PATCH net] ravb: Double free on error in ravb_start_xmit()

[David Miller]

From: Dan Carpenter 
Date: Sat, 22 Apr 2017 13:46:56 +0300

> If skb_put_padto() fails then it frees the skb.  I shifted that code
> up a bit to make my error handling a little simpler.
> 
> Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
> Signed-off-by: Dan Carpenter 

Applied.

Re: [PATCH v2] sh_eth: unmap DMA buffers when freeing rings

[David Miller]

From: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Date: Wed, 19 Apr 2017 22:09:51 +0300

> On 04/17/2017 11:10 PM, David Miller wrote:
> 
>>> The DMA API debugging (when enabled) causes:
>>>
>>> WARNING: CPU: 0 PID: 1445 at lib/dma-debug.c:519
>>> add_dma_entry+0xe0/0x12c
>>> DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b2974d
>>>
>>> to be  printed after repeated initialization of the Ether device, e.g.
>>> suspend/resume or 'ifconfig' up/down. This is because DMA buffers
>>> mapped
>>> using dma_map_single() in sh_eth_ring_format() and sh_eth_start_xmit()
>>> are
>>> never unmapped. Resolve this problem by unmapping the buffers when
>>> freeing
>>> the descriptor rings; in order to do it right, we'd have to add an
>>> extra
>>> parameter to sh_eth_txfree() (we rename this function to
>>> sh_eth_tx_free(),
>>> while at it).
>>>
>>> Based on the commit a47b70ea86bd ("ravb: unmap descriptors when
>>> freeing
>>> rings").
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>>
>> Applied, thanks.
> 
>Please don;t forget to send it to -stable.
>The bug seems to be there from the very beginning.

Ok, queued up.

Re: [PATCH v2] sh_eth: unmap DMA buffers when freeing rings

[David Miller]

From: Sergei Shtylyov 
Date: Mon, 17 Apr 2017 15:55:22 +0300

> The DMA API debugging (when enabled) causes:
> 
> WARNING: CPU: 0 PID: 1445 at lib/dma-debug.c:519 add_dma_entry+0xe0/0x12c
> DMA-API: exceeded 7 overlapping mappings of cacheline 0x01b2974d
> 
> to be  printed after repeated initialization of the Ether device, e.g.
> suspend/resume or 'ifconfig' up/down. This is because DMA buffers mapped
> using dma_map_single() in sh_eth_ring_format() and sh_eth_start_xmit() are
> never unmapped. Resolve this problem by unmapping the buffers when freeing
> the descriptor  rings;  in order  to do it right, we'd have to add an extra
> parameter to sh_eth_txfree() (we rename this function to sh_eth_tx_free(),
> while at it).
> 
> Based on the commit a47b70ea86bd ("ravb: unmap descriptors when freeing
> rings").
> 
> Signed-off-by: Sergei Shtylyov 

Applied, thanks.

Re: [PATCH 0/2] sh_eth: fixes for MagicPacket handling

[David Miller]

From: Niklas Söderlund 
Date: Wed,  1 Feb 2017 15:41:53 +0100

> This series contain two fixes for MagicPacket handling. It's based on 
> top of net-next and is tested on Koelsch.

Series applied, thanks.

I fixed the "register" --> "registered" thing in the commit message
for patch #2 when I applied this.

Thanks again.

Re: [PATCH v2 0/3] sh_eth: E-DMAC interrupt mask cleanups

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 29 Jan 2017 15:06:39 +0300

>Here's a set of 3 patches against DaveM's 'net-next.git' repo. The main 
> goal
> of this set is to stop using the bare numbers for the E-DMAC interrupt masks.
> 
> [1/3] sh_eth: rename EESIPR bits
> [2/3] sh_eth: add missing EESIPR bits
> [3/3] sh_eth: stop using bare numbers for EESIPR values

Series applied, thank you.

Re: [PATCH v2 net-next 0/2] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W

[David Miller]

From: Simon Horman 
Date: Fri, 27 Jan 2017 19:35:18 +0100

> this series adds support for gigabit communication to the Renesas EthernetAVB
> controller when used in conjunction with  R-Car Gen3 H3 ES1.1+ and M3-W SoCs.
> Gigabit is already supported with R-Car Gen 2 SoCs.
> 
> The patch from Geert was previously posted for inclusion in v4.10 and
> acked by Dave for that purpose. It was, however, not accepted by the
> ARM SoC maintainers.
> 
> The path from Mizuguchi-san is to address timing problems observed with
> gigabit transfers. I would like it considered although my own testing on
> M3-W did not show any timing problems.

Series applied, thanks Simon.

Re: [PATCH v5 net] ravb: unmap descriptors when freeing rings

[David Miller]

From: Simon Horman 
Date: Thu, 26 Jan 2017 14:29:27 +0100

> From: Kazuya Mizuguchi 
> 
> "swiotlb buffer is full" errors occur after repeated initialisation of a
> device - f.e. suspend/resume or ip link set up/down. This is because memory
> mapped using dma_map_single() in ravb_ring_format() and ravb_start_xmit()
> is not released.  Resolve this problem by unmapping descriptors when
> freeing rings.
> 
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Signed-off-by: Kazuya Mizuguchi 
> [simon: reworked]
> Signed-off-by: Simon Horman 

Applied, thanks Simon.

Re: [PATCH v2 0/3] net: phy: leds: Fix truncated LED trigger names and crashes

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 25 Jan 2017 11:39:47 +0100

> I started seeing crashes during s2ram and poweroff on all my ARM boards,
> like:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 
> 
> ...
> [] (__list_del_entry_valid) from [] 
> (led_trigger_unregister+0x34/0xcc)
> [] (led_trigger_unregister) from [] 
> (phy_led_triggers_unregister+0x28/0x34)
> [] (phy_led_triggers_unregister) from [] 
> (phy_detach+0x30/0x74)
> [] (phy_detach) from [] (sh_eth_close+0x64/0x9c)
> [] (sh_eth_close) from [] (dpm_run_callback+0x48/0xc8)
> 
> or:
> 
> list_del corruption. prev->next should be dede6540, but was 2e323931
> [ cut here ]
> kernel BUG at lib/list_debug.c:52!
> ...
> [] (__list_del_entry_valid) from [] 
> (led_trigger_unregister+0x34/0xcc)
> [] (led_trigger_unregister) from [] 
> (phy_led_triggers_unregister+0x28/0x34)
> [] (phy_led_triggers_unregister) from [] 
> (phy_detach+0x30/0x74)
> [] (phy_detach) from [] (sh_eth_close+0x6c/0xa4)
> [] (sh_eth_close) from [] (__dev_close_many+0xac/0xd0)
> 
> As the only clue was a kernel message like
> 
> sh-eth ee70.ethernet eth0: No phy led trigger registered for 
> speed(100)
> 
> I had to bisected this, leading to commit 4567d686f5c6d955 ("phy:
> increase size of MII_BUS_ID_SIZE and bus_id").  Reverting that commit
> fixed the issue.
> 
> More investigation revealed the crashes are due to the combination of
> two things:
>   - Truncated LED trigger names, leading to duplicate names, and
> registration failures,
>   - Bad error handling in case of registration failures.
> 
> Both are fixed by this patch series.

Thanks for tracking this down and fixing it.

Series applied, thanks.

Re: [PATCH] net: constify mdiobb_ops structures

[David Miller]

From: Bhumika Goyal 
Date: Fri, 13 Jan 2017 23:32:26 +0530

> Declare mdiobb_ops structures as const as they are only stored in the
> ops field of mdiobb_ctrl structures. This field is of type const, so
> mdiobb_ops structures having this property can be declared const too.

This patch doesn't apply cleanly to net-next, please respin.

Re: [PATCH net v3] ravb: do not use zero-length alignment DMA descriptor

[David Miller]

From: Sergei Shtylyov 
Date: Mon, 16 Jan 2017 16:01:49 +0300

> On 01/16/2017 01:45 PM, Simon Horman wrote:
> 
>> From: Masaru Nagai 
>>
>> Due to alignment requirements of the hardware transmissions are split
>> into
>> two DMA descriptors, a small padding descriptor of 0 - 3 bytes in
>> length
>> followed by a descriptor for rest of the packet.
>>
>> In the case of IP packets the first descriptor will never be zero due
>> to
>> the way that the stack aligns buffers for IP packets. However, for
>> non-IP
>> packets it may be zero.
>>
>> In that case it has been reported that timeouts occur, presumably
>> because
>> transmission stops at the first zero-length DMA descriptor and thus
>> the
>> packet is not transmitted. However, in my environment a BUG is
>> triggered as
>> follows:
> [...]
> 
>> Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
>> Signed-off-by: Masaru Nagai > Signed-off-by: Simon Horman 
> 
> Acked-by: Sergei Shtylyov 

Applied and queued up for -stable, thanks.

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

[David Miller]

From: Simon Horman 
Date: Thu, 12 Jan 2017 16:46:47 +0100

> What I now see is that a few lines further up there is:
> 
>if (skb_put_padto(skb, ETH_ZLEN))
>   goto drop;
> 
>   where ETH_ZLEN is 60.
> 
> So I don't think we need to worry about skb->len being less than 60 and
> this patch can be simplified to:
> 
>   if (len == 0)
>   len = 4;

I'd say this might deserve a comment...

Re: [PATCH/RFC net] ravb: do not use zero-length alighment DMA request

[David Miller]

From: Simon Horman 
Date: Thu, 12 Jan 2017 14:53:37 +0100

> diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
> b/drivers/net/ethernet/renesas/ravb_main.c
> index 92d7692c840d..3b4d2504285e 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1508,6 +1508,8 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, 
> struct net_device *ndev)
>   buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
>entry / NUM_TX_DESC * DPTR_ALIGN;
>   len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
> + if (len == 0)
> + len = skb->len > 4 ? 4 : skb->len;
>   memcpy(buffer, skb->data, len);
>   dma_addr = dma_map_single(ndev->dev.parent, buffer, len, DMA_TO_DEVICE);
>   if (dma_mapping_error(ndev->dev.parent, dma_addr))

Assume len ends up being skb->len, then the second DMA mapping will be
made of zero length.

This code needs a bit of TLC.

Re: [PATCH net] ravb: Remove Rx overflow log messages

[David Miller]

From: Simon Horman 
Date: Thu, 12 Jan 2017 13:21:06 +0100

> From: Kazuya Mizuguchi 
> 
> Remove Rx overflow log messages as in an environment where logging results
> in network traffic logging may cause further overflows.
> 
> Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
> Signed-off-by: Kazuya Mizuguchi 
> [simon: reworked changelog]
> Signed-off-by: Simon Horman 
> Acked-by: Sergei Shtylyov 

Applied, thanks.

Re: [PATCHv3 0/6] sh_eth: add wake-on-lan support via magic packet

[David Miller]

From: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Date: Tue, 10 Jan 2017 00:48:28 +0300

> On 01/09/2017 11:55 PM, David Miller wrote:
> 
>>> This series adds support for Wake-on-Lan using Magic Packet for a few
>>> models of the sh_eth driver. Patch 1/6 fix a naming error, patch 2/6
>>> adds generic support to control and support WoL while patches 3/6 -
>>> 6/6
>>> enable different models.
>>>
>>> Based ontop of net-next master.
>>  ...
>>
>> Series applied, thanks.
> 
>That was too quick for me... I hadn't even started looking into the
>main patch yet. :-/

Sorry, today a lot of stuff got submitted and I do not want to have such
a huge backlog at the end of the day.

I can revert the entire series if you want me to.

Re: [PATCHv3 0/6] sh_eth: add wake-on-lan support via magic packet

[David Miller]

From: Niklas Söderlund 
Date: Mon,  9 Jan 2017 16:34:03 +0100

> This series adds support for Wake-on-Lan using Magic Packet for a few
> models of the sh_eth driver. Patch 1/6 fix a naming error, patch 2/6 
> adds generic support to control and support WoL while patches 3/6 - 6/6 
> enable different models.
> 
> Based ontop of net-next master.
 ...

Series applied, thanks.

Re: [PATCH 0/2] sh_eth: "intgelligent checksum" related cleanups

[David Miller]

From: Sergei Shtylyov 
Date: Sat, 07 Jan 2017 00:01:40 +0300

>Here's a set of 2 patches against DaveM's 'net.git' repo, as they are based
> on a couple patches merged there recently; however, the patches are destined
> for 'net-next.git' (once 'net.git' gets merged there next time). I'm cleaning
> up the "intelligent checksum" related code (however, the driver only disables
> this feature for now, theres's no proper offload supprt yet).

Series applied to net-next, thanks.

Re: [PATCH] sh_eth: R8A7740 supports packet shecksumming

[David Miller]

From: Sergei Shtylyov 
Date: Thu, 5 Jan 2017 12:33:21 +0300

>Oops, typo in the subject, "shecksumming". David, should I resend?

I accidently pushed this out without fixing the typo, sorry about
that but that's going to be how it is I'm afraid :-)

Re: [PATCH] sh_eth: R8A7740 supports packet shecksumming

[David Miller]

From: Sergei Shtylyov 
Date: Thu, 05 Jan 2017 00:29:32 +0300

> The R8A7740 GEther controller supports the packet checksum offloading
> but the 'hw_crc' (bad name, I'll fix it) flag isn't set in the R8A7740
> data,  thus CSMR isn't cleared...
> 
> Fixes: 73a0d907301e ("net: sh_eth: add support R8A7740")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH] sh_eth: fix EESIPR values for SH77{34|63}

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 04 Jan 2017 22:18:24 +0300

> As the SH77{34|63} manuals are freely available,  I've checked the EESIPR
> values written against the manuals, and they appeared to set the reserved
> bits 11-15 (which should be 0 on write). Fix those EESIPR values.
> 
> Fixes: 380af9e390ec ("net: sh_eth: CPU dependency code collect to "struct 
> sh_eth_cpu_data"")
> Fixes: f5d12767c8fd ("sh_eth: get SH77{34|63} support out of #ifdef")
> Signed-off-by: Sergei Shtylyov 

Applied.

Re: [PATCH] sh_eth: enable RX descriptor word 0 shift on SH7734

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 04 Jan 2017 23:10:23 +0300

> The RX descriptor word 0 on SH7734 has the RFS[9:0] field in bits 16-25
> (bits  0-15 usually used for that are occupied by the packet checksum).
> Thus  we need to set the 'shift_rd0'  field in the SH7734 SoC data...
> 
> Fixes: f0e81fecd4f8 ("net: sh_eth: Add support SH7734")
> Signed-off-by: Sergei Shtylyov 

Applied, thank you.

Re: [PATCH 0/2] sh_eth: E-MAC interrupt handler cleanups

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 04 Jan 2017 15:09:36 +0300

>Here's a set of 3 patches against DaveM's 'net-next.git' repo. I'm cleaning
> up the E-MAC interrupt handling with the main goal of factoring out the E-MAC
> interrupt handler into a separate function.
> 
> [1/3] sh_eth: handle only enabled E-MAC interrupts
> [2/3] sh_eth: no need for *else* after *goto*
> [3/3] sh_eth: factor out sh_eth_emac_interrupt()

Series applied to net-next, thanks.

Re: [PATCH] sh_eth: fix branch prediction in sh_eth_interrupt()

[David Miller]

From: Sergei Shtylyov 
Date: Fri, 30 Dec 2016 00:07:38 +0300

> IIUC, likely()/unlikely() should apply to the whole *if* statement's
> expression, not a part of it  -- fix such expression in  sh_eth_interrupt()
> accordingly...
> 
> Fixes: 283e38db65e7 ("sh_eth: Fix serialisation of interrupt disable with 
> interrupt & NAPI handlers")
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against DaveM's 'net-next.git' repo; I'm not sure if it should
> be  targeted to the 'net.git' repo instead...

I decided to apply this to 'net', thanks.

Re: [patch] net: renesas: ravb: unintialized return value

[David Miller]

From: Dan Carpenter 
Date: Thu, 1 Dec 2016 23:57:44 +0300

> We want to set the other "err" variable here so that we can return it
> later.  My version of GCC misses this issue but I caught it with a
> static checker.
> 
> Fixes: 9f70eb339f52 ("net: ethernet: renesas: ravb: fix fixed-link phydev 
> leaks")
> Signed-off-by: Dan Carpenter 

Applied.

Re: [PATCH v3] sh_eth: remove unchecked interrupts for RZ/A1

[David Miller]

From: Chris Brandt 
Date: Thu,  1 Dec 2016 13:32:14 -0500

> When streaming a lot of data and the RZ/A1 can't keep up, some status bits
> will get set that are not being checked or cleared which cause the
> following messages and the Ethernet driver to stop working. This
> patch fixes that issue.
> 
> irq 21: nobody cared (try booting with the "irqpoll" option)
> handlers:
> [] sh_eth_interrupt
> Disabling IRQ #21
> 
> Fixes: db893473d313a4ad ("sh_eth: Add support for r7s72100")
> Signed-off-by: Chris Brandt 
> Acked-by: Sergei Shtylyov 

Applied and queued up for -stable, thanks.

Re: [PATCH net 00/16] net: fix fixed-link phydev leaks

[David Miller]

From: Johan Hovold 
Date: Mon, 28 Nov 2016 19:24:53 +0100

> This series fixes failures to deregister and free fixed-link phydevs
> that have been registered using the of_phy_register_fixed_link()
> interface.
> 
> All but two drivers currently fail to do this and this series fixes most
> of them with the exception of a staging driver and the stmmac drivers
> which will be fixed by follow-on patches.
> 
> Included are also a couple of fixes for related of-node leaks.
> 
> Note that all patches except the of_mdio one have been compile-tested
> only.
> 
> Also note that the series is against net due to dependencies not yet in
> net-next.

Series applied, thanks Johan.

Re: [PATCH v2] net: phy: Fix use after free in phy_detach()

[David Miller]

From: Geert Uytterhoeven 
Date: Mon, 28 Nov 2016 15:18:31 +0100

> If device_release_driver(>mdio.dev) is called, it releases all
> resources belonging to the PHY device. Hence the subsequent call to
> phy_led_triggers_unregister() will access already freed memory when
> unregistering the LEDs.
> 
> Move the call to phy_led_triggers_unregister() before the possible call
> to device_release_driver() to fix this.
> 
> Fixes: 2e0bc452f4721520 ("net: phy: leds: add support for led triggers on phy 
> link state change")
> Signed-off-by: Geert Uytterhoeven 
> ---
> This is v2 of "[RFC] net: phy: Fix double free in phy_detach()".
> 
> v2:
>   - Dropped RFC,
>   - Reworded, as commit a7dac9f9c1695d74 ("phy: fix error case of
> phy_led_triggers_(un)register") fixed the double free, and thus the
> warning I was seeing during "poweroff" on sh73a0/kzm9g,
>   - Verified use after free using CONFIG_DEBUG_DEVRES, log_devres = 1,
> and additional debug code printing the address of
> phy->phy_led_triggers. Adding poisoning of freed memory to
> devres_log() will cause a crash.

Applied, thanks.

Re: [PATCH/RFC] ravb: Support 1Gbps on R-Car H3 ES1.1+ and R-Car M3-W

[David Miller]

From: Geert Uytterhoeven 
Date: Mon, 31 Oct 2016 18:13:38 +0100

> The limitation to 10/100Mbit speeds on R-Car Gen3 is valid for R-Car H3
> ES1.0 only. Check for the exact SoC model to allow 1Gbps on newer
> revisions of R-Car H3, and on R-Car M3-W.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> Tested on:
>   - r8a7795/salvator-x with R-Car H3 ES1.0 (limited to 100Mbps),
>   - r8a7795/salvator-x with R-Car H3 ES1.1 (1Gbps),
>   - r8a7796/salvator-x with R-Car M3-W ES1.0 (1Gbps).
> 
> This is marked as an RFC because it depends on:
>   A) the soc_device_match() infrastructure,
>   B) Renesas SoC core ESx.y handling.
> Hence I think the best merge strategy is to let this patch go in through
> Simon's Renesas tree.
> 
> David: If you agree, can you please provide your ack? Thanks!

Sure, no problem:

Acked-by: David S. Miller 

Re: [PATCH resend] sh_eth: add R8A7743/5 support

[David Miller]

From: Sergei Shtylyov 
Date: Tue, 27 Sep 2016 01:23:26 +0300

> Add support for the first two members of the Renesas RZ/G family, RZ/G1M/E
> (also known as  R8A7743/5). The Ether core is the same as in the R-Car gen2
> SoCs, so will share the code/data with them...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the DaveM's 'net-next.git' repo.
> 
> Re-sending with the DT maintainers/list included this time...

Applied, thanks Sergei.

Re: [PATCH v2] net: ethernet: renesas: sh_eth: add POST registers for rz

[David Miller]

From: Chris Brandt 
Date: Wed,  7 Sep 2016 14:57:09 -0400

> Due to a mistake in the hardware manual, the FWSLC and POST1-4 registers
> were not documented and left out of the driver for RZ/A making the CAM
> feature non-operational.
> Additionally, when the offset values for POST1-4 are left blank, the driver
> attempts to set them using an offset of 0x which can cause a memory
> corruption or panic.
> 
> This patch fixes the panic and properly enables CAM.
> 
> Reported-by: Daniel Palmer 
> Signed-off-by: Chris Brandt 

Applied, thanks.

Re: [PATCH] ravb: avoid unused function warnings

[David Miller]

From: Arnd Bergmann 
Date: Fri, 26 Aug 2016 17:30:29 +0200

> When CONFIG_PM_SLEEP is disabled, we get a couple of harmless warnings:
> 
> drivers/net/ethernet/renesas/ravb_main.c:2117:12: error: 'ravb_resume' 
> defined but not used [-Werror=unused-function]
> drivers/net/ethernet/renesas/ravb_main.c:2104:12: error: 'ravb_suspend' 
> defined but not used [-Werror=unused-function]
> 
> The simplest solution here is to replace the #ifdef with __maybe_unused
> annotations, which lets the compiler do the right thing by itself.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 0184165b2f42 ("ravb: add sleep PM suspend/resume support")

Applied, thanks.

Re: [PATCH 1/2] net: ethernet: renesas: ravb: use phydev from struct net_device

[David Miller]

From: Philippe Reynes 
Date: Sat, 20 Aug 2016 00:52:18 +0200

> The private structure contain a pointer to phydev, but the structure
> net_device already contain such pointer. So we can remove the pointer
> phy_dev in the private structure, and update the driver to use the
> one contained in struct net_device.
> 
> Signed-off-by: Philippe Reynes 

Applied.

Re: [PATCH] ravb: use proper names for suspend/resume functions

[David Miller]

From: Niklas Söderlund 
Date: Wed, 10 Aug 2016 13:09:49 +0200

> The patch 'ravb: add sleep PM suspend/resume support' used incorrect
> function names containing 'runtime' for the suspend and resume
> functions.
> 
> Reported-by: Sergei Shtylyov 
> Signed-off-by: Niklas Söderlund 

Applied, thanks.

Re: [PATCH] net: ipconfig: fix use after free

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 10 Aug 2016 12:00:35 +0200

> Hi Uwe,
> 
> On Wed, Aug 10, 2016 at 11:44 AM, Uwe Kleine-König
>  wrote:
>> ic_close_devs() calls kfree() for all devices's ic_device. Since commit
>> 2647cffb2bc6 ("net: ipconfig: Support using "delayed" DHCP replies")
>> the active device's ic_device is still used however to print the
>> ipconfig summary which results in an oops if the memory is already
>> changed. So delay freeing until after the autoconfig results are
>> reported.
> 
> Thanks!
> 
>> Fixes: 2647cffb2bc6 ("net: ipconfig: Support using "delayed" DHCP replies")
>> Reported-by: Geert Uytterhoeven 
>> Signed-off-by: Uwe Kleine-König 
> 
> Tested-by: Geert Uytterhoeven 

Applied, thanks everyone.

Re: [PATCH 2/2] ravb: add sleep PM suspend/resume support

[David Miller]

From: Sergei Shtylyov 
Date: Wed, 10 Aug 2016 13:47:26 +0300

>Ugh, I should have reviewed the patch earlier -- I was postponing this
>until I have the time to test it... Since the patch did have some
>visible issues, it should've been recast before applying. DaveM,
>please in the future could you ping me before merging?

Review patches in a timely manner.

If I can go through a 5 day email outage and still see this patch
rotting in patchwork, you could have reviewed it in time.

Re: [PATCH 2/2] ravb: add sleep PM suspend/resume support

[David Miller]

From: Niklas Söderlund 
Date: Wed,  3 Aug 2016 15:56:47 +0200

> The interface would not function after the system had been woken up
> after have been suspended (echo mem > /sys/power/state) cycle. The
> reason for this is that all device registers have been reset to its
> default values. This patch adds sleep suspend and resume functions that
> detached the interface at suspend and restore the registers and reattach
> the interface at resume.
> 
> Only the registers that are only configured at probe time needs to be
> explicitly restored by the resume handler. All other registers are
> reconfigured by either reopening the device in the resume handler (if
> the device was running when the system was suspended) or when the
> interface is opened by a user at a later time.
> 
> Signed-off-by: Niklas Söderlund 

Applied to net-next, thanks.

Re: [PATCH v3] packet: fix second argument of sock_tx_timestamp()

[David Miller]

From: Yoshihiro Shimoda 
Date: Tue, 19 Jul 2016 14:40:51 +0900

> This patch fixes an issue that a syscall (e.g. sendto syscall) cannot
> work correctly. Since the sendto syscall doesn't have msg_control buffer,
> the sock_tx_timestamp() in packet_snd() cannot work correctly because
> the socks.tsflags is set to 0.
> So, this patch sets the socks.tsflags to sk->sk_tsflags as default.
> 
> Fixes: c14ac9451c34 ("sock: enable timestamping using control messages")
> Cc: 
> Reported-by: Kazuya Mizuguchi 
> Reported-by: Keita Kobayashi 
> Signed-off-by: Yoshihiro Shimoda 

Applied.

Re: [PATCH 0/2] Fix DMA channel misreporting for the Renesas Ethernet drivers

[David Miller]

From: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Date: Mon, 18 Jul 2016 17:13:02 +0300

> Hello.
> 
> On 07/18/2016 09:24 AM, David Miller wrote:
> 
>>>Here's a set of 2 patches against DaveM's 'net.git' repo fixing
>>> up the DMA channel reporting by 'ifconfig'...
>>
>> Is some fixing some ifconfig output that is effectively meaningless
>> appropriate for 'net'?
> 
>I just don't know any more users of SIOCGIFMAP ioctl... ip?
>It seems to  also be used in net/core/rtnetlink.c...

Who cares who uses it.  The important thing to ask is what in the
world could they do with the value?

DMA masks have no meaning or usage since ISA times.

Re: [PATCH 0/2] Fix DMA channel misreporting for the Renesas Ethernet drivers

[David Miller]

From: Sergei Shtylyov 
Date: Sun, 17 Jul 2016 16:06:24 +0300

>Here's a set of 2 patches against DaveM's 'net.git' repo fixing
> up the DMA channel reporting by 'ifconfig'...

Is some fixing some ifconfig output that is effectively meaningless
appropriate for 'net'?  Sounds like 'net-next' material to me.