Skip to content
  1. Jan 19, 2018
    • Arnd Bergmann's avatar
      phy: work around 'phys' references to usb-nop-xceiv devices · b7563e27
      Arnd Bergmann authored
      Stefan Wahren reports a problem with a warning fix that was merged
      for v4.15: we had lots of device nodes with a 'phys' property pointing
      to a device node that is not compliant with the binding documented in
      Documentation/devicetree/bindings/phy/phy-bindings.txt
      
      This generally works because USB HCD drivers that support both the generic
      phy subsystem and the older usb-phy subsystem ignore most errors from
      phy_get() and related calls and then use the usb-phy driver instead.
      
      However, it turns out that making the usb-nop-xceiv device compatible with
      the generic-phy binding changes the phy_get() return code from -EINVAL to
      -EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
      -EPROBE_DEFER from its probe function rather than ignoring the failure,
      breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
      enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
      function, so a reasonable assumption would be that many other platforms
      are affected as well.
      
      I have reviewed all the related patches and concluded that "usb-nop-xceiv"
      is the only USB phy that is affected by the change, and since it is by far
      the most commonly referenced phy, all the other USB phy drivers appear
      to be used in ways that are are either safe in DT (they don't use the
      'phys' property), or in the driver (they already ignore -EPROBE_DEFER
      from generic-phy when usb-phy is available).
      
      To work around the problem, this adds a special case to _of_phy_get()
      so we ignore any PHY node that is compatible with "usb-nop-xceiv",
      as we know that this can never load no matter how much we defer. In the
      future, we might implement a generic-phy driver for "usb-nop-xceiv"
      and then remove this workaround.
      
      Since we generally want older kernels to also want to work with the
      fixed devicetree files, it would be good to backport the patch into
      stable kernels as well (3.13+ are possibly affected), even though they
      don't contain any of the patches that may have caused regressions.
      
      Fixes: 014d6da6 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
      Fixes: c5bbf358 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
      Fixes: 44e5dced arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
      Fixes: f568f6f5 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
      Fixes: d745d5f2 ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
      Fixes: 915fbe59 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
      Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
      Link: https://patchwork.kernel.org/patch/10158145/
      
      
      Cc: stable@vger.kernel.org
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Eric Anholt <eric@anholt.net>
      Tested-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Tested-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      b7563e27
    • Maxime Ripard's avatar
      ARM: sunxi_defconfig: Enable CMA · c13e7f31
      Maxime Ripard authored
      
      
      The DRM driver most notably, but also out of tree drivers (for now) like
      the VPU or GPU drivers, are quite big consumers of large, contiguous memory
      buffers. However, the sunxi_defconfig doesn't enable CMA in order to
      mitigate that, which makes them almost unusable.
      
      Enable it to make sure it somewhat works.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c13e7f31
  2. Jan 12, 2018
  3. Jan 08, 2018
  4. Jan 07, 2018
  5. Jan 06, 2018
  6. Jan 05, 2018