1. 04 Feb, 2021 3 commits
    • Mike Looijmans's avatar
      net: mdiobus: Prevent spike on MDIO bus reset signal · e0183b97
      Mike Looijmans authored
      The mdio_bus reset code first de-asserted the reset by allocating with
      GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if
      the reset signal defaulted to asserted, there'd be a short "spike"
      before the reset.
      
      Here is what happens depending on the pre-existing state of the reset
      signal:
      Reset (previously asserted):   ~~~|_|~~~~|_______
      Reset (previously deasserted): _____|~~~~|_______
                                        ^ ^    ^
                                        A B    C
      
      At point A, the low going transition is because the reset line is
      requested using GPIOD_OUT_LOW. If the line is successfully requested,
      the first thing we do is set it high _without_ any delay. This is
      point B. So, a glitch occurs between A and B.
      
      We then fsleep() and finally set the GPIO low at point C.
      
      Requesting the line using GPIOD_OUT_HIGH eliminates the A and B
      transitions. Instead we get:
      
      Reset (previously asserted)  : ~~~~~~~~~~|______
      Reset (previously deasserted): ____|~~~~~|______
                                         ^     ^
                                         A     C
      
      Where A and C are the points described above in the code. Point B
      has been eliminated.
      
      The issue was found when we pulled down the reset signal for the
      Marvell 88E1512P PHY (because it requires at least 50ms after POR with
      an active clock). Looking at the reset signal with a scope revealed a
      short spike, point B in the artwork above.
      Signed-off-by: default avatarMike Looijmans <mike.looijmans@topic.nl>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20210202143239.10714-1-mike.looijmans@topic.nlSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e0183b97
    • Dan Carpenter's avatar
      net: mscc: ocelot: fix error code in mscc_ocelot_probe() · 4160d9ec
      Dan Carpenter authored
      Probe should return an error code if platform_get_irq_byname() fails
      but it returns success instead.
      
      Fixes: 6c30384e ("net: mscc: ocelot: register devlink ports")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Link: https://lore.kernel.org/r/YBkXyFIl4V9hgxYM@mwandaSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4160d9ec
    • Dan Carpenter's avatar
      net: mscc: ocelot: fix error handling bugs in mscc_ocelot_init_ports() · e0c16233
      Dan Carpenter authored
      There are several error handling bugs in mscc_ocelot_init_ports().  I
      went through the code, and carefully audited it and made fixes and
      cleanups.
      
      1) The ocelot_probe_port() function didn't have a mirror release function
         so it was hard to follow.  I created the ocelot_release_port()
         function.
      2) In the ocelot_probe_port() function, if the register_netdev() call
         failed, then it lead to a double free_netdev(dev) bug.  Fix this by
         setting "ocelot->ports[port] = NULL" on the error path.
      3) I was concerned that the "port" which comes from of_property_read_u32()
         might be out of bounds so I added a check for that.
      4) In the original code if ocelot_regmap_init() failed then the driver
         tried to continue but I think that should be a fatal error.
      5) If ocelot_probe_port() failed then the most recent devlink was leaked.
         The fix for mostly came Vladimir Oltean.  Get rid of "registered_ports"
         and just set a bit in "devlink_ports_registered" to say when the
         devlink port has been registered (and needs to be unregistered on
         error).  There are fewer than 32 ports so a u32 is large enough for
         this purpose.
      6) The error handling if the final ocelot_port_devlink_init() failed had
         two problems.  The "while (port-- >= 0)" loop should have been
         "--port" pre-op instead of a post-op to avoid a buffer underflow.
         The "if (!registered_ports[port])" condition was reversed leading to
         resource leaks and double frees.
      
      Fixes: 6c30384e ("net: mscc: ocelot: register devlink ports")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Link: https://lore.kernel.org/r/YBkXhqRxHtRGzSnJ@mwandaSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e0c16233
  2. 03 Feb, 2021 37 commits