On Wed, Feb 08, 2012 at 08:31:49PM +0000, Florian Tobias Schandinat wrote: > Hi Russell, > > On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote: > > commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd > > Author: Tomi Valkeinen <tomi.valkeinen@xxxxxx> > > Date: Tue Jan 17 11:09:57 2012 +0200 > > > > OMAPDSS: HDMI: PHY burnout fix > > > > A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board > > if the HDMI PHY is kept powered on when the cable is not connected. > > I agree this is a serious issue. > > > which now has me wondering if, by trying to boot v3.3-rc2 on this board > > during the past week, I have a destroyed HDMI interface on it. > > I am not sure as I don't keep track of all OMAP changes, but you make it > sound like a regression, is there any difference to 3.2 behavior? I've no idea when the problem was introduced, that's not the point that I'm making. The point that I'm making is that the patch is dated January 17th, it was apparantly committed on the 26th, and it went into mainline on the 8th February. For a patch which fixes a _hardware_ _destruction_ issue, three weeks is _FAR_ too long for it to take to get into mainline. Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the 4430 SDP platform, _including_ the HDMI code, and looking at the commit it could be one of those platforms which is affected. As I don't have a HDMI cable connected to the system, and I ran that kernel overnight, and I tried opening each /dev/fb* device, what I'm now wondering is: have I destroyed the HDMI PHY on my 4430SDP? But that's not really the point. The point is, for someone to sit on such a patch for weeks is, in my opinion, as good as saying to your users "I don't care if you bust your hardware." However, you raise another point, a much more serious one at that. Is this problem also present in 3.2? The patch seems to apply almost cleanly to that kernel version, so I guess it is. It fails to apply to v3.1 because of missing files, so I guess 3.1 is unaffected. So, why isn't this patch copied to the stable people? And why is there this seemingly lack of care for hardware destruction bugs? Please, if it affects v3.2, PLEASE PLEASE PLEASE tell the stable people who know nothing about this commit until I asked them this evening about it. > > So, a big thanks for sitting on that fix and exposing peoples hardware > > to damage, that shows real professionalism. > > Well, I am no professional to begin with, at least in the sense of getting paid > for it. That said I'm quite happy if I manage to find a few hours every weekend > to do the work. Given that the final thing should be tested in -next before I > ask Linus to pull, it is completely usual (and even quite fast) if things take > 8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus > to pull directly for such issues. For hardware destruction issues, once the problem has been identified, it should be shouted about very loudly to get it upstream as quickly as possible. I'm sure Linus would've even taken it in patch form. (You do realise that Linus does apply patches as well as pulling trees?) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
