1. 19 1月, 2019 1 次提交
    • T
      net: phy: mdio_bus: add missing device_del() in mdiobus_register() error handling · e40e2a2e
      Thomas Petazzoni 提交于
      The current code in __mdiobus_register() doesn't properly handle
      failures returned by the devm_gpiod_get_optional() call: it returns
      immediately, without unregistering the device that was added by the
      call to device_register() earlier in the function.
      
      This leaves a stale device, which then causes a NULL pointer
      dereference in the code that handles deferred probing:
      
      [    1.489982] Unable to handle kernel NULL pointer dereference at virtual address 00000074
      [    1.498110] pgd = (ptrval)
      [    1.500838] [00000074] *pgd=00000000
      [    1.504432] Internal error: Oops: 17 [#1] SMP ARM
      [    1.509133] Modules linked in:
      [    1.512192] CPU: 1 PID: 51 Comm: kworker/1:3 Not tainted 4.20.0-00039-g3b73a4cc8b3e-dirty #99
      [    1.520708] Hardware name: Xilinx Zynq Platform
      [    1.525261] Workqueue: events deferred_probe_work_func
      [    1.530403] PC is at klist_next+0x10/0xfc
      [    1.534403] LR is at device_for_each_child+0x40/0x94
      [    1.539361] pc : [<c0683fbc>]    lr : [<c0455d90>]    psr: 200e0013
      [    1.545628] sp : ceeefe68  ip : 00000001  fp : ffffe000
      [    1.550863] r10: 00000000  r9 : c0c66790  r8 : 00000000
      [    1.556079] r7 : c0457d44  r6 : 00000000  r5 : ceeefe8c  r4 : cfa2ec78
      [    1.562604] r3 : 00000064  r2 : c0457d44  r1 : ceeefe8c  r0 : 00000064
      [    1.569129] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [    1.576263] Control: 18c5387d  Table: 0ed7804a  DAC: 00000051
      [    1.582013] Process kworker/1:3 (pid: 51, stack limit = 0x(ptrval))
      [    1.588280] Stack: (0xceeefe68 to 0xceef0000)
      [    1.592630] fe60:                   cfa2ec78 c0c03c08 00000000 c0457d44 00000000 c0c66790
      [    1.600814] fe80: 00000000 c0455d90 ceeefeac 00000064 00000000 0d7a542e cee9d494 cfa2ec78
      [    1.608998] fea0: cfa2ec78 00000000 c0457d44 c0457d7c cee9d494 c0c03c08 00000000 c0455dac
      [    1.617182] fec0: cf98ba44 cf926a00 cee9d494 0d7a542e 00000000 cf935a10 cf935a10 cf935a10
      [    1.625366] fee0: c0c4e9b8 c0457d7c c0c4e80c 00000001 cf935a10 c0457df4 cf935a10 c0c4e99c
      [    1.633550] ff00: c0c4e99c c045a27c c0c4e9c4 ced63f80 cfde8a80 cfdebc00 00000000 c013893c
      [    1.641734] ff20: cfde8a80 cfde8a80 c07bd354 ced63f80 ced63f94 cfde8a80 00000008 c0c02d00
      [    1.649936] ff40: cfde8a98 cfde8a80 ffffe000 c0139a30 ffffe000 c0c6624a c07bd354 00000000
      [    1.658120] ff60: ffffe000 cee9e780 ceebfe00 00000000 ceeee000 ced63f80 c0139788 cf8cdea4
      [    1.666304] ff80: cee9e79c c013e598 00000001 ceebfe00 c013e44c 00000000 00000000 00000000
      [    1.674488] ffa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
      [    1.682671] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    1.690855] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [    1.699058] [<c0683fbc>] (klist_next) from [<c0455d90>] (device_for_each_child+0x40/0x94)
      [    1.707241] [<c0455d90>] (device_for_each_child) from [<c0457d7c>] (device_reorder_to_tail+0x38/0x88)
      [    1.716476] [<c0457d7c>] (device_reorder_to_tail) from [<c0455dac>] (device_for_each_child+0x5c/0x94)
      [    1.725692] [<c0455dac>] (device_for_each_child) from [<c0457d7c>] (device_reorder_to_tail+0x38/0x88)
      [    1.734927] [<c0457d7c>] (device_reorder_to_tail) from [<c0457df4>] (device_pm_move_to_tail+0x28/0x40)
      [    1.744235] [<c0457df4>] (device_pm_move_to_tail) from [<c045a27c>] (deferred_probe_work_func+0x58/0x8c)
      [    1.753746] [<c045a27c>] (deferred_probe_work_func) from [<c013893c>] (process_one_work+0x210/0x4fc)
      [    1.762888] [<c013893c>] (process_one_work) from [<c0139a30>] (worker_thread+0x2a8/0x5c0)
      [    1.771072] [<c0139a30>] (worker_thread) from [<c013e598>] (kthread+0x14c/0x154)
      [    1.778482] [<c013e598>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
      [    1.785689] Exception stack(0xceeeffb0 to 0xceeefff8)
      [    1.790739] ffa0:                                     00000000 00000000 00000000 00000000
      [    1.798923] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    1.807107] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
      [    1.813724] Code: e92d47f0 e1a05000 e8900048 e1a00003 (e5937010)
      [    1.819844] ---[ end trace 3c2c0c8b65399ec9 ]---
      
      The actual error that we had from devm_gpiod_get_optional() was
      -EPROBE_DEFER, due to the GPIO being provided by a driver that is
      probed later than the Ethernet controller driver.
      
      To fix this, we simply add the missing device_del() invocation in the
      error path.
      
      Fixes: 69226896 ("mdio_bus: Issue GPIO RESET to PHYs")
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e40e2a2e
  2. 18 9月, 2018 1 次提交
  3. 05 6月, 2018 1 次提交
    • H
      net: phy: remove PM ops from MDIO bus · 9107c05e
      Heiner Kallweit 提交于
      Current implementation of MDIO bus PM ops doesn't actually implement
      bus-specific PM ops but just calls PM ops defined on a device level
      what doesn't seem to be fully in line with the core PM model.
      
      When looking e.g. at __device_suspend() the PM core looks for PM ops
      of a device in a specific order:
      1. device PM domain
      2. device type
      3. device class
      4. device bus
      
      I think it has good reason that there's no PM ops on device level.
      
      Now that a device type representation of PHY's as special type of MDIO
      devices was added (only user of MDIO bus PM ops), the MDIO bus
      PM ops can be removed including member pm of struct mdio_device.
      
      If for some other type of MDIO device PM ops are needed, it should be
      modeled as struct device_type as well.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9107c05e
  4. 07 2月, 2018 1 次提交
  5. 04 1月, 2018 2 次提交
  6. 14 12月, 2017 1 次提交
  7. 06 12月, 2017 1 次提交
    • S
      phylib: Add device reset GPIO support · bafbdd52
      Sergei Shtylyov 提交于
      The PHY devices sometimes do have their reset signal (maybe even power
      supply?) tied to some GPIO and sometimes it also does happen that a boot
      loader does not leave it deasserted. So far this issue has been attacked
      from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
      the GPIO in question; that solution, when applied to the device trees, led
      to adding the PHY reset GPIO properties to the MAC device node, with one
      exception: Cadence MACB driver which could handle the "reset-gpios" prop
      in a PHY device subnode. I believe that the correct approach is to teach
      the 'phylib' to get the MDIO device reset GPIO from the device tree node
      corresponding to this device -- which this patch is doing...
      
      Note that I had to modify the AT803x PHY driver as it would stop working
      otherwise -- it made use of the reset GPIO for its own purposes...
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Acked-by: NRob Herring <robh@kernel.org>
      [geert: Propagate actual errors from fwnode_get_named_gpiod()]
      [geert: Avoid destroying initial setup]
      [geert: Consolidate GPIO descriptor acquiring code]
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: NRichard Leitner <richard.leitner@skidata.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bafbdd52
  8. 09 9月, 2017 1 次提交
  9. 18 7月, 2017 1 次提交
  10. 14 6月, 2017 2 次提交
  11. 03 6月, 2017 1 次提交
  12. 01 6月, 2017 1 次提交
    • R
      net: fix auto-loading of Marvell DSA driver · 1b8f8694
      Russell King 提交于
      Auto-loading of the Marvell DSA driver has stopped working with recent
      kernels.  This seems to be due to the change of binding for DSA devices,
      moving them from the platform bus to the MDIO bus.
      
      In order for module auto-loading to work, we need to provide a MODALIAS
      string in the uevent file for the device.  However, the device core does
      not automatically provide this, and needs each bus_type to implement a
      uevent method to generate these strings.  The MDIO bus does not provide
      such a method, so no MODALIAS string is provided:
      
      .# cat /sys/bus/mdio_bus/devices/f1072004.mdio-mii\:04/uevent
      DRIVER=mv88e6085
      OF_NAME=switch
      OF_FULLNAME=/soc/internal-regs/mdio@72004/switch@4
      OF_COMPATIBLE_0=marvell,mv88e6085
      OF_COMPATIBLE_N=1
      
      In the case of OF-based devices, the solution is easy -
      of_device_uevent_modalias() does the work for us.  After this is done,
      the uevent file looks like this:
      
      .# cat /sys/bus/mdio_bus/devices/f1072004.mdio-mii\:04/uevent
      DRIVER=mv88e6085
      OF_NAME=switch
      OF_FULLNAME=/soc/internal-regs/mdio@72004/switch@4
      OF_COMPATIBLE_0=marvell,mv88e6085
      OF_COMPATIBLE_N=1
      MODALIAS=of:NswitchT<NULL>Cmarvell,mv88e6085
      
      which results in auto-loading of the Marvell DSA driver on Clearfog
      platforms.
      
      Fixes: c0405563 ("ARM: dts: armada-388-clearfog: Utilize new DSA binding")
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b8f8694
  13. 12 5月, 2017 1 次提交
  14. 25 4月, 2017 1 次提交
    • R
      mdio_bus: Issue GPIO RESET to PHYs. · 69226896
      Roger Quadros 提交于
      Some boards [1] leave the PHYs at an invalid state
      during system power-up or reset thus causing unreliability
      issues with the PHY which manifests as PHY not being detected
      or link not functional. To fix this, these PHYs need to be RESET
      via a GPIO connected to the PHY's RESET pin.
      
      Some boards have a single GPIO controlling the PHY RESET pin of all
      PHYs on the bus whereas some others have separate GPIOs controlling
      individual PHY RESETs.
      
      In both cases, the RESET de-assertion cannot be done in the PHY driver
      as the PHY will not probe till its reset is de-asserted.
      So do the RESET de-assertion in the MDIO bus driver.
      
      [1] - am572x-idk, am571x-idk, a437x-idk
      Signed-off-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69226896
  15. 30 3月, 2017 1 次提交
    • F
      net: phy: Allow building mdio-boardinfo into the kernel · d0281a56
      Florian Fainelli 提交于
      mdio-boardinfo contains code that is helpful for platforms to register
      specific MDIO bus devices independent of how CONFIG_MDIO_DEVICE or
      CONFIG_PHYLIB will be selected (modular or built-in). In order to make
      that possible, let's do the following:
      
      - descend into drivers/net/phy/ unconditionally
      
      - make mdiobus_setup_mdiodev_from_board_info() take a callback argument
        which allows us not to expose the internal MDIO board info list and
        mutex, yet maintain the logic within the same file
      
      - relocate the code that creates a MDIO device into
        drivers/net/phy/mdio_bus.c
      
      - build mdio-boardinfo.o into the kernel as soon as MDIO_DEVICE is
        defined (y or m)
      
      Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
      Fixes: 648ea013 ("net: phy: Allow pre-declaration of MDIO devices")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0281a56
  16. 25 3月, 2017 1 次提交
    • F
      net: phy: Allow splitting MDIO bus/device support from PHYs · 90eff909
      Florian Fainelli 提交于
      Introduce a new configuration symbol: MDIO_DEVICE which allows building
      the MDIO devices and bus code, without pulling in the entire Ethernet
      PHY library and devices code.
      
      PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
      updated to reflect that.
      
      When MDIO_DEVICE (MDIO bus/device only) is selected, but not PHYLIB, we
      have mdio-bus.ko as a loadable module, and it does not have a
      module_exit() function because the safety of removing a bus class is
      unclear.
      
      When both MDIO_DEVICE and PHYLIB are enabled, we need to assemble
      everything into a common loadable module: libphy.ko because of nasty
      circular dependencies between phy.c, phy_device.c and mdio_bus.c which
      are really tough to untangle.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90eff909
  17. 07 2月, 2017 1 次提交
  18. 25 11月, 2016 1 次提交
  19. 05 5月, 2016 1 次提交
  20. 02 5月, 2016 1 次提交
    • M
      mdio_bus: Fix MDIO bus scanning in __mdiobus_register() · 70e927b9
      Marek Vasut 提交于
      Since commit b74766a0 ("phylib: don't return NULL
      from get_phy_device()") in linux-next, phy_get_device() will return
      ERR_PTR(-ENODEV) instead of NULL if the PHY device ID is all ones.
      
      This causes problem with stmmac driver and likely some other drivers
      which call mdiobus_register(). I triggered this bug on SoCFPGA MCVEVK
      board with linux-next 20160427 and 20160428. In case of the stmmac, if
      there is no PHY node specified in the DT for the stmmac block, the stmmac
      driver ( drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c function
      stmmac_mdio_register() ) will call mdiobus_register() , which will
      register the MDIO bus and probe for the PHY.
      
      The mdiobus_register() resp. __mdiobus_register() iterates over all of
      the addresses on the MDIO bus and calls mdiobus_scan() for each of them,
      which invokes get_phy_device(). Before the aforementioned patch, the
      mdiobus_scan() would return NULL if no PHY was found on a given address
      and mdiobus_register() would continue and try the next PHY address. Now,
      mdiobus_scan() returns ERR_PTR(-ENODEV), which is caught by the
      'if (IS_ERR(phydev))' condition and the loop exits immediately if the
      PHY address does not contain PHY.
      
      Repair this by explicitly checking for the ERR_PTR(-ENODEV) and if this
      error comes around, continue with the next PHY address.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70e927b9
  21. 27 4月, 2016 1 次提交
  22. 12 4月, 2016 1 次提交
  23. 13 1月, 2016 1 次提交
  24. 08 1月, 2016 10 次提交
  25. 23 10月, 2015 1 次提交
  26. 26 9月, 2015 1 次提交
  27. 25 9月, 2015 3 次提交
    • R
      phy: add phy_device_remove() · 38737e49
      Russell King 提交于
      Add a phy_device_remove() function to complement phy_device_register(),
      which undoes the effects of phy_device_register() by removing the phy
      device from visibility, but not freeing it.
      
      This allows these details to be moved out of the mdio bus code into
      the phy code where this action belongs.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38737e49
    • R
      phy: fix mdiobus module safety · 3e3aaf64
      Russell King 提交于
      Re-implement the mdiobus module refcounting to ensure that we actually
      ensure that the mdiobus module code does not go away while we might call
      into it.
      
      The old scheme using bus->dev.driver was buggy, because bus->dev is a
      class device which never has a struct device_driver associated with it,
      and hence the associated code trying to obtain a refcount did nothing
      useful.
      
      Instead, take the approach that other subsystems do: pass the module
      when calling mdiobus_register(), and record that in the mii_bus struct.
      When we need to increment the module use count in the phy code, use
      this stored pointer.  When the phy is deteched, drop the module
      refcount, remembering that the phy device might go away at that point.
      
      This doesn't stop the mii_bus going away while there are in-use phys -
      it merely stops the underlying code vanishing.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e3aaf64
    • R
      phy: fix of_mdio_find_bus() device refcount leak · a1364421
      Russell King 提交于
      of_mdio_find_bus() leaks a struct device refcount, caused by using
      class_find_device() and not realising that the device reference has
      its refcount incremented:
      
       * Note, you will need to drop the reference with put_device() after use.
      ...
              while ((dev = class_dev_iter_next(&iter))) {
                      if (match(dev, data)) {
                              get_device(dev);
                              break;
                      }
      
      Update the comment, and arrange for the phy code to drop this refcount
      when disposing of a reference to it.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a1364421