1. 19 Mar, 2023 34 commits
  2. 18 Mar, 2023 4 commits
    • Sakari Ailus's avatar
      media: v4l: subdev: Make link validation safer · 55f1ecb1
      Sakari Ailus authored
      Link validation currently accesses invalid pointers if the link passed to
      it is not between two sub-devices. This is of course a driver bug.
      
      Ignore the error but print a warning message, as this is how it used to
      work previously.
      
      Fixes: a6b995ed ("media: subdev: use streams in v4l2_subdev_link_validate()")
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Tested-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      55f1ecb1
    • Tomi Valkeinen's avatar
      media: subdev: Fix validation state lockdep issue · 53077915
      Tomi Valkeinen authored
      The new subdev state code has a possible deadlock scenario during link
      validation when the pipeline contains subdevs that support state and
      that do not support state.
      
      The current code locks the states of the subdevs on both ends of the
      link when starting the link validation, locking the sink side first,
      then the source. If either (or both) of the subdevs does not support
      state, nothing is done for that subdev at this point, and instead the
      locking is handled the old way, i.e. the subdev's ops do the locking
      internally.
      
      The issue arises when the sink doesn't support state, but source does,
      so the validation code locks the source for the duration of the
      validation, and then the sink is locked only when the get_fmt op is
      called. So lockdep sees the source locked first, then the sink.
      
      Later, when the streaming is started, the sink's s_stream op is called,
      which probably takes the subdev's lock. The op then calls the source's
      s_stream, which takes the source's lock. So, the sink is locked first,
      then the source.
      
      Note that link validation and stream starting is not done at the same
      time, so an actual deadlock should never happen. However, it's still a
      clear bug.
      
      Fix this by locking the subdev states only if both subdevs support
      state. In other words, we have two scenarios:
      
      1. Both subdevs support state. Lock sink first, then source, and keep
         the locks while validating the link.
      2. At least one of the subdevs do not support state. Take the lock only
         for the duration of the operation (get_fmt or looking at the
         routing), and release after the op is done.
      
      Obviously 1. is better, as we have a more consistent view of the states
      of the subdevs during validation. 2. is how it has been so far, so it's
      no worse than this used to be.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      53077915
    • Arnd Bergmann's avatar
      media: i2c: imx290: fix conditional function definitions · b928db94
      Arnd Bergmann authored
      The runtime suspend/resume functions are only referenced from the
      dev_pm_ops, but they use the old SET_RUNTIME_PM_OPS() helper
      that requires a __maybe_unused annotation to avoid a warning:
      
      drivers/media/i2c/imx290.c:1082:12: error: unused function 'imx290_runtime_resume' [-Werror,-Wunused-function]
      static int imx290_runtime_resume(struct device *dev)
                 ^
      drivers/media/i2c/imx290.c:1090:12: error: unused function 'imx290_runtime_suspend' [-Werror,-Wunused-function]
      static int imx290_runtime_suspend(struct device *dev)
                 ^
      
      Convert this to the new RUNTIME_PM_OPS() helper that so this
      is not required. To improve this further, also use the pm_ptr()
      helper that lets the dev_pm_ops get dropped entirely when
      CONFIG_PM is disabled.
      
      A related mistake happened in the of_match_ptr() macro here, which
      like SET_RUNTIME_PM_OPS() requires the match table to be marked
      as __maybe_unused, though I could not reproduce building this without
      CONFIG_OF. Remove the of_match_ptr() here as there is no point in
      dropping the match table in configurations without CONFIG_OF.
      
      Fixes: 02852c01 ("media: i2c: imx290: Initialize runtime PM before subdev")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      b928db94
    • Javier Martinez Canillas's avatar
      media: Revert "venus: firmware: Correct non-pix start and end addresses" · b0d944bc
      Javier Martinez Canillas authored
      This reverts commit a837e516, which broke
      probing of the venus driver, at least on the SC7180 SoC HP X2 Chromebook:
      
        [   11.455782] qcom-venus aa00000.video-codec: Adding to iommu group 11
        [   11.506980] qcom-venus aa00000.video-codec: non legacy binding
        [   12.143432] qcom-venus aa00000.video-codec: failed to reset venus core
        [   12.156440] qcom-venus: probe of aa00000.video-codec failed with error -110
      
      Matthias Kaehlcke also reported that the same change caused a regression in
      SC7180 and sc7280, that prevents AOSS from entering sleep mode during system
      suspend. So let's revert this commit for now to fix both issues.
      
      Fixes: a837e516 ("venus: firmware: Correct non-pix start and end addresses")
      Reported-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Signed-off-by: default avatarStanimir Varbanov <stanimir.k.varbanov@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@kernel.org>
      b0d944bc
  3. 12 Mar, 2023 2 commits