[...] >> > >> > Shouldn't this be split into latency of the domain (and in the domain's >> > node) and latency of the device? >> >> Yes! $Subject patch only takes device latencies into account. >> >> Perhaps what you mean is that we should document device PM QoS >> latencies in another place than >> Documentation/devicetree/bindings/power/power_domain.txt as well? > > Yes, the location is confusing that this is device latency which has > nothing to do with power domains other than the fact we've lost all > state (which a reset could cause too). Okay, will a new file, Documentation/devicetree/bindings/power/device_qos.txt make sense for you? > >> Regarding bindings for the domain latencies, I will post that as a >> separate patch soonish. > > It probably makes sense to look at latency bindings as a whole series. Well, unless you insist, I would rather look at this first. The domain latencies might be a bit more complex and those shouldn't affect how we describe device latencies, or you think so? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
