On Monday, July 27, 2015 10:29:34 PM Lee Jones wrote: > On Mon, 27 Jul 2015, Lee Jones wrote: > > > On Mon, 27 Jul 2015, Rafael J. Wysocki wrote: > > > > > On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote: > > > > On Mon, 27 Jul 2015, Mika Westerberg wrote: > > > > > > > > > On Mon, Jul 27, 2015 at 04:27:33PM +0100, Lee Jones wrote: > > > > > > FAO Stephen Boyd, > > > > > > > > > > > > > Stephen, can you, please, have a look into patch 8 regarding to clock name > > > > > > > matching and other stuff Lee asked? > > > > > > > > > > > > Patch 8: > > > > > > > > > > > > "Can you review the clock implementation please? It looks > > > > > > fragile to me as it relies heavily on device names constructed > > > > > > of MFD cell names and IDA numbers cat'ed together!" > > > > > > > > > > Lee, can you suggest an alternative then? > > > > > > > > > > Why we are doing it like this is that number of different LPSS devices > > > > > changes from SoC to SoC. In addition to that the device (called "slice") > > > > > might have iDMA block or not. > > > > > > > > > > Since the drivers in question (pxa2xx-spi, i2c-designware and 8250_dw) > > > > > use standard clk framework to request their clocks the Linux device must > > > > > have clock registered which matches the device in advance. > > > > > > > > > > Because we add the host controller device dynamically (from the MFD > > > > > driver) based on how many devices are actually present, we need somehow > > > > > predict what would be the correct name and instance number for that > > > > > device to get the clock for it. That's the reason we use IDA here along > > > > > with the cell name (or driver name). > > > > > > > > I'm sure there are perfectly viable reasons for you doing this. And I > > > > don't know the CCF well enough to know whether it's the best idea or > > > > not, or else I would have made a suggestion rather than waiting all > > > > this time. > > > > > > > > It's for this reason that I needed Mike (now Stephen) to take a look > > > > and give me either an Ack, to say it's the best solution, or to > > > > provide a better alternative. > > > > > > > > Until that happens, I'm stuck! > > > > > > Well, what if we had no one at hand to review that code? Would that mean it > > > would not be applicable forever? > > > > No, but that's not the case is it? > > > > I don't understand why Mike and Stephen aren't helping! > > I'll wait until tomorrow and if we haven't heard anything I'll make a > decision. OK, thanks! BTW, I don't have the time to review every single patch using ACPI or one of the PM frameworks. If people who use them make mistakes, it is their burden to fix those mistakes when they show up in testing. What's happening here is that Andy and Mika are taking the responsibility for fixing the new code if it turns out to be buggy and so it's their problem if it happens to be broken. And you can still revert commits that introduce bugs as a last resort. -- 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
