Li Yang <le...@freescale.com> writes: > The original code was there before I touched the driver. So > unfortunately I also don't know the history of the problem.
Alas. > Judging from the comment in code and current test result I guess it > is a board related issue. I wonder if anyone on the 8315_DS project knows where the limitation came from, since that's the origin of the workaround... Regardless, it's recommended by at least one vendor who based their design on the 8315 RDB. If it's board-related, then that seems a reasonable conditional. > I agree with Anthony that the best action for now is to remove the > workaround completely. Eeek. I'm pretty sure that it needs to stay. (I can't guarantee that it has fixed my problem, but it's been a week or two without the hang, so I'm becoming more confident). I think the question is how to best conditionalize it. The options seem to be: 1. at compile time, via kconfig bits; 2. at runtime via probing / discovery; or 3. at runtime via device tree. Given that this is a relatively old platform, and only 2-3 of us have run into this issue in 5 years, I'm inclined to just go with option 1. That's exactly what Adrian's patch (from 2008!) does: http://old.nabble.com/-2.6-patch--sata_fsl.c%3A-fix-8315DS-workaround-td18807647.html Using CONFIG_831x_RDB seems like a reasonable choice. Anyway. To be clear, my project is currently in good shape (by adopting Adrian's patch) so I don't have any actual urgency for fixing this. I was hoping that someone might know the "correct" answer offhand, but I honestly think that this isn't worth spending too much time on. (But I do think that Adrian's patch is an improvement over the current state of affairs.) Thanks again to everyone that's chimed in. Best regards, Anthony Foiani _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
