public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: matthieu castet <castet.matthieu@free.fr>
To: Linux and Kernel Video <video4linux-list@redhat.com>
Cc: Christer Weinigel <christer@weinigel.se>,
	linux-kernel@vger.kernel.org, Nathan Laredo <laredo@gnu.org>
Subject: Re: Stradis driver conflicts with all other SAA7146 drivers
Date: Sun, 28 May 2006 19:46:32 +0200	[thread overview]
Message-ID: <4479E1F8.4030606@free.fr> (raw)
In-Reply-To: <4479DF88.2040500@gmail.com>

Jiri Slaby wrote:
> Christer Weinigel napsal(a):
> 
>>Jiri Slaby <jirislaby@gmail.com> writes:
>>
>>
>>>Christer Weinigel napsal(a):
>>>
>>>>fixed in the driver.  If the card doesn't have a subvendor/subdevice,
>>>>is there some way of doing a sanity check on the board to see if it
>>>>actually is a stradis card and then release the board if it isn't?
>>>
>>>Unfortunately not.
>>
>>Why not?  There's an I2C bus with a bunch of devices on it.  Isn't it
>>possible to do an I2C scan and if it doesn't match what's supposed to
>>be on the card fail the probe and release the PCI resources?
> 
> This is an older method not used for device drivers, but only for searching for
> busses or i2c et al, of which drivers stands aside and controls the device.
> 
>>If there is no FPGA or the FPGA fails to respond, that should also be
>>a fairly good indicator that it is not a stradis board.
> 
> Yup, but pci probing doesn't have such mechanism.
Hum ?
The driver have to return an error (negative value) in the probbing 
function if it detect that the card fails to respond correctly.

Same happen for i2c.
If the driver didn't manage to find what it expect on the i2c bus, the 
driver won't be usefull for the device, so the driver should release the 
device.

Matthieu

  reply	other threads:[~2006-05-28 17:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-28 12:33 Stradis driver conflicts with all other SAA7146 drivers Christer Weinigel
2006-05-28 12:53 ` Jiri Slaby
2006-05-28 14:04   ` Mauro Carvalho Chehab
2006-05-28 16:01     ` Nathan Laredo
2006-05-28 16:17       ` Jiri Slaby
2006-05-28 17:31       ` Mauro Carvalho Chehab
2006-05-28 17:58         ` Christer Weinigel
2006-05-28 18:40           ` Mauro Carvalho Chehab
2006-05-29 12:46             ` [v4l-dvb-maintainer] " Michael Hunold
2006-05-29 13:33               ` Mauro Carvalho Chehab
2006-05-29 13:43                 ` Michael Hunold
2006-05-29 13:58                   ` Mauro Carvalho Chehab
2006-05-29 14:38                     ` Gerd Hoffmann
2006-05-31 14:01                     ` Alan Cox
2006-05-31 14:29                       ` Arjan van de Ven
2006-05-29 12:44           ` Michael Hunold
2006-05-29 22:51             ` Christer Weinigel
2006-05-28 16:02   ` Christer Weinigel
2006-05-28 16:36     ` Jiri Slaby
2006-05-28 17:17       ` Christer Weinigel
2006-05-28 17:36         ` Jiri Slaby
2006-05-28 17:46           ` matthieu castet [this message]
2006-05-28 20:29             ` Jiri Slaby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4479E1F8.4030606@free.fr \
    --to=castet.matthieu@free.fr \
    --cc=christer@weinigel.se \
    --cc=laredo@gnu.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox