Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <29ab2e43-4374-a3ea-6ae1-a4267867eaa4@jpvw.nl> <20191002154922.7f1cfc76@coco.lan>
 <CANL0fFRJZBfEDWK_c2w1TomvB5-i4g09LopyJUbO5NtOwKdDTg@mail.gmail.com>
 <20191003080539.2b13c03b@coco.lan> <CANL0fFSmvEEJhnA=qjTuEPr4N8q8eWLeYC5du+OoTMxe1Gnh5Q@mail.gmail.com>
 <20191003120238.75811da6@coco.lan> <20191003160336.GA5125@Limone>
 <20191003130909.01d29b77@coco.lan> <20191003162326.GA2727@Limone>
 <20191003144225.0137bf6c@coco.lan> <20191003183200.GA2631@Limone>
 <e468b867-1b45-8220-a5d2-ac40fdb4e0e6@jpvw.nl> <CANL0fFQms9oyec_1UevbJ7aLp+KNJ3h6UhGEbqrnCNO286rbGg@mail.gmail.com>
 <20191003163914.7c384d36@coco.lan> <20191003164426.6da8538f@coco.lan>
In-Reply-To: <20191003164426.6da8538f@coco.lan>
From:   Gonsolo <gonsolo@gmail.com>
Date:   Thu, 3 Oct 2019 21:51:35 +0200
Message-ID: <CANL0fFRSNbUhcik7rnhjZ0qUe-tZyzcjY+M1J_iGzUa5jNc9_A@mail.gmail.com>
Subject: Re: [PATCH] si2157: Add support for Logilink VG0022A.
To:     Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc:     JP <jp@jpvw.nl>, crope@iki.fi, Sean Young <sean@mess.org>,
        linux-media@vger.kernel.org,
        Linux Kernel <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> 1) The firmware file is likely at the Windows driver for this device
> (probably using a different format). It should be possible to get
> it from there.

If you tell me how I'm willing to do this. :)

> 2) Another possibility would be to add a way to tell the si2168 driver
> to not try to load a firmware, using the original one. That would
> require adding a field at si2168_config to allow signalizing to it
> that it should not try to load a firmware file, and add a quirk at
> the af9035 that would set such flag for Logilink VG0022A.

I don't get this. Which firmware, si2168 or si2157?

I'm still for option 3: If there is a bogus chip revision number it's
likely the VG0022A and we can safely set fw to NULL, in which case
everything works.
All already working devices will continue to work as before.
With a low probability there are other devices that will return 0xffff
but a) they didn't work until now and b) they receive a clear message
that they return bogus numbers and this works just for the VG0022A, in
which case this hardware can be tested.
At last, *my* VG0022A will work without a custom kernel which I'm a
big fan of. :))

Are there any counterarguments except that it is not the cleanest
solution in the universe? ;)

-- 
g