1. 27 6月, 2020 1 次提交
  2. 24 6月, 2020 1 次提交
  3. 05 6月, 2020 1 次提交
  4. 07 5月, 2020 1 次提交
  5. 23 4月, 2020 2 次提交
  6. 21 4月, 2020 1 次提交
  7. 08 4月, 2020 1 次提交
  8. 18 3月, 2020 2 次提交
  9. 25 2月, 2020 1 次提交
    • J
      mdio_bus: Add generic mdio_find_bus() · ce69e216
      Jeremy Linton 提交于
      It appears most ethernet drivers follow one of two main strategies
      for mdio bus/phy management. A monolithic model where the net driver
      itself creates, probes and uses the phy, and one where an external
      mdio/phy driver instantiates the mdio bus/phy and the net driver
      only attaches to a known phy. Usually in this latter model the phys
      are discovered via DT relationships or simply phy name/address
      hardcoding.
      
      This is a shame because modern well behaved mdio buses are self
      describing and can be probed. The mdio layer itself is fully capable
      of this, yet there isn't a clean way for a standalone net driver
      to attach and enumerate the discovered devices. This is because
      outside of of_mdio_find_bus() there isn't a straightforward way
      to acquire the mii_bus pointer.
      
      So, lets add a mdio_find_bus which can return the mii_bus based
      only on its name.
      Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce69e216
  10. 17 1月, 2020 1 次提交
    • F
      net: phy: Maintain MDIO device and bus statistics · 080bb352
      Florian Fainelli 提交于
      We maintain global statistics for an entire MDIO bus, as well as broken
      down, per MDIO bus address statistics. Given that it is possible for
      MDIO devices such as switches to access MDIO bus addresses for which
      there is not a mdio_device instance created (therefore not a a
      corresponding device directory in sysfs either), we also maintain
      per-address statistics under the statistics folder. The layout looks
      like this:
      
      /sys/class/mdio_bus/../statistics/
      	transfers
      	errrors
      	writes
      	reads
      	transfers_<addr>
      	errors_<addr>
      	writes_<addr>
      	reads_<addr>
      
      When a mdio_device instance is registered, a statistics/ folder is
      created with the tranfers, errors, writes and reads attributes which
      point to the appropriate MDIO bus statistics structure.
      
      Statistics are 64-bit unsigned quantities and maintained through the
      u64_stats_sync.h helper functions.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      080bb352
  11. 15 1月, 2020 1 次提交
  12. 26 11月, 2019 1 次提交
  13. 20 11月, 2019 3 次提交
  14. 19 11月, 2019 1 次提交
    • M
      mdio_bus: fix mdio_register_device when RESET_CONTROLLER is disabled · 075e238d
      Marek Behún 提交于
      When CONFIG_RESET_CONTROLLER is disabled, the
      devm_reset_control_get_exclusive function returns -ENOTSUPP. This is not
      handled in subsequent check and then the mdio device fails to probe.
      
      When CONFIG_RESET_CONTROLLER is enabled, its code checks in OF for reset
      device, and since it is not present, returns -ENOENT. -ENOENT is handled.
      Add -ENOTSUPP also.
      
      This happened to me when upgrading kernel on Turris Omnia. You either
      have to enable CONFIG_RESET_CONTROLLER or use this patch.
      Signed-off-by: NMarek Behún <marek.behun@nic.cz>
      Fixes: 71dd6c0d ("net: phy: add support for reset-controller")
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      075e238d
  15. 12 11月, 2019 1 次提交
  16. 16 9月, 2019 1 次提交
  17. 30 7月, 2019 1 次提交
    • S
      drivers: Introduce device lookup variants by of_node · cfba5de9
      Suzuki K Poulose 提交于
      Introduce wrappers for {bus/driver/class}_find_device() to
      locate devices by its of_node.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: devicetree@vger.kernel.org
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: linux-i2c@vger.kernel.org
      Cc: linux-rockchip@lists.infradead.org
      Cc: linux-spi@vger.kernel.org
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Alan Tull <atull@kernel.org>
      Cc: linux-fpga@vger.kernel.org
      Cc: Peter Rosin <peda@axentia.se>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Thor Thayer <thor.thayer@linux.intel.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Peter Rosin <peda@axentia.se>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Acked-by: Wolfram Sang <wsa@the-dreams.de> # I2C part
      Acked-by: Moritz Fischer <mdf@kernel.org> # For FPGA part
      Acked-by: NMark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20190723221838.12024-3-suzuki.poulose@arm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfba5de9
  18. 19 4月, 2019 2 次提交
  19. 23 2月, 2019 1 次提交
    • Y
      mdio_bus: Fix use-after-free on device_register fails · 6ff7b060
      YueHaibing 提交于
      KASAN has found use-after-free in fixed_mdio_bus_init,
      commit 0c692d07 ("drivers/net/phy/mdio_bus.c: call
      put_device on device_register() failure") call put_device()
      while device_register() fails,give up the last reference
      to the device and allow mdiobus_release to be executed
      ,kfreeing the bus. However in most drives, mdiobus_free
      be called to free the bus while mdiobus_register fails.
      use-after-free occurs when access bus again, this patch
      revert it to let mdiobus_free free the bus.
      
      KASAN report details as below:
      
      BUG: KASAN: use-after-free in mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
      Read of size 4 at addr ffff8881dc824d78 by task syz-executor.0/3524
      
      CPU: 1 PID: 3524 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xfa/0x1ce lib/dump_stack.c:113
       print_address_description+0x65/0x270 mm/kasan/report.c:187
       kasan_report+0x149/0x18d mm/kasan/report.c:317
       mdiobus_free+0x85/0x90 drivers/net/phy/mdio_bus.c:482
       fixed_mdio_bus_init+0x283/0x1000 [fixed_phy]
       ? 0xffffffffc0e40000
       ? 0xffffffffc0e40000
       ? 0xffffffffc0e40000
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f6215c19c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
      RBP: 00007f6215c19c70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6215c1a6bc
      R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
      
      Allocated by task 3524:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:496
       kmalloc include/linux/slab.h:545 [inline]
       kzalloc include/linux/slab.h:740 [inline]
       mdiobus_alloc_size+0x54/0x1b0 drivers/net/phy/mdio_bus.c:143
       fixed_mdio_bus_init+0x163/0x1000 [fixed_phy]
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 3524:
       set_track mm/kasan/common.c:85 [inline]
       __kasan_slab_free+0x130/0x180 mm/kasan/common.c:458
       slab_free_hook mm/slub.c:1409 [inline]
       slab_free_freelist_hook mm/slub.c:1436 [inline]
       slab_free mm/slub.c:2986 [inline]
       kfree+0xe1/0x270 mm/slub.c:3938
       device_release+0x78/0x200 drivers/base/core.c:919
       kobject_cleanup lib/kobject.c:662 [inline]
       kobject_release lib/kobject.c:691 [inline]
       kref_put include/linux/kref.h:67 [inline]
       kobject_put+0x146/0x240 lib/kobject.c:708
       put_device+0x1c/0x30 drivers/base/core.c:2060
       __mdiobus_register+0x483/0x560 drivers/net/phy/mdio_bus.c:382
       fixed_mdio_bus_init+0x26b/0x1000 [fixed_phy]
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff8881dc824c80
       which belongs to the cache kmalloc-2k of size 2048
      The buggy address is located 248 bytes inside of
       2048-byte region [ffff8881dc824c80, ffff8881dc825480)
      The buggy address belongs to the page:
      page:ffffea0007720800 count:1 mapcount:0 mapping:ffff8881f6c02800 index:0x0 compound_mapcount: 0
      flags: 0x2fffc0000010200(slab|head)
      raw: 02fffc0000010200 0000000000000000 0000000500000001 ffff8881f6c02800
      raw: 0000000000000000 00000000800f000f 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8881dc824c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff8881dc824c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff8881dc824d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                      ^
       ffff8881dc824d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8881dc824e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      Fixes: 0c692d07 ("drivers/net/phy/mdio_bus.c: call put_device on device_register() failure")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ff7b060
  20. 19 2月, 2019 1 次提交
  21. 23 1月, 2019 1 次提交
  22. 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
  23. 17 1月, 2019 1 次提交
  24. 18 9月, 2018 1 次提交
  25. 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
  26. 07 2月, 2018 1 次提交
  27. 04 1月, 2018 2 次提交
  28. 14 12月, 2017 1 次提交
  29. 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
  30. 09 9月, 2017 1 次提交
  31. 18 7月, 2017 1 次提交
  32. 14 6月, 2017 2 次提交
  33. 03 6月, 2017 1 次提交