On Wednesday, October 21, 2020 12:41:50 PM CEST Ulf Hansson wrote: > On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <[email protected]> wrote: > > > > On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <[email protected]> wrote: > > > > > > + Arnd > > > > > > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <[email protected]> wrote: > > > > > > > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <[email protected]> > > > > wrote: > > > > > > > > > > The avs drivers in drivers/power/avs/* are all SoC specific drivers > > > > > that > > > > > doesn't share any code. Instead they are located in a directory, > > > > > mostly to keep > > > > > similar functionality together. From a maintenance point of view, it > > > > > makes > > > > > better sense to collect SoC specific drivers like these, into the SoC > > > > > specific > > > > > directories. > > > > > > > > > > Therefore, this series moves the drivers, one by one - and in the > > > > > end, it > > > > > deletes the empty avs directory. > > > > > > > > > > It seems best to me, if this can be funneled via Rafael's linux-pm > > > > > tree. Then > > > > > when going forward, each driver should be managed through the SoC > > > > > maintainer's > > > > > trees. > > > > > > > > That's fine by me. > > > > > > > > I'd like to get an ACK from the arm-soc side on this, though. > > > > > > I have looped in Arnd, to get his opinion on this. > > > > > > Although, I think the people on cc already send pull requests to the > > > arm-soc maintainers (or perhaps it was these people you were referring > > > to), so just awaiting their acks should be fine, I guess. > > > > OK > > > > For now, I've taken patches [2-3/4] that have been ACKed. > > > > When the [1/4] is ACKed, I'll take it too and apply the last one. > > Patch 1/4 has been acked now as well, so I think the remaining part of > this series is ready to go.
Agreed, I'm going to apply the remaining two patches from it tomorrow. > However, I noticed that Stephen Rothwell reported some merge conflicts > for arm-soc in linux-next. Quite trivial to resolve, though. Perhaps > an option to consider is to send this as material for v5.10-rc1 (or > maybe rc2) to avoid further conflicts during this release cycle? Just > an idea.. Yes, I'm going to do that. Thanks!
