1. 26 7月, 2017 11 次提交
    • P
      media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS · b25db383
      Prabhakar Lad 提交于
      drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons:
      
      - This ioctl was never in public api and was only defined in kernel header.
      - The function set_params constantly mixes up pointers and phys_addr_t
        numbers.
      - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
        described as an 'experimental ioctl that will change in future kernels'.
      - The code to allocate the table never gets called after we copy_from_user
        the user input over the kernel settings, and then compare them
        for inequality.
      - We then go on to use an address provided by user space as both the
        __user pointer for input and pass it through phys_to_virt to come up
        with a kernel pointer to copy the data to. This looks like a trivially
        exploitable root hole.
      Signed-off-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      b25db383
    • P
      media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl · da05d52d
      Prabhakar Lad 提交于
      this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
      for vpfe_capture driver with a minimal patch suitable for backporting.
      
      - This ioctl was never in public api and was only defined in kernel header.
      - The function set_params constantly mixes up pointers and phys_addr_t
        numbers.
      - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
        described as an 'experimental ioctl that will change in future kernels'.
      - The code to allocate the table never gets called after we copy_from_user
        the user input over the kernel settings, and then compare them
        for inequality.
      - We then go on to use an address provided by user space as both the
        __user pointer for input and pass it through phys_to_virt to come up
        with a kernel pointer to copy the data to. This looks like a trivially
        exploitable root hole.
      
      Due to these reasons we make sure this ioctl now returns -EINVAL and backport
      this patch as far as possible.
      
      Fixes: 5f15fbb6 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture driver")
      Signed-off-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
      Cc: <stable@vger.kernel.org>      # for v3.7 and up
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      da05d52d
    • S
      media: venus: don't abuse dma_alloc for non-DMA allocations · 377a22d3
      Stanimir Varbanov 提交于
      In venus_boot(), we pass a pointer to a phys_addr_t
      into dmam_alloc_coherent, which the compiler warns about:
      
      platform/qcom/venus/firmware.c: In function 'venus_boot':
      platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
      
      To avoid the error refactor venus_boot function by discard
      dma_alloc_coherent invocation because we don't want to map the
      memory for the device.  Something more, the usage of
      DMA mapping API is actually wrong and the current
      implementation relies on several bugs in DMA mapping code.
      When these bugs are fixed that will break firmware loading,
      so fix this now to avoid future troubles.
      
      The meaning of venus_boot is to copy the content of the
      firmware buffer into reserved (and memblock removed)
      block of memory and pass that physical address to the
      trusted zone for authentication and mapping through iommu
      form the secure world. After iommu mapping is done the iova
      is passed as ane entry point to the remote processor.
      
      After this change memory-region property is parsed manually
      and the physical address is memremap to CPU, call mdt_load to
      load firmware segments into proper places and unmap
      reserved memory.
      
      Fixes: af2c3834 ("[media] media: venus: adding core part and helper functions")
      Signed-off-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      377a22d3
    • R
      media: venus: hfi: fix error handling in hfi_sys_init_done() · 3e7caae5
      Rob Clark 提交于
      Not entirely sure what triggers it, but with venus build as kernel
      module and in initrd, we hit this crash:
      
        Unable to handle kernel paging request at virtual address ffff80003c039000
        pgd = ffff00000a14f000
        [ffff80003c039000] *pgd=00000000bd9f7003, *pud=00000000bd9f6003, *pmd=00000000bd9f0003, *pte=0000000000000000
        Internal error: Oops: 96000007 [#1] SMP
        Modules linked in: qcom_wcnss_pil(E+) crc32_ce(E) qcom_common(E) venus_core(E+) remoteproc(E) snd_soc_msm8916_digital(E) virtio_ring(E) cdc_ether(E) snd_soc_lpass_apq8016(E) snd_soc_lpass_cpu(E) snd_soc_apq8016_sbc(E) snd_soc_lpass_platform(E) v4l2_mem2mem(E) virtio(E) snd_soc_core(E) ac97_bus(E) snd_pcm_dmaengine(E) snd_seq(E) leds_gpio(E) videobuf2_v4l2(E) videobuf2_core(E) snd_seq_device(E) snd_pcm(E) videodev(E) media(E) nvmem_qfprom(E) msm(E) snd_timer(E) snd(E) soundcore(E) spi_qup(E) mdt_loader(E) qcom_tsens(E) qcom_spmi_temp_alarm(E) nvmem_core(E) msm_rng(E) uas(E) usb_storage(E) dm9601(E) usbnet(E) mii(E) mmc_block(E) adv7511(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) qcom_spmi_vadc(E) qcom_vadc_common(PE) industrialio(E) pinctrl_spmi_mpp(E)
         pinctrl_spmi_gpio(E) rtc_pm8xxx(E) clk_smd_rpm(E) sdhci_msm(E) sdhci_pltfm(E) qcom_smd_regulator(E) drm(E) smd_rpm(E) qcom_spmi_pmic(E) regmap_spmi(E) ci_hdrc_msm(E) ci_hdrc(E) usb3503(E) extcon_usb_gpio(E) phy_msm_usb(E) udc_core(E) qcom_hwspinlock(E) extcon_core(E) ehci_msm(E) i2c_qup(E) sdhci(E) mmc_core(E) spmi_pmic_arb(E) spmi(E) qcom_smd(E) smsm(E) rpmsg_core(E) smp2p(E) smem(E) hwspinlock_core(E) gpio_keys(E)
        CPU: 2 PID: 551 Comm: irq/150-venus Tainted: P            E   4.12.0+ #1625
        Hardware name: qualcomm dragonboard410c/dragonboard410c, BIOS 2017.07-rc2-00144-ga97bdbdf72-dirty 07/08/2017
        task: ffff800037338000 task.stack: ffff800038e00000
        PC is at hfi_sys_init_done+0x64/0x140 [venus_core]
        LR is at hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
        pc : [<ffff00000118b384>] lr : [<ffff00000118c11c>] pstate: 20400145
        sp : ffff800038e03c60
        x29: ffff800038e03c60 x28: 0000000000000000
        x27: 00000000000df018 x26: ffff00000118f4d0
        x25: 0000000000020003 x24: ffff80003a8d3010
        x23: ffff00000118f760 x22: ffff800037b40028
        x21: ffff8000382981f0 x20: ffff800037b40028
        x19: ffff80003c039000 x18: 0000000000000020
        x17: 0000000000000000 x16: ffff800037338000
        x15: ffffffffffffffff x14: 0000001000000014
        x13: 0000000100001007 x12: 0000000100000020
        x11: 0000100e00000000 x10: 0000000000000001
        x9 : 0000000200000000 x8 : 0000001400000001
        x7 : 0000000000001010 x6 : 0000000000000148
        x5 : 0000000000001009 x4 : ffff80003c039000
        x3 : 00000000cd770abb x2 : 0000000000000042
        x1 : 0000000000000788 x0 : 0000000000000002
        Process irq/150-venus (pid: 551, stack limit = 0xffff800038e00000)
        Call trace:
        [<ffff00000118b384>] hfi_sys_init_done+0x64/0x140 [venus_core]
        [<ffff00000118c11c>] hfi_process_msg_packet+0xcc/0x1e8 [venus_core]
        [<ffff00000118a2b4>] venus_isr_thread+0x1b4/0x208 [venus_core]
        [<ffff00000118e750>] hfi_isr_thread+0x28/0x38 [venus_core]
        [<ffff000008161550>] irq_thread_fn+0x30/0x70
        [<ffff0000081617fc>] irq_thread+0x14c/0x1c8
        [<ffff000008105e68>] kthread+0x138/0x140
        [<ffff000008083590>] ret_from_fork+0x10/0x40
        Code: 52820125 52820207 7a431820 54000249 (b9400263)
        ---[ end trace c963460f20a984b6 ]---
      
      The problem is that in the error case, we've incremented the data ptr
      but not decremented rem_bytes, and keep reading (presumably garbage)
      until eventually we go beyond the end of the buffer.
      
      Instead, on first error, we should probably just bail out.  Other
      option is to increment read_bytes by sizeof(u32) before the switch,
      rather than only accounting for the ptype header in the non-error
      case.  Note that in this case it is HFI_ERR_SYS_INVALID_PARAMETER,
      ie. an unrecognized/unsupported parameter, so interpreting the next
      word as a property type would be bogus.  The other error cases are
      due to truncated buffer, so there isn't likely to be anything valid
      to interpret in the remainder of the buffer.  So just bailing seems
      like a reasonable solution.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      3e7caae5
    • A
      media: venus: fix compile-test build on non-qcom ARM platform · b8f9bdc1
      Arnd Bergmann 提交于
      If QCOM_MDT_LOADER is enabled, but ARCH_QCOM is not, we run into
      a build error:
      
      ERROR: "qcom_mdt_load" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
      ERROR: "qcom_mdt_get_size" [drivers/media/platform/qcom/venus/venus-core.ko] undefined!
      
      This changes the 'select' statement again, so we only try to enable
      those symbols when the drivers will actually get built, and explicitly
      test for QCOM_MDT_LOADER to be enabled before calling into it.
      
      Fixes: 76724b30 ("[media] media: venus: enable building with COMPILE_TEST")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      b8f9bdc1
    • A
      media: venus: mark PM functions as __maybe_unused · eb918f91
      Arnd Bergmann 提交于
      Without PM support, gcc warns about two unused functions:
      
      platform/qcom/venus/core.c:146:13: error: 'venus_clks_disable' defined but not used [-Werror=unused-function]
      platform/qcom/venus/core.c:126:12: error: 'venus_clks_enable' defined but not used [-Werror=unused-function]
      
      The problem as usual are incorrect #ifdefs, so the easiest fix
      is to do away with the #ifdef completely and mark the suspend/resume
      handlers as __maybe_unused, which they are.
      
      Fixes: af2c3834 ("[media] media: venus: adding core part and helper functions")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NStanimir Varbanov <stanimir.varbanov@linaro.org>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      eb918f91
    • H
      media: cec-notifier: small improvements · fc1ff45a
      Hans Verkuil 提交于
      Allow calling cec_notifier_set_phys_addr and
      cec_notifier_set_phys_addr_from_edid with a NULL notifier, in which
      case these functions do nothing.
      
      Add a cec_notifier_phys_addr_invalidate helper function (the notifier
      equivalent of cec_phys_addr_invalidate).
      
      These changes simplify drm CEC driver support.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      fc1ff45a
    • H
      media: pulse8-cec: persistent_config should be off by default · 9b7c0c47
      Hans Verkuil 提交于
      The persistent_config option is used to make the CEC settings persistent by using
      the eeprom inside the device to store this information. This was on by default, which
      caused confusion since this device now behaves differently from other CEC devices
      which all come up unconfigured.
      
      Another reason for doing this now is that I hope a more standard way of selecting
      persistent configuration will be created in the future. And for that to work all
      CEC drivers should behave the same and come up unconfigured by default.
      
      None of the open source CEC applications are using this CEC framework at the moment
      so change this behavior before it is too late.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: <stable@vger.kernel.org>      # for v4.10 and up
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      9b7c0c47
    • H
      media: cec: cec_transmit_attempt_done: ignore CEC_TX_STATUS_MAX_RETRIES · bd34ca87
      Hans Verkuil 提交于
      The switch in cec_transmit_attempt_done() should ignore the
      CEC_TX_STATUS_MAX_RETRIES status bit.
      
      Calling this function with e.g. CEC_TX_STATUS_NACK | CEC_TX_STATUS_MAX_RETRIES
      is perfectly legal and should not trigger the WARN(1).
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      bd34ca87
    • S
      media: lirc: LIRC_GET_REC_RESOLUTION should return microseconds · 9f5039ba
      Sean Young 提交于
      Since commit e8f48188 ("[media] lirc: advertise
      LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
      LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
      the hardware can detect. This breaks decoding in lirc because lircd
      expects the answer in microseconds, but nanoseconds is returned.
      
      Cc: <stable@vger.kernel.org> # v2.6.36+
      Reported-by: NDerek <user.vdr@gmail.com>
      Tested-by: NDerek <user.vdr@gmail.com>
      Signed-off-by: NSean Young <sean@mess.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      9f5039ba
    • J
      media: vimc: set id_table for platform drivers · bf183e0f
      Javier Martinez Canillas 提交于
      The vimc platform drivers define a platform device ID table but these
      are not set to the .id_table field in the platform driver structure.
      
      So the platform device ID table is only used to fill the aliases in
      the module but are not used for matching (works because the platform
      subsystem fallbacks to the driver's name if no .id_table is set).
      
      But this also means that the platform device ID table isn't used if
      the driver is built-in, which leads to the following build warning:
      
      This causes the following build warnings when the driver is built-in:
      
      drivers/media/platform/vimc//vimc-capture.c:528:40: warning: ‘vimc_cap_driver_ids’ defined but not used [-Wunused-const-variable=]
       static const struct platform_device_id vimc_cap_driver_ids[] = {
                                              ^~~~~~~~~~~~~~~~~~~
      drivers/media/platform/vimc//vimc-debayer.c:588:40: warning: ‘vimc_deb_driver_ids’ defined but not used [-Wunused-const-variable=]
       static const struct platform_device_id vimc_deb_driver_ids[] = {
                                              ^~~~~~~~~~~~~~~~~~~
      drivers/media/platform/vimc//vimc-scaler.c:442:40: warning: ‘vimc_sca_driver_ids’ defined but not used [-Wunused-const-variable=]
       static const struct platform_device_id vimc_sca_driver_ids[] = {
                                              ^~~~~~~~~~~~~~~~~~~
      drivers/media/platform/vimc//vimc-sensor.c:376:40: warning: ‘vimc_sen_driver_ids’ defined but not used [-Wunused-const-variable=]
       static const struct platform_device_id vimc_sen_driver_ids[] = {
                                              ^~~~~~~~~~~~~~~~~~~
      Reported-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      Suggested-by: NSakari Ailus <sakari.ailus@iki.fi>
      Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
      Reviewed-by: NHelen Koike <helen.koike@collabora.com>
      Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      bf183e0f
  2. 17 7月, 2017 1 次提交
    • M
      media: davinci: variable 'common' set but not used · 9a01968c
      Mauro Carvalho Chehab 提交于
      Get rid of those two warnings:
      drivers/media/platform/davinci/vpif_capture.c: In function 'vpif_remove':
      drivers/media/platform/davinci/vpif_capture.c:1722:21: warning: variable 'common' set but not used [-Wunused-but-set-variable]
        struct common_obj *common;
                           ^~~~~~
      drivers/media/platform/davinci/vpif_display.c: In function 'vpif_remove':
      drivers/media/platform/davinci/vpif_display.c:1342:21: warning: variable 'common' set but not used [-Wunused-but-set-variable]
        struct common_obj *common;
                           ^~~~~~
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      9a01968c
  3. 26 6月, 2017 4 次提交
  4. 25 6月, 2017 24 次提交