On Tue, Oct 11, 2016 at 10:57 AM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > On 11/10/16 01:05, Rafael J. Wysocki wrote: >> >> On Thu, Oct 6, 2016 at 7:20 PM, Sudeep Holla <sudeep.holla@xxxxxxx> >> wrote: > > > [...] > >>>> Well, maybe they should have talked to the upstream before >>>> shipping the product with that table? Failing to do so is like >>>> jumping to a pool from a tower without checking how much water is >>>> there in it in the first place ... >>>> >>> >>> Really ? I admit that I like this response and your stance here and >>> I definitely support it but I have seen quite a few cases which >>> tells me otherwise. >> >> >> Was I involved in any of those? >> > > No I wasn't referring to any particular case here. What I meant is we > have quite a few hacks/workarounds even on x86 for various reasons like: > other OS works, the product is shipped and firmware can't be fixed, and > so on. We might encounter similar situations even with DSD in future and > hence my worries. There surely will be cases when people mess up their _DSD and validation is insufficient and so on. That seems to be the nature of the business today. What I'm talking about is not implementation mistakes, but cases when people have a problem to address and decide to do that in a way that cannot be done by the mainline (for technical reasons), and then expect the mainline to accept this. When in doubt about which way to go, they should talk to the mainline in the first place or the solution they choose may stay out of the tree forever (and become a major pain to maintain going forward). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
