From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
bcollins@debian.org, Greg KH <greg@kroah.com>,
scjody@steamballoon.com, gregkh@suse.de
Subject: Re: new PCI quirk for Toshiba Satellite?
Date: Mon, 24 Oct 2005 10:45:07 -0700 [thread overview]
Message-ID: <200510241045.08494.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <43594BD3.9070103@s5r6.in-berlin.de>
On Friday, October 21, 2005 1:13 pm, Stefan Richter wrote:
> 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).
Ok, I'll update Rob's patch to the latest tree and send it on (I hadn't
seen it yet when I wrote my version).
> It seems to me, using the .callback and .driver_data doesn't make it
> cleaner and leaner.
I agree, I thought it was necessary since I hadn't looked at
dmi_check_system and didn't know if it had a return value I could check.
Rob's patch looks much simpler and nicer.
> > 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.
Having it all in the driver probably makes the most sense if we have to
have code there anyway. Otherwise future users may have to check both
places if things break again in another configuration.
> 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__).
Checks against the compiler defined arch are usually wrong since users
could be cross compiling, and I'd like to avoid an ifdef altogether. I
think we can make the code collapse entirely by fixing linux/dmi.h. If
we remove the !defined(CONFIG_X86_64) check around the extern of
dmi_check_system, all other arches will have it defined to simply return
0, causing gcc to remove the dead conditional in ohci1394.c.
Anyway, I'll refresh that patch, test it, and send it on to Andrew,
hopefully tonight.
Thanks,
Jesse
next prev parent reply other threads:[~2005-10-24 17:45 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
2005-10-24 17:45 ` Jesse Barnes [this message]
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=200510241045.08494.jbarnes@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=bcollins@debian.org \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=scjody@steamballoon.com \
--cc=stefanr@s5r6.in-berlin.de \
/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