> > 1) They do not apply cleanly on top of other i2c-designware changes I > > applied (check i2c/for-next I just pushed out). The conflicts might not > > be hard, but they were not trivial enough for me to do them inbetween > > other things. I'd be very happy about a repost on top of i2c/for-next. > > OK, I'll do that. Great, much appreciated! > > 2) "pretty much have" is not so convincing to me. That is such a generic > > core, it probably has enough out-of-tree users as well. > > I wasn't aware that we care about out-of-tree users. This is one example coming from a feeling that we should at least try to make this change having less impact. > > And with all these ACPI regressions from this cycle, I am very > > cautious right now. Brainstorming: What about "depends on (ACPI && > > COMMON_CLK) || !ACPI"? > > Understood. I'll try the above. Cool, thanks!
Attachment:
signature.asc
Description: Digital signature
