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
next prev parent 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®