Quoting Russell King - ARM Linux admin (2019-01-31 07:21:47) > On Thu, Jan 31, 2019 at 03:24:52PM +0200, Matti Vaittinen wrote: > > Hello All, > > > > On Fri, Dec 07, 2018 at 01:09:00PM +0200, Matti Vaittinen wrote: > > > Series adds managed clkdev lookup interfaces and cleans few drivers > > > > > > Few clk drivers appear to be leaking clkdev lookup registrations at > > > driver remove. The patch series adds devm versions of lookup > > > registrations and cleans up few drivers. Driver clean-up patches have > > > not been tested as I lack the HW. All testing and comments if > > > driver/device removal is even possible for changed drivers is highly > > > appreciated. If removal is not possible I will gladly drop the patches > > > from series - although leaking lookups may serve as bad example for new > > > developers =) > > > > > > Changed drivers are: > > > clk-max77686 and clk-st > > > > > > Please note that the patch #2 requires this change to work correctly: > > > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=05502bf9eb7a7297f5fa6f1d17b169b3d5b53570 > > > > I guess the dependency mentioned abowe is already in (most) of the > > trees. (I can't say for sure as I don't know what is the correct tree > > for clkdev - is it linux-arm.git as Russel is maintaining clkdev? > > Yes, I'm supposed to be maintaining clkdev, but I'm busy with other > stuff (such as reorganising my network, helping people with SFP issues, > I'm supposed to be replying to Arend over a brcmfmac issue that has been > on-going since Christmas which I haven't yet been able to doing the next > test...) > > > If yes, then the commit 05502bf9eb7a7297f5fa6f1d17b169b3d5b53570 > > "clk: of-provider: look at parent if registered device has no > > provider info" seems to be sitting in maser branch). > > It's there because it's part of the mainline kernel and has been > since v5.0-rc1. So, if you depend on that commit, basing off > v5.0-rc1 is probably sane, unless there's something else that > conflicts. > I can pick up the patches in the clk tree. Clk drivers will be the users so it's probably simplest to merge the clkdev patch in clk tree and then consumers can be updated at the same time in a patch stack on top of that. Otherwise, if I can get a stable branch/tag to pile the clk driver patches on I can apply them that way and then the clkdev patch can go via Russell.
