| Message ID | 20201006160516.319830-1-ulf.hansson@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | power: avs: Move drivers to the soc directories and drop avs | expand |
On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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. Cheers!
+ Arnd On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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. Kind regards Uffe
On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > + Arnd > > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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. Thanks!
On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > + Arnd > > > > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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. 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.. Kind regards Uffe
On Wednesday, October 21, 2020 12:41:50 PM CEST Ulf Hansson wrote: > On Fri, 16 Oct 2020 at 18:30, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Wed, Oct 7, 2020 at 5:23 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > > > + Arnd > > > > > > On Wed, 7 Oct 2020 at 17:09, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > > > > On Tue, Oct 6, 2020 at 6:05 PM Ulf Hansson <ulf.hansson@linaro.org> 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!
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. Kind regards Ulf Hansson Ulf Hansson (4): power: avs: qcom-cpr: Move the driver to the qcom specific drivers power: avs: rockchip-io: Move the driver to the rockchip specific drivers power: avs: smartreflex Move driver to soc specific drivers power: avs: Drop the avs directory and the corresponding Kconfig MAINTAINERS | 6 +-- arch/arm/plat-omap/Kconfig | 2 +- drivers/power/Kconfig | 1 - drivers/power/Makefile | 1 - drivers/power/avs/Kconfig | 37 ------------------- drivers/power/avs/Makefile | 4 -- drivers/soc/qcom/Kconfig | 16 ++++++++ drivers/soc/qcom/Makefile | 1 + .../{power/avs/qcom-cpr.c => soc/qcom/cpr.c} | 0 drivers/soc/rockchip/Kconfig | 8 ++++ drivers/soc/rockchip/Makefile | 1 + .../rockchip/io-domain.c} | 0 drivers/soc/ti/Makefile | 1 + drivers/{power/avs => soc/ti}/smartreflex.c | 0 14 files changed, 31 insertions(+), 47 deletions(-) delete mode 100644 drivers/power/avs/Kconfig delete mode 100644 drivers/power/avs/Makefile rename drivers/{power/avs/qcom-cpr.c => soc/qcom/cpr.c} (100%) rename drivers/{power/avs/rockchip-io-domain.c => soc/rockchip/io-domain.c} (100%) rename drivers/{power/avs => soc/ti}/smartreflex.c (100%)