On Thu, Oct 6, 2016 at 4:20 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > On 06/10/16 14:04, Rafael J. Wysocki wrote: >> >> On Thu, Oct 6, 2016 at 12:29 PM, Sudeep Holla <sudeep.holla@xxxxxxx> >> wrote: > > > [...] > >>> No doubt about that, though controlling it is another question. >>> Especially ARM vendors who have some driver for DT might just use this >>> method without anyone noticing, ignoring the ACPI method as everything >>> just works out of box. That's the main worry. Also it also provides no >>> incentive for them to work with ASWG to enhance ACPI specification. >> >> >> They will need to hack the kernel to do that, because the mainline >> will not support anything like regulator or pinctrl support based on >> DT properties, at least as long as I have any influence on that. >> > > OK, that's good. > >> And if they need to hack the kernel anyway, nothing prevents them from >> hacking it to support whatever properties they like even if we don't >> put any support for any generic _DSD properties into the mainline. >> That's why the whole "oh but this allows ARM vendors to abuse things" >> argument doesn't hold any water in my view. >> > > While I agree with you, the argument which will be done and will win > most of the time to upstream something is that "we have shipped the > product with that table, we need to support it upstream...". I don't > think even you disagree with that ;) 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 ... 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
