linux-kernel - Re: [PATCH v5 00/39] i.MX Media Driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06038465-5634-3f69-521d-3f2a7d14afde@mentor.com>
Date:   Tue, 14 Mar 2017 10:02:26 -0700
From:   Steve Longerbeam <steve_longerbeam@...tor.com>
To:     Mauro Carvalho Chehab <mchehab@...pensource.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>
CC:     Steve Longerbeam <slongerbeam@...il.com>, <robh+dt@...nel.org>,
        <mark.rutland@....com>, <shawnguo@...nel.org>,
        <kernel@...gutronix.de>, <fabio.estevam@....com>,
        <mchehab@...nel.org>, <hverkuil@...all.nl>, <nick@...anahar.org>,
        <markus.heiser@...marIT.de>, <p.zabel@...gutronix.de>,
        <laurent.pinchart+renesas@...asonboard.com>, <bparrot@...com>,
        <geert@...ux-m68k.org>, <arnd@...db.de>,
        <sudipm.mukherjee@...il.com>, <minghsiu.tsai@...iatek.com>,
        <tiffany.lin@...iatek.com>, <jean-christophe.trotin@...com>,
        <horms+renesas@...ge.net.au>,
        <niklas.soderlund+renesas@...natech.se>, <robert.jarzmik@...e.fr>,
        <songjun.wu@...rochip.com>, <andrew-ct.chen@...iatek.com>,
        <gregkh@...uxfoundation.org>, <shuah@...nel.org>,
        <sakari.ailus@...ux.intel.com>, <pavel@....cz>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-media@...r.kernel.org>, <devel@...verdev.osuosl.org>
Subject: Re: [PATCH v5 00/39] i.MX Media Driver



On 03/12/2017 03:10 PM, Mauro Carvalho Chehab wrote:
> Em Sun, 12 Mar 2017 21:13:24 +0000
> Russell King - ARM Linux <linux@...linux.org.uk> escreveu:
>
>> On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote:
>>> Yet, udev/systemd has some rules that provide an unique name for V4L
>>> devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
>>> runs a small application (v4l_id) with creates a persistent symling
>>> using rules like this:
>>>
>>> 	KERNEL=="video*", ENV{ID_SERIAL}=="?*", SYMLINK+="v4l/by-id/$env{ID_BUS}-$env{ID_SERIAL}-video-index$attr{index}"
>>>
>>> Those names are stored at /dev/v4l/by-path.
>> This doesn't help:
>>
>> $ ls -Al /dev/v4l/by-id/
>> total 0
>> lrwxrwxrwx 1 root root 13 Mar 12 19:54 usb-Sonix_Technology_Co.__Ltd._USB_2.0_Camera-video-index0 -> ../../video10
>> $ ls -Al /dev/v4l/by-path/
>> total 0
>> lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-2040000.vpu-video-index0 -> ../../video0
>> lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-2040000.vpu-video-index1 -> ../../video1
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index0 -> ../../video2
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index1 -> ../../video3
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index2 -> ../../video4
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index3 -> ../../video5
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index4 -> ../../video6
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index5 -> ../../video7
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index6 -> ../../video8
>> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index7 -> ../../video9
>> lrwxrwxrwx 1 root root 13 Mar 12 19:54 platform-ci_hdrc.0-usb-0:1:1.0-video-index0 -> ../../video10
>>
>> The problem is the "platform-capture-subsystem-video-index" entries.
>> These themselves change order.  For instance, I now have:
>>
>> - entity 72: ipu1_csi0 capture (1 pad, 1 link)
>>               type Node subtype V4L flags 0
>>               device node name /dev/video6
>>
>> which means it's platform-capture-subsystem-video-index4.  Before, it
>> was platform-capture-subsystem-video-index2.
> That's a driver problem. v4l_id gets information to build the persistent
> name from the result of VIDIOC_QUERYCAP.
>
> In the case of Exynos gsc driver, for example, the information is here:
>
> static int gsc_m2m_querycap(struct file *file, void *fh,
> 			   struct v4l2_capability *cap)
> {
> 	struct gsc_ctx *ctx = fh_to_ctx(fh);
> 	struct gsc_dev *gsc = ctx->gsc_dev;
>
> 	strlcpy(cap->driver, GSC_MODULE_NAME, sizeof(cap->driver));
> 	strlcpy(cap->card, GSC_MODULE_NAME " gscaler", sizeof(cap->card));
> 	snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> 		 dev_name(&gsc->pdev->dev));
> 	cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M_MPLANE |
> 		V4L2_CAP_VIDEO_CAPTURE_MPLANE |	V4L2_CAP_VIDEO_OUTPUT_MPLANE;
>
> 	cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
> 	return 0;
> }
>
> See that the bus_info there is filled with:
>
> 	snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", dev_name(&gsc->pdev->dev));
>
>  From the output you printed, it seems that the i.MX6 is just doing:
> 	snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:");
> for some devices.

imx6 is setting bus_info string on all capture devices as:

snprintf(cap->bus_info, sizeof(cap->bus_info),
                  "platform:%s", dev_name(priv->dev));

dev_name(priv->dev) is the device name of the attached subdev.
So the bus_info string, at least for attached CSI subdevs, should
be "platform:imx-ipuv3-csi".

Maybe there is something else missing, I haven't had a chance to
look at this yet.

Steve


>
> If you change the i.MX6 driver to do the same, you'll likely be able to
> have unique names there too.
>
> Regards,
> Mauro