linux-kernel - Re: [PATCH] si2157: Add support for Logilink VG0022A.

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: <20191003080539.2b13c03b@coco.lan>
Date:   Thu, 3 Oct 2019 08:05:39 -0300
From:   Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
To:     Gonsolo <gonsolo@...il.com>
Cc:     JP <jp@...w.nl>, crope@....fi, Sean Young <sean@...s.org>,
        linux-media@...r.kernel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] si2157: Add support for Logilink VG0022A.

Em Thu, 3 Oct 2019 12:13:33 +0200
Gonsolo <gonsolo@...il.com> escreveu:

> Hi!
> 
> > Could you please test the enclosing patch and see if, with that, you
> > can remove the hacks you added for the tuner probe to work?  
> 
> I tested again on a vanilla media_tree with Mauro's patch attached.
> Doesn't work. Dmesg output:
> 
> [    0.788387] kernel: usb 1-1: new high-speed USB device number 2
> using ehci-pci
> [    0.792384] kernel: usb 2-1: new high-speed USB device number 2
> using xhci_hcd
> [    0.944937] kernel: usb 2-1: New USB device found, idVendor=1d19,
> idProduct=0100, bcdDevice= 1.00
> [    0.944939] kernel: usb 2-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> [    0.944940] kernel: usb 2-1: Product: TS Aggregator
> [    0.944941] kernel: usb 2-1: Manufacturer: ITE Tech., Inc.
> [    0.944942] kernel: usb 2-1: SerialNumber: AF0102020700001
> 
> I then also used the following (additional) patch:
> 
> @@ -2119,6 +2122,8 @@ static const struct usb_device_id af9035_id_table[] = {
>         /* IT930x devices */
>         { DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9303,
>                 &it930x_props, "ITE 9303 Generic", NULL) },
> +       { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x0100,
> +               &it930x_props, "Logilink VG0022A", NULL) },
>         { DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_TD310,
>                 &it930x_props, "AVerMedia TD310 DVB-T2", NULL) },
>         { }
> 
> Which gives the following output:
> 
> [    5.380989] si2168 1-0067: Silicon Labs Si2168-B40 successfully identified
> [    5.380991] si2168 1-0067: firmware version: B 4.0.2
> [    5.381013] usb 2-1: DVB: registering adapter 0 frontend 0 (Silicon
> Labs Si2168)...
> [    5.381018] dvbdev: dvb_create_media_entity: media entity 'Silicon
> Labs Si2168' registered.
> [    5.390058] checking generic (e0000000 410000) vs hw (e0000000 10000000)
> [    5.390062] fb0: switching to inteldrmfb from EFI VGA
> [    5.390268] Console: switching to colour dummy device 80x25
> [    5.390281] i915 0000:00:02.0: vgaarb: deactivate vga console
> [    5.393438] si2157 2-0063: Silicon Labs Si2147/2148/2157/2158
> successfully attached

Ok. It sounds that the issues you're facing are indeed related to timing
conditions.

> 
> But when I try to use VLC I get the following:
> 
> [  457.677363] si2168 1-0067: downloading firmware from file
> 'dvb-demod-si2168-b40-01.fw'
> [  458.631034] si2168 1-0067: firmware version: B 4.0.11
> [  458.650309] si2157 2-0063: unknown chip version Si21255-\xff\xff\xff
> 
> Now I'm trying other timings.

Returning 0xff, 0xff, 0xff, ... usually means that the tuner chip didn't
respond in time.

This could indicate:

1) The device requires more time to go to sane state after firmware
   load and/or device reset/power up;

2) Tuner may be using I2C clock stretching, but the bridge doesn't
   support it.

3) The clock used at the I2C bus is still too high;

4) The tuner is hidden by an I2C gate. 


I think that using the standard I2C bus clock of 100kbps should be
enough.

I2C clock stretching seems to be unlikely for a command that it is
just getting the device's version.

What seems more likely is that this device may need some time after
firmware load to start working.

So, I would add a msleep() somewhere after the firmware update.

Thanks,
Mauro