Re: new PCI quirk for Toshiba Satellite?

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Jesse Barnes wrote:
> On Friday, October 21, 2005 1:13 pm, Stefan Richter wrote:
> > Jesse Barnes wrote:
> > > 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.

No, better move it to pci/quirks.c. I may be wrong (again) but I think
everything of the workaround can be done there.

> > 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.

Once the workaround is in pci/quirks.c, a single #ifdef would suffice
(if it is still of any benefit there).
--
Stefan Richter
-=====-=-=-= =-=- ==---
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/