On Sat, Aug 09, 2008 at 02:29:31PM +0200, Bastian Blank wrote: > On Sat, Aug 09, 2008 at 01:18:10PM +0200, Robert Millan wrote: > > I'll be working on a patch for this one today. > > Some advices: > - Please make a minimal fix. As the firmwares are fix-only it may just > remove them and the code referencing it. Please note that the patch > must not include parts of the problematic code, use unifdef (see > debian/patches/debian/dfsg/files-0 and the tg3 patches) to remove them > and after that change anything else. This patch goes into the orig and > it should not be broken because of that. > - If you want (and can test it with the hardware) make the firmware > loadable from userspace in a second patch. This patch goes into the > normal flow and can be changed later.
Okay. Which one of these do you prefer: - Make the orig patch as minimal as possible, even if it leaves the source in a state that won't build, then provide one (or two) patches to fix build and/or implement userspace load. - Make the orig patch remove the firmware, but with care not to break build or support for ICH, then provide another patch to implement userspace load. I also looked at Jaswinder's patch in http://lkml.org/lkml/2008/6/14/102. I notice some details that I missed in my work; but it also looks more intrusive in general (something that I assume is fine for upstream but not so for Debian). What's the upstream status of Jaswinder's patch? From the discussion it seems upstream is arguing about in which directory this patch can be put. Does anyone know if this will be merged? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]