mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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/

  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®