From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
bcollins@debian.org, Greg KH <greg@kroah.com>,
scjody@steamballoon.com, gregkh@suse.de
Subject: Re: new PCI quirk for Toshiba Satellite?
Date: Fri, 21 Oct 2005 22:13:07 +0200 [thread overview]
Message-ID: <43594BD3.9070103@s5r6.in-berlin.de> (raw)
In-Reply-To: <200510211138.57847.jbarnes@virtuousgeek.org>
Jesse Barnes wrote:
> Stefan, is a PCI quirk addition possible or do we have to use
> dmi_check_system in the ohci driver itself (since we have to reprogram
> the cache line size in addition to the other registers)?
I am not familiar with the PCI subsystem, thus cannot advise how to
handle it best nor wanted to post a patch myself (yet).
[...]
>> .callback = ohci1394_toshiba_reprogram_config,
>> .ident = "Toshiba PSM4 based laptop",
>> .matches = {
>> DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
>> DMI_MATCH(DMI_PRODUCT_VERSION, "PSM4"),
>> },
>> .driver_data = &tosh_data;
It seems to me, using the .callback and .driver_data doesn't make it
cleaner and leaner.
> But then what about the dev->current_state = 4? Is that necessary?
It is necessary; at least if the workaround resides in ohci1394.
Otherwise the controller won't come back after a suspend/ resume cycle.
(See Rob's post from February,
http://marc.theaimsgroup.com/?m=110786495210243 ) Maybe there is another
way to do that if the workaround was moved to pci/quirks.c.
[...]
> + if (toshiba) {
> + dev->current_state = 4;
> + pci_read_config_word(dev, PCI_CACHE_LINE_SIZE, &toshiba_data);
> + }
> +
> if (pci_enable_device(dev))
> FAIL(-ENXIO, "Failed to enable OHCI hardware");
> pci_set_master(dev);
>
> + if (toshiba) {
> + mdelay(10);
> + pci_write_config_word(dev, PCI_CACHE_LINE_SIZE, toshiba_data);
[...]
pci_set_master(dev) can be moved below the second part of the Toshiba
workaround. That means AFAIU, the 2nd part of the Toshiba workaround can
be moved out of ohci1394 into pci_fixup_device() which is called from
pci_enable_device(), to be called as a DECLARE_PCI_FIXUP_ENABLE hook.
The first part of the workaround, i.e. caching the cache line size, for
example by means of a static variable, would have to go into an
_FIXUP_EARLY, _FIXUP_HEADER, or _FIXUP_FINAL hook. I am not sure yet
about which type of hook to use.
Furthermore, everything which belongs to the workaround should IMO be
enclosed by #ifdef SOME_SENSIBLE_MACRO. This avoids kernel bloat for any
target which is surely not a Toshiba laptop. Rob used an #if
defined(__i386__).
--
Stefan Richter
-=====-=-=-= =-=- =-=-=
http://arcgraph.de/sr/
next prev parent reply other threads:[~2005-10-21 20:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-15 18:55 ohci1394 unhandled interrupts bug in 2.6.14-rc2 jbarnes
2005-10-15 19:39 ` Stefan Richter
2005-10-15 20:29 ` Jesse Barnes
2005-10-15 20:40 ` new PCI quirk for Toshiba Satellite? Jesse Barnes
2005-10-20 0:06 ` Greg KH
2005-10-20 18:32 ` Stefan Richter
2005-10-21 18:38 ` Jesse Barnes
2005-10-21 20:13 ` Stefan Richter [this message]
2005-10-24 17:45 ` Jesse Barnes
2005-10-24 18:07 ` Jesse Barnes
2005-10-24 18:21 ` Stefan Richter
2005-10-24 21:09 ` Ivan Kokshaysky
2005-10-15 21:02 ` ohci1394 unhandled interrupts bug in 2.6.14-rc2 Stefan Richter
2005-10-15 21:59 ` Jesse Barnes
2005-10-17 7:55 ` Andrew Morton
2005-10-17 9:35 ` Stefan Richter
2005-10-17 9:42 ` Andrew Morton
2005-10-17 10:03 ` Stefan Richter
2005-10-17 16:30 ` Jesse Barnes
2005-10-17 18:50 ` Stefan Richter
2005-10-19 17:54 ` Jesse Barnes
2005-10-17 12:48 ` rob
2005-10-17 15:58 ` Stefan Richter
2005-10-18 5:32 ` rob
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=43594BD3.9070103@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=bcollins@debian.org \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=scjody@steamballoon.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
all inboxes | Powered by JetHome®