Skip to content

L
linux
Switch branch/tag
  1. 04 Feb, 2021 4 commits
    • Srujana Challa's avatar
      octeontx2-af: Mailbox changes for 98xx CPT block · de2854c8
      Srujana Challa authored 
      This patch changes CPT mailbox message format to
support new block CPT1 in 98xx silicon.

cpt_rd_wr_reg ->
    Modify cpt_rd_wr_reg mailbox and its handler to
    accommodate new block CPT1.
cpt_lf_alloc ->
    Modify cpt_lf_alloc mailbox and its handler to
    configure LFs from a block address out of multiple
    blocks of same type. If a PF/VF needs to configure
    LFs from both the blocks then this mbox should be
    called twice.
Signed-off-by: default avatarMahipal Challa <mchalla@marvell.com>
Signed-off-by: default avatarSrujana Challa <schalla@marvell.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      de2854c8
    • 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
  3. 03 Feb, 2021 36 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7