> diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
> index 2b3d514..d1f539c 100644
> --- a/drivers/media/tuners/xc5000.c
> +++ b/drivers/media/tuners/xc5000.c
> @@ -85,6 +85,7 @@ struct xc5000_priv {
> /* Product id */
> #define XC_PRODUCT_ID_FW_NOT_LOADED 0x2000
> #define XC_PRODUCT_ID_FW_LOADED 0x1388
> +#define XC_PRODUCT_ID_FW_LOADED_5000C 0x14b4
>
> /* Registers */
> #define XREG_INIT 0x00
> @@ -1344,6 +1345,7 @@ struct dvb_frontend *xc5000_attach(struct dvb_frontend
> *fe,
>
> switch (id) {
> case XC_PRODUCT_ID_FW_LOADED:
> + case XC_PRODUCT_ID_FW_LOADED_5000C:
> printk(KERN_INFO
> "xc5000: Successfully identified at address 0x%02x\n",
> cfg->i2c_address);
What is the bridge which interfaces the xc5000? The XC5000C typically
returns 0x1388 just like the xc5000. It's much more likely that the
I2C bus is broken on the bridge driver (or the chip is in reset at
this stage), the I2C request is silently failing and you're getting
whatever happens to have been in the buffer.
NACK unless you can produce an I2C bus trace showing those bytes
coming back over the wire.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
