On Mon 27 Apr 2020 at 18:23, Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> wrote: > Hi Jerome, > > On Mon, Apr 27, 2020 at 10:56 AM Jerome Brunet <jbrunet@xxxxxxxxxxxx> wrote: > [...] >> > Changes since v3 at [3]: >> > - split the clock bits into a separate clock controller driver because >> > of two reasons: 1) it keeps the MMC controller driver mostly clean of >> > the clock bits >> >> If the register is in the MMC controller register space and the MMC >> driver is the driver using these clocks, it is where the clocks belong. >> I don't get why it could be an issue ? >> >> Is the clock block is shared with another device, like on the Gx family ? > no, it is not shared with another device (to my knowledge). > >> > 2) the pure clock controller can use >> > devm_clk_hw_register() (instead of devm_clk_register(), which is >> > deprecated) and the MMC controller can act as a pure clock consumer. >> >> Why can't you use devm_clk_hw_register in an MMC driver ? >> Unless I missed something, it is provided by clk-provider.h, which can be >> included by any driver. > indeed, I could use devm_clk_hw_register in the MMC driver. > Ulfs concern was that a lot of code was needed for managing the clocks > and I agree with him. so this is my way of keeping those details away > from the MMC driver and have two separate drivers which are better to > understand overall. Martin, Ulf, I understand that CCF code might seems verbose and I'm happy to help review it if necessary but I don't think every driver out there should register some kind of fake clock controller driver everytime they wish to use CCF API. Yes the it might make the driver code cleaner but the overall architecture is harder to follow. CCF was made so driver from any subsystem *may* use it. Creating a controller for a single register is overkill. The HW architecture of this particular device does not justify it. > > > Martin
