mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Rudolf Marek <r.marek@sh.cvut.cz>
To: Jordan Crouse <jordan.crouse@amd.com>
Cc: Jean Delvare <khali@linux-fr.org>,
	info-linux@ldcmail.amd.com, BGardner@Wabtec.com,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] scx200_acb: Use PCI I/O resource when appropriate
Date: Tue, 11 Apr 2006 18:29:21 +0200	[thread overview]
Message-ID: <443BD961.3050807@sh.cvut.cz> (raw)
In-Reply-To: <20060411161942.GB13334@cosmic.amd.com>

Hello all,

> And so our dirty laundry is out... :)
> 
> We have a sad history here - back a few parts, we had less descriptors to 
> describe IO, so we opted to combine several components under the same PCI
> header to save resources.  So the bottom line is that we have at least three
> desirable devices (timers, GPIO pins and the SMBus) that all lay claim to
> the same device.  So a proper PCI header would be difficult to implement - 
> either we would have 1 device that registered with three different
> subsystems, or we would have three individual devices, the first of which
> would get the PCI resources to the ruin of the others.

Well we had the problem with i2c-viapro and vi686a. Best solution was
to fail from the probe function - like this:

         /* Always return failure here.  This is to allow other drivers to bind
          * to this pci device.  We don't really want to have control over the
          * pci device, we only wanted to read as few register values from it.
          */
         return -ENODEV;

release_region:
         release_region(vt596_smba, 8);
         return error;
}

> 
> So this is the solution I came up with, for older parts.  For newer parts,
> I sat the BIOS guys down in a room with a guy name Bruno, and they agreed
> to make a separate header for each component.

This is good ;)

Regards
Rudolf

  reply	other threads:[~2006-04-11 16:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-31 23:03 [PATCH 2.6] " Jordan Crouse
2006-04-11 12:07 ` Jean Delvare
     [not found] ` <LYRIS-4270-45297-2006.04.11-06.08.18--jordan.crouse#amd.com@whitestar.amd.com>
2006-04-11 16:19   ` Jordan Crouse
2006-04-11 16:29     ` Rudolf Marek [this message]
2006-04-11 20:42       ` Jean Delvare
2006-04-11 21:02     ` Jean Delvare

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=443BD961.3050807@sh.cvut.cz \
    --to=r.marek@sh.cvut.cz \
    --cc=BGardner@Wabtec.com \
    --cc=info-linux@ldcmail.amd.com \
    --cc=jordan.crouse@amd.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    /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

all inboxes | Powered by JetHome®