On Thu, Oct 6, 2016 at 5:23 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Thu, Oct 06, 2016 at 03:15:36PM +0200, Rafael J. Wysocki wrote: >> On Thu, Oct 6, 2016 at 12:40 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > One of my biggest concerns with this approach is that I'm really not >> > clear to me that that this has broad buy in from the x86/ACPI community >> > and therefore that we might end up needing to support several different >> > styles of ACPI bindings. Reuse would be great but it can be confusing >> > if there's multiple different styles of bindings in use at the same >> > time. > >> My view on that is a bit different. > >> Even if there's more than one style in use, they all can be supported >> at the same time. Avoiding confusion is only a matter of prioritizing >> them, then. > >> It should be clear which style is the default one, which is going to >> be taken into consideration next and so on. If that is made clear, I >> don't see a big problem here, at least in principle. > > My concern isn't just people using multiple styles, it's also people > trying to mix and match. Sometimes that will work well enough and it's > fine but it can go wrong. Yes, it can. I'm not against being careful, but I'd rather not reject things as a matter of principle. >> The pinctrl thing is being dealt with (and not in a way of adding >> pinctrl _DSD properties support to the kernel FWIW). Other things >> potentially conflicting with ACPI-defined HW control should be dealt >> with analogously. > > Right, I was mentioning it mainly as an example of the general pattern > of ACPI bindings springing up without coordination rather than as a > specific problem that needs resolution. > >> The point here is that some things just don't conflict with >> ACPI-defined HW control even potentially and they can be handled with >> the help of _DSD properties just fine. Thus, there are no technical >> obstacles to do that, at least not in principle. > > It feels like we should be aiming for a higher bar with defining things > like this than simple technical possibility - my fear is that we end up > with a mess down the line with people being far too gung ho about > defining new bindings without trying to work on standards. But here we are talking about using bindings that (a) have already been defined in DT and (b) are actively used by the existing code. I guess you mean using existing DT bindings instead of working on standards, but let's face it, DT bindings de facto are the standard in some parts of the kernel. > Perhaps I'm just worrying too much here but I'm not sure there's enough > communication going on. The private nature of ACPI standardization > discussion doesn't help here of course. Agreed, and that doesn't apply to ACPI only, of course. 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
