Re: [PATCH 00/16] rmk's patch series for fixing OMAP
From: Russell King - ARM Linux <hidden>
Date: 2012-02-09 00:53:34
Also in:
linux-arm-kernel, linux-omap
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:quoted
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd Author: Tomi Valkeinen [off-list ref] 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.quoted
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.
quoted
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?)