On Tue, May 01, 2007 at 11:51:41PM -0700, Tim Hockin wrote: > I'm not sure what the right answer is. The code was designed to do > the right thing, and yet in your case it's broken. Does it need to be > a build option to work around broken hardware? Yuck. Without a system that really needs the original problem that was being worked around it's going to be hard to see if the workaround still does the job. Given the nature of the failure I wouldn't be surprised if it broke different things on every board that has problems. How about a sysfs tuneable? It's not nice but at least it's runtime. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Attachment:
signature.asc
Description: Digital signature
- References:
- Re: Natsemi DP83815 driver spaming
- From: Mark Brown <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Mark Brown <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Mark Brown <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: Rafał Bilski <[email protected]>
- Re: Natsemi DP83815 driver spaming
- From: "Tim Hockin" <[email protected]>
- Re: Natsemi DP83815 driver spaming
- Prev by Date: Re: [patch] CFS scheduler, -v8
- Next by Date: RE: How to make mmap'ed kernel buffer non-cacheable
- Previous by thread: Re: Natsemi DP83815 driver spaming
- Next by thread: Re: Natsemi DP83815 driver spaming
- Index(es):