Le lundi 20 mai 2013 01:38:18, Tejun Heo a écrit : > I don't really wanna go that way. Those bridges always have been > something fringe and broken in ways which aren't fundamentally > fixable. Fixing one would break another without anyway to properly > detect them. > > So, I'm okay with having a knob for cases where the user knows what to > do but I don't think even that is something of much importance, and > I'm definitely not gonna do anything which may affect !bridge case > adversely. I understand. > Those bridges have always been a second-class citizen and > their importance has waned a lot. Just a bit of background on why I got interested in Csaba's patch: I never used my bridges when I originally got them (serillel was bundled with some motherboards I bought circa 2003), because a PATA controller was available anyway. Since then, I changed all my hard drives progressively to SATA ones because of the capacity increase. But I still have many DVD drives from that time, because there was just no motivation to change them, and I don't have any optical SATA drive. Then I bought a new motherboards a few weeks ago, without paying enough attention: there is no PATA controller on it. So I remembered those bridges and finally tried to use them. Now, given that those bridges are old and were originally IMHO very close to useless, I'm indeed probably part of a fringe who didn't throw them away and remember them. SATA optical drives are quite cheap, maybe there is not even a financial motivation to look for such bridge. > EH stands for exception handling and discovery / init definitely are > part of exception handling in libata speak. Thanks for the clarification. > So, nope, I really don't want this. Err, the body of this patch didn't change from my original submission, only the commit message has changed. > > +atapi_dmadir > > + > > + Bitmask enabling dmadir for corresponding device if ATAPI. > > + 1: Enable dmadir for port's device 0 > > + 2: Enable dmadir for port's device 1 > > + (etc) > > + See also libata's atapi_dmadir module parameter. > > Shouldn't this be a device property? Unplugging the drive would, in my understanding, loose the setting if stored at the device level. Is there another way to trigger a new initialisation attempt after changing the setting ? Should I add a "rescan" device attribute ? Regards, -- Vincent Pelletier -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
