- 21 Apr, 2020 39 commits
-
-
Boris Brezillon authored
Building those list is a standard procedure described in section '8.2.4 Decoding process for reference picture lists construction' of the H264 specification. We already have 2 drivers needing the same logic (hantro and rkvdec) and I suspect we will soon have more. Let's provide generic helpers to create those lists. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ezequiel Garcia authored
Instead of depending on the Rockchip PHY driver the ISP driver should really depend on CONFIG_GENERIC_PHY_MIPI_DPHY, given all it needs is the phy_mipi_dphy_get_default_config() symbol. Fix it. Signed-off-by:
Helen Koike <helen.koike@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
The driver is perfectly capable of being built without CONFIG_OF. Remove this dependency, which is useful for compile-only tests. Signed-off-by:
-
Ezequiel Garcia authored
If CONFIG_OF is not selected, the compiler will complain: drivers/staging/media/rkisp1/rkisp1-dev.c: In function ‘rkisp1_probe’: drivers/staging/media/rkisp1/rkisp1-dev.c:457:22: warning: unused variable ‘node’ [-Wunused-variable] 457 | struct device_node *node = pdev->dev.of_node; Rework the code slightly and make the compiler happy. Suggested-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Seungchul Kim authored
v4l2_fh struct define differently by CONFIG_V4L2_MEM2MEM_DEV. If some vendors use CONFIG_V4L2_MEM2MEM_DEV by module, it can make the mismatch of v4l2_fh sturct. By the mismatch, the following error occurs. =============================== [ 7.533506] v4l2_mem2mem: disagrees about version of symbol video_devdata [ 7.533594] v4l2_mem2mem: Unknown symbol video_devdata (err -22) [ 7.535319] v4l2_mem2mem: disagrees about version of symbol v4l2_event_pending [ 7.542532] v4l2_mem2mem: Unknown symbol v4l2_event_pending (err -22) =============================== So v4l2_fh struct is modified to does not have dependency for CONFIG_V4L2_MEM2MEM_DEV. Signed-off-by:
Seungchul Kim <sc377.kim@samsung.com> Signed-off-by:
-
Dafna Hirschfeld authored
The fields 'fmt_type' in the structs 'rkisp1_rsz_config', 'rkisp1_isp_mbus_info' are of type 'v4l2_pixel_encoding' so it is nicer to change their name to 'pixel_enc'. Also change the define 'RKISP1_DEF_FMT_TYPE' to 'RKISP1_DEF_PIXEL_ENC' Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Dafna Hirschfeld authored
The pixel encoding can be retrieved from the cap->pix.info. Therefore the field fmt_type can be removed from the struct rkisp1_capture_fmt_cfg. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Dafna Hirschfeld authored
The enum rkisp1_fmt_pix_type that holds the pixel format which is one of RGB, YUV, BAYER, can be replace by the v4l2 enum v4l2_pixel_encoding. Signed-off-by:
-
Kieran Bingham authored
Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will enable extra validation on DMA operations ensuring that the size restraints are met. When using the FCP in conjunction with the VSP1/DU, and display frames, the size of the DMA operations is larger than the default maximum segment size reported by the DMA core (64K). With the DMA debug enabled, this produces a warning such as the following: "DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device claims to support [len=3145728] [max=65536]" We have no specific limitation on the segment size which isn't already handled by the VSP1/DU which actually handles the DMA allcoations and buffer management, so define a maximum segment size of up to 4GB (a 32 bit mask). Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Fixes: 7b49235e ("[media] v4l: Add Renesas R-Car FCP driver") Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
-
Dafna Hirschfeld authored
remove the TODO item: * Make sure uapi structs have the same size and layout in 32 and 62 bits, and that there are no holes in the structures (pahole is a utility that can be used to test this). It was tested with pahole and found compatible. Signed-off-by:
-
Dan Carpenter authored
If these functions fail then we return success, but we should instead preserve negative error code and return that. Fixes: fde649b4 ("media: vicodec: Register another node for stateless decoder") Fixes: c022a4a9 ("media: vicodec: add struct for encoder/decoder instance") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Fabio Estevam authored
Improve the documentation by providing examples on how to test camera capture on imx6q-sabresd via v4l2-ctl and Gstreamer. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by: Steve Longerbeam<slongerbeam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
In order to improve the documentation, provide the OV5640 MIPI module part number that is used on the imx6q-sabresd board. Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Signed-off-by:
-
Fabio Estevam authored
The current example for imx6q-sabresd is for a direct conversion pipeline. Provide an extra example using unprocessed video capture for completeness. Signed-off-by:
-
Fabio Estevam authored
The current instructions for imx6q-sabresd do not lead to functional capture on OV5640 MIPI CSI-2. The reason for this, as explained by Steve Longerbeam, is that OV5640 by default transmits on virtual channel 0, not channel 1 as is given in the instructions. Adapt the instructions to use virtual channel 0 so that a working camera setup can be achieved on imx6q-sabresd. Also, since we are using an IC direct conversion pipeline, improve the example by demonstrating colorspace and scaling. Signed-off-by:
-
Maheshwar Ajja authored
Add H264 profile "Contrained High" and H264 levels "5.2", "6.0", "6.1" and "6.2". Signed-off-by:
Maheshwar Ajja <majja@codeaurora.org> Signed-off-by:
-
Maheshwar Ajja authored
Add H264 profile "Contrained High" and H264 levels "5.2", "6.0", "6.1" and "6.2". Signed-off-by:
-
Fabio Estevam authored
Currently v4l2-compliance tool returns the following output: Compliance test for imx-media-csc-s device /dev/video8: Driver Info: Driver name : imx-media-csc-s Card type : imx-media-csc-scaler Bus info : platform:imx-media-csc-scaler The driver name string is limited to 16 characters, so provide a shorter name in order to get a better output. While at it, use the same shorter name for driver, card and platform. Signed-off-by: -
Colin Ian King authored
The variable status is being assigned a value that is never read. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Colin Ian King authored
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Hsin-Yi Wang authored
aliases property name must include only lowercase and '-'. Fix in dts and driver. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Colin Ian King authored
The pointer 'common' is being assigned with a value that is never read, the assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Laurent Pinchart authored
The imx_media_mbus_fmt_to_pix_fmt() and imx_media_mbus_fmt_to_ipu_image() functions do not need to modify their mbus argument, and imx_media_ipu_image_to_mbus_fmt() does not need to modify its ipu_image argument. Make them const. [slongerbeam@gmail.com: Constified mbus arg to imx_media_mbus_fmt_to_ipu_image(), and ipu_image arg to imx_media_ipu_image_to_mbus_fmt(), as well] Signed-off-by:
-
Laurent Pinchart authored
Rename the format lookup and enumeration functions according to their usage: - Rename imx_media_(find|enum)_format() to *_pixel_format() to explicitly state on what formats the functions operate. This aligns the naming scheme with the media bus and IPU format functions that already end with *_mbus_format() and *_ipu_formats(). - Rename all enumeration functions to pluralize 'formats' at the end, as they enumerate multiple formats. Signed-off-by:
-
Steve Longerbeam authored
To make the code easier to follow, split up find_format() into separate search functions for pixel formats and media-bus codes, and inline find_format() into the exported functions imx_media_find_format() and imx_media_find_mbus_format(). Do the equivalent for enum_format(). Also add comment blocks for the exported find|enum functions. The convenience functions imx_media_find_ipu_format() and imx_media_enum_ipu_format() can now be made inline and moved to imx-media.h. Signed-off-by:
-
Laurent Pinchart authored
The imx_media_pixfmt structures include a codes member that stores media bus codes as a fixed array of 4 integers. The functions dealing with the imx_media_pixfmt structures assume that the array of codes is terminated by a 0 element. This mechanism is fragile, as demonstrated by several instances of the structure containing 4 non-zero codes. Fix this by turning the array into a pointer, and providing an IMX_BUS_FMTS macro to initialize the codes member with a guaranteed 0 element at the end. [Fixed a NULL deref of the codes pointer in a couple places] [Added more comments for the struct imx_media_pixfmt members, including a bold NOTE! for future developers that codes pointer is NULL for the in-memory-only formats] Signed-off-by:
-
Steve Longerbeam authored
Add a PIXFMT_SEL_IPU selection flag, to select only the IPU-internal pixel formats, and move the single-entry IPU-internal pixel format arrays into pixel_formats[]. imx_media_find_ipu_format() and imx_media_enum_ipu_format() can now simply call find_format() and enum_format(). The RGB32 format is both an IPU-internal format, and an in-memory format via idmac channels that is supported by the IPUv3 driver, so it appears twice in pixel_formats[], one with ipufmt=false for the in-memory format, and again with ipufmt=true for the IPU-internal format. Signed-off-by:
-
Steve Longerbeam authored
After the introduction of the CS_SEL_BAYER flag, the "codespace" pixel format selection enumeration wording no longer makes sense (and even before, when selecting between YUV or RGB formats, "codespace" was a misuse of the term). Rename - 'enum codespace_sel' to 'enum imx_pixfmt_sel' - CS_SEL_* to PIXFMT_SEL_* - local vars named cs_sel to fmt_sel or just sel No functional changes. Signed-off-by:
-
Steve Longerbeam authored
- imx_media_capture_device_register() needs to use CS_SEL_ANY when finding the format from the attached source subdevice, because the source can be a CSI which supports bayer, and the CSI may have selected a bayer format when it registered. - Likewise, imx_media_init_mbus_fmt() is called from the CSI, so the function may be passed a bayer code. Use CS_SEL_ANY when locating the format. Signed-off-by:
-
Laurent Pinchart authored
The format lookup (and enumeration) functions take a boolean flag to tell if Bayer formats should be considered. This leads to hard to read lines such as return enum_format(fourcc, NULL, index, cs_sel, true, false); where the boolean parameters can easily be mixed. To make the code clearer, add a CS_SEL_BAYER flag that can be passed through the codespace_sel parameter of the lookup functions to replace the bool parameter. [slongerbeam@gmail.com: Instead of declaring CS_SEL_ANY as a bitfield containing only CS_SEL_YUV | CS_SEL_RGB, declare CS_SEL_ANY as all of the above (YUV, RGB, BAYER). A new enum is declared for the YUV | RGB selection as CS_SEL_YUV_RGB, and that is used by sub-devices that don't support BAYER and only allow selecting and enumerating YUV or RGB encodings. CS_SEL_ANY is now only used by the CSI sub-devices and the attached capture interfaces, since only those devices support BAYER formats.] Signed-off-by:
-
Laurent Pinchart authored
The init_mbus_colorimetry() function is small and used in a single place. The code becomes easier to follow if it gets inline in its caller. Do so. Signed-off-by:
-
Philipp Zabel authored
Iterate over all media bus formats, not just over the first format in each imx_media_pixfmt entry. Before: $ v4l2-ctl -d $(media-ctl -e ipu1_csi0) --list-subdev-mbus-codes 0 ioctl: VIDIOC_SUBDEV_ENUM_MBUS_CODE (pad=0) 0x2006: MEDIA_BUS_FMT_UYVY8_2X8 0x2008: MEDIA_BUS_FMT_YUYV8_2X8 0x1008: MEDIA_BUS_FMT_RGB565_2X8_LE 0x100a: MEDIA_BUS_FMT_RGB888_1X24 0x100d: MEDIA_BUS_FMT_ARGB8888_1X32 0x3001: MEDIA_BUS_FMT_SBGGR8_1X8 0x3013: MEDIA_BUS_FMT_SGBRG8_1X8 0x3002: MEDIA_BUS_FMT_SGRBG8_1X8 0x3014: MEDIA_BUS_FMT_SRGGB8_1X8 0x3007: MEDIA_BUS_FMT_SBGGR10_1X10 0x300e: MEDIA_BUS_FMT_SGBRG10_1X10 0x300a: MEDIA_BUS_FMT_SGRBG10_1X10 0x300f: MEDIA_BUS_FMT_SRGGB10_1X10 0x2001: MEDIA_BUS_FMT_Y8_1X8 0x200a: MEDIA_BUS_FMT_Y10_1X10 After: $ v4l2-ctl -d $(media-ctl -e ipu1_csi0) --list-subdev-mbus-codes 0 ioctl: VIDIOC_SUBDEV_ENUM_MBUS_CODE (pad=0) 0x2006: MEDIA_BUS_FMT_UYVY8_2X8 0x200f: MEDIA_BUS_FMT_UYVY8_1X16 0x2008: MEDIA_BUS_FMT_YUYV8_2X8 0x2011: MEDIA_BUS_FMT_YUYV8_1X16 0x1008: MEDIA_BUS_FMT_RGB565_2X8_LE 0x100a: MEDIA_BUS_FMT_RGB888_1X24 0x100c: MEDIA_BUS_FMT_RGB888_2X12_LE 0x100d: MEDIA_BUS_FMT_ARGB8888_1X32 0x3001: MEDIA_BUS_FMT_SBGGR8_1X8 0x3013: MEDIA_BUS_FMT_SGBRG8_1X8 0x3002: MEDIA_BUS_FMT_SGRBG8_1X8 0x3014: MEDIA_BUS_FMT_SRGGB8_1X8 0x3007: MEDIA_BUS_FMT_SBGGR10_1X10 0x3008: MEDIA_BUS_FMT_SBGGR12_1X12 0x3019: MEDIA_BUS_FMT_SBGGR14_1X14 0x301d: MEDIA_BUS_FMT_SBGGR16_1X16 0x300e: MEDIA_BUS_FMT_SGBRG10_1X10 0x3010: MEDIA_BUS_FMT_SGBRG12_1X12 0x301a: MEDIA_BUS_FMT_SGBRG14_1X14 0x301e: MEDIA_BUS_FMT_SGBRG16_1X16 0x300a: MEDIA_BUS_FMT_SGRBG10_1X10 0x3011: MEDIA_BUS_FMT_SGRBG12_1X12 0x301b: MEDIA_BUS_FMT_SGRBG14_1X14 0x301f: MEDIA_BUS_FMT_SGRBG16_1X16 0x300f: MEDIA_BUS_FMT_SRGGB10_1X10 0x3012: MEDIA_BUS_FMT_SRGGB12_1X12 0x301c: MEDIA_BUS_FMT_SRGGB14_1X14 0x3020: MEDIA_BUS_FMT_SRGGB16_1X16 0x2001: MEDIA_BUS_FMT_Y8_1X8 0x200a: MEDIA_BUS_FMT_Y10_1X10 0x2013: MEDIA_BUS_FMT_Y12_1X12 [laurent.pinchart@ideasonboard.com: Decrement index to replace loop counter k] [laurent.pinchart@ideasonboard.com: Return directly from within the loops] Fixes: e1302912 ("[media] media: Add i.MX media core driver") Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Philipp Zabel authored
Merge yuv_formats and rgb_formats into a single array. Always loop over all entries, skipping those that do not match the requested search criteria. This simplifies the code, lets us get rid of the manual counting of array entries, and stops accidentally ignoring some non-mbus RGB formats. Before: $ v4l2-ctl -d /dev/video14 --list-formats-out ioctl: VIDIOC_ENUM_FMT Type: Video Output [0]: 'UYVY' (UYVY 4:2:2) [1]: 'YUYV' (YUYV 4:2:2) [2]: 'YU12' (Planar YUV 4:2:0) [3]: 'YV12' (Planar YVU 4:2:0) [4]: '422P' (Planar YUV 4:2:2) [5]: 'NV12' (Y/CbCr 4:2:0) [6]: 'NV16' (Y/CbCr 4:2:2) [7]: 'RGBP' (16-bit RGB 5-6-5) [8]: 'RGB3' (24-bit RGB 8-8-8) [9]: 'BX24' (32-bit XRGB 8-8-8-8) After: $ v4l2-ctl -d /dev/video14 --list-formats-out ioctl: VIDIOC_ENUM_FMT Type: Video Output [0]: 'UYVY' (UYVY 4:2:2) [1]: 'YUYV' (YUYV 4:2:2) [2]: 'YU12' (Planar YUV 4:2:0) [3]: 'YV12' (Planar YVU 4:2:0) [4]: '422P' (Planar YUV 4:2:2) [5]: 'NV12' (Y/CbCr 4:2:0) [6]: 'NV16' (Y/CbCr 4:2:2) [7]: 'RGBP' (16-bit RGB 5-6-5) [8]: 'RGB3' (24-bit RGB 8-8-8) [9]: 'BGR3' (24-bit BGR 8-8-8) [10]: 'BX24' (32-bit XRGB 8-8-8-8) [11]: 'XR24' (32-bit BGRX 8-8-8-8) [12]: 'RX24' (32-bit XBGR 8-8-8-8) [13]: 'XB24' (32-bit RGBX 8-8-8-8) Tested on a imx6q-sabresd. [laurent.pinchart@ideasonboard.com: Make loop counters unsigned] [laurent.pinchart@ideasonboard.com: Decrement index instead of adding a counter] [laurent.pinchart@ideasonboard.com: Return directly from within loop instead of breaking] [slongerbeam@gmail.com: Fix colorspace comparison error] Fixes: e1302912 ("[media] media: Add i.MX media core driver") Signed-off-by:
-
Guru Das Srinagesh authored
Since the PWM framework is switching struct pwm_state.period's datatype to u64, prepare for this transition by using DIV_ROUND_CLOSEST_ULL to handle a 64-bit dividend. Cc: Richard Fontana <rfontana@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Allison Randal <allison@lohutok.net> Signed-off-by:
Guru Das Srinagesh <gurus@codeaurora.org> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Christophe JAILLET authored
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'. While at it, change the log level from 'err' to 'debug'. Fixes: e6089fec ("media: m88ds3103: Add support for ds3103b demod") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Sean Young authored
This makes it possible to declare dvb_usb_device_properties const. Signed-off-by:
-
Colin Ian King authored
Currently when i2c transfers fail the error return -EREMOTEIO is assigned to err but then later overwritten when the tuner attach call is made. Fix this by returning early with the error return code -EREMOTEIO on i2c transfer failure errors. If the transfer fails, an uninitialized value will be read from b2. Addresses-Coverity: ("Unused value") Fixes: fbfee868 ("V4L/DVB (5651): Dibusb-mb: convert pll handling to properly use dvb-pll") Signed-off-by: -
Sean Young authored
If the kernel is built without e.g. the imon IR decoder, the protocols sysfs file still show the protocol as available. If user-space tries to enable this decoder, the kernel will report an error: $ echo +imon > /sys/class/rc/rc0/protocols [ 57.693033] rc_core: Loaded IR protocol module ir-imon-decoder, but protocol imon still not available Ensuring that unavailable protocols are not advertised, ensures that users space knows it is not available, and a BPF based IR decoder can be loaded instead. This supports the case when no kernel-based codec needs to be compiled in, and every IR decoder can be BPF based. Signed-off-by:
-
Sean Young authored
The first element of the key array is not used. Remove it, and along with it a uninitialized memory read. This should fix the rc debug message. Link: https://www.spinics.net/lists/kernel/msg3374861.htmlSuggested-by:
Phong Tran <tranmanphong@gmail.com> Signed-off-by:
-
- 20 Apr, 2020 1 commit
-
-
Mauro Carvalho Chehab authored
When built with: CONFIG_USB=m CONFIG_VIDEO_USBVISION=y It causes ld errors: ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_write_reg_irq': usbvision-core.c:(.text+0x8a4): undefined reference to `usb_submit_urb' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_isoc_irq': usbvision-core.c:(.text+0x2ee8): undefined reference to `usb_submit_urb' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_read_reg': usbvision-core.c:(.text+0x30ad): undefined reference to `usb_control_msg' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_write_reg': usbvision-core.c:(.text+0x3178): undefined reference to `usb_control_msg' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_set_output': usbvision-core.c:(.text+0x344e): undefined reference to `usb_control_msg' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_set_input': usbvision-core.c:(.text+0x3b9b): undefined reference to `usb_control_msg' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_setup': usbvision-core.c:(.text+0x4009): undefined reference to `usb_control_msg' ld: drivers/staging/media/usbvision/usbvision-core.o:usbvision-core.c:(.text+0x417f): more undefined references to `usb_control_msg' follow ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_set_alternate': usbvision-core.c:(.text+0x4518): undefined reference to `usb_set_interface' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_init_isoc': usbvision-core.c:(.text+0x4673): undefined reference to `usb_alloc_urb' ld: usbvision-core.c:(.text+0x46a5): undefined reference to `usb_alloc_coherent' ld: usbvision-core.c:(.text+0x4765): undefined reference to `usb_submit_urb' ld: drivers/staging/media/usbvision/usbvision-core.o: in function `usbvision_stop_isoc': usbvision-core.c:(.text+0x4837): undefined reference to `usb_kill_urb' ld: usbvision-core.c:(.text+0x485f): undefined reference to `usb_free_coherent' ld: usbvision-core.c:(.text+0x4874): undefined reference to `usb_free_urb' ld: usbvision-core.c:(.text+0x48f1): undefined reference to `usb_set_interface' ld: drivers/staging/media/usbvision/usbvision-video.o: in function `usbvision_release': usbvision-video.c:(.text+0x1a8a): undefined reference to `usb_free_urb' ld: drivers/staging/media/usbvision/usbvision-video.o: in function `usbvision_disconnect': usbvision-video.c:(.text+0x1b74): undefined reference to `usb_put_dev' ld: drivers/staging/media/usbvision/usbvision-video.o: in function `usbvision_radio_close': usbvision-video.c:(.text+0x1c89): undefined reference to `usb_set_interface' ld: drivers/staging/media/usbvision/usbvision-video.o: in function `usbvision_probe': usbvision-video.c:(.text+0x1e4b): undefined reference to `usb_get_dev' ld: usbvision-video.c:(.text+0x20e1): undefined reference to `usb_alloc_urb' ld: usbvision-video.c:(.text+0x2797): undefined reference to `usb_put_dev' ld: drivers/staging/media/usbvision/usbvision-video.o: in function `usbvision_exit': usbvision-video.c:(.exit.text+0x37): undefined reference to `usb_deregister' ld: drivers/staging/media/usbvision/usbvision-video.o: in function `usbvision_init': usbvision-video.c:(.init.text+0xf9): undefined reference to `usb_register_driver' ld: drivers/staging/media/usbvision/usbvision-i2c.o: in function `usbvision_i2c_write': usbvision-i2c.c:(.text+0x2f4): undefined reference to `usb_control_msg' Reported-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
