| Message ID | 1379003839-16068-1-git-send-email-galak@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <galak@codeaurora.org> wrote: > Use the Qualcomm vendor prefix (qcom) as the directory name for > Qualcomm MSM devicetrees going forward. > > Signed-off-by: Kumar Gala <galak@codeaurora.org> Let's not move just one platform like this. If we are to do this, we should move everything, and that will be really painful and needs to be done in a controlled manner, probably scripted and right before a -rc1 or such. -Olof
On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote: > On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <galak@codeaurora.org> wrote: >> Use the Qualcomm vendor prefix (qcom) as the directory name for >> Qualcomm MSM devicetrees going forward. >> >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > > Let's not move just one platform like this. If we are to do this, we > should move everything, and that will be really painful and needs to > be done in a controlled manner, probably scripted and right before a > -rc1 or such. Than I suggest we deal with it when we pull the device trees out of the kernel tree. As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being. - k
On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <galak@codeaurora.org> wrote: > > On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote: > >> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <galak@codeaurora.org> wrote: >>> Use the Qualcomm vendor prefix (qcom) as the directory name for >>> Qualcomm MSM devicetrees going forward. >>> >>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >> >> Let's not move just one platform like this. If we are to do this, we >> should move everything, and that will be really painful and needs to >> be done in a controlled manner, probably scripted and right before a >> -rc1 or such. > > > Than I suggest we deal with it when we pull the device trees out of the kernel tree. > > As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being. My original request to please use a common prefix for your product families stands. Please prefix with msm-*, or if you have to, qcom-* instead, since you guys can't seem to make your mind up on standard prefixes (msm, apq, etc). -Olof
On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: > On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <galak@codeaurora.org> wrote: >> >> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote: >> >>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <galak@codeaurora.org> wrote: >>>> Use the Qualcomm vendor prefix (qcom) as the directory name for >>>> Qualcomm MSM devicetrees going forward. >>>> >>>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>> >>> Let's not move just one platform like this. If we are to do this, we >>> should move everything, and that will be really painful and needs to >>> be done in a controlled manner, probably scripted and right before a >>> -rc1 or such. >> >> >> Than I suggest we deal with it when we pull the device trees out of the kernel tree. >> >> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being. > > My original request to please use a common prefix for your product > families stands. Please prefix with msm-*, or if you have to, qcom-* > instead, since you guys can't seem to make your mind up on standard > prefixes (msm, apq, etc). This is silly, I dont see the reason to go with qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we mostly likely shift to a dir structure. As engineers we are all too aware of the lack of sanity in marketing names, but its what we have so we have to live with it. - k
On Thu, Sep 12, 2013 at 10:55 AM, Kumar Gala <galak@codeaurora.org> wrote: > > On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: > >> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <galak@codeaurora.org> wrote: >>> >>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote: >>> >>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <galak@codeaurora.org> wrote: >>>>> Use the Qualcomm vendor prefix (qcom) as the directory name for >>>>> Qualcomm MSM devicetrees going forward. >>>>> >>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>>> >>>> Let's not move just one platform like this. If we are to do this, we >>>> should move everything, and that will be really painful and needs to >>>> be done in a controlled manner, probably scripted and right before a >>>> -rc1 or such. >>> >>> >>> Than I suggest we deal with it when we pull the device trees out of the kernel tree. >>> >>> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being. >> >> My original request to please use a common prefix for your product >> families stands. Please prefix with msm-*, or if you have to, qcom-* >> instead, since you guys can't seem to make your mind up on standard >> prefixes (msm, apq, etc). > > This is silly, I dont see the reason to go with qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we mostly likely shift to a dir structure. > > As engineers we are all too aware of the lack of sanity in marketing names, but its what we have so we have to live with it. And we all have a choice whether we let the marketing people's insanity spread into our engineering projects, or if we keep it as sane as possible in spite of them. I wouldn't have an objection here if there was some sort of rationale between what "apq" and "msm" means. But it seems like qualcomm rolls a dice and decides if a platform will have one name or the other. Dragonboard dmesg says msm<foo>. DTS file for the same board says apq. DTSI file says one thing, overridden by the dts to something else. Total chaos. I would be fine with adding two instead of one (after all, platforms like TI has this for AM* vs OMAP*, etc), but there _has_ to be some sort of consistency or you might just as well assign a random string as name. So, if you can't come up with a reasonable, rational and consistent naming scheme (which, apparantly, you can't since your marketing guys are in control of this and they don't get it right), then at least prefix with a common string for the platform. That's all I'm asking. -Olof
On Sep 12, 2013, at 1:04 PM, Olof Johansson wrote: > On Thu, Sep 12, 2013 at 10:55 AM, Kumar Gala <galak@codeaurora.org> wrote: >> >> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: >> >>> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala <galak@codeaurora.org> wrote: >>>> >>>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote: >>>> >>>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala <galak@codeaurora.org> wrote: >>>>>> Use the Qualcomm vendor prefix (qcom) as the directory name for >>>>>> Qualcomm MSM devicetrees going forward. >>>>>> >>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>>>> >>>>> Let's not move just one platform like this. If we are to do this, we >>>>> should move everything, and that will be really painful and needs to >>>>> be done in a controlled manner, probably scripted and right before a >>>>> -rc1 or such. >>>> >>>> >>>> Than I suggest we deal with it when we pull the device trees out of the kernel tree. >>>> >>>> As such, I'd tell Rohit to go forward with the file being named apq8074-dragonboard.dtb for the time being. >>> >>> My original request to please use a common prefix for your product >>> families stands. Please prefix with msm-*, or if you have to, qcom-* >>> instead, since you guys can't seem to make your mind up on standard >>> prefixes (msm, apq, etc). >> >> This is silly, I dont see the reason to go with qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we mostly likely shift to a dir structure. >> >> As engineers we are all too aware of the lack of sanity in marketing names, but its what we have so we have to live with it. > > And we all have a choice whether we let the marketing people's > insanity spread into our engineering projects, or if we keep it as > sane as possible in spite of them. > > I wouldn't have an objection here if there was some sort of rationale > between what "apq" and "msm" means. But it seems like qualcomm rolls a > dice and decides if a platform will have one name or the other. > Dragonboard dmesg says msm<foo>. DTS file for the same board says apq. > DTSI file says one thing, overridden by the dts to something else. > Total chaos. > > I would be fine with adding two instead of one (after all, platforms > like TI has this for AM* vs OMAP*, etc), but there _has_ to be some > sort of consistency or you might just as well assign a random string > as name. > > So, if you can't come up with a reasonable, rational and consistent > naming scheme (which, apparantly, you can't since your marketing guys > are in control of this and they don't get it right), then at least > prefix with a common string for the platform. That's all I'm asking. > > > -Olof I'm not sure get why the insanity of naming impacts anything, those people that care about the platforms know what names mean what. Plus we have this same set of having to be in the know for other SoC already. Freescale does this all the time in PPC land, they just do it with numbers and not prefixes. I suggested doing a qcom/ dir, as it addresses your concern, of putting all of our mess in one place. Just because every other SoC/mach/plat hasn't done that should stop us from at least doing it for qcom. - k
On 09/12/2013 01:15 PM, Kumar Gala wrote: > > On Sep 12, 2013, at 1:04 PM, Olof Johansson wrote: > >> On Thu, Sep 12, 2013 at 10:55 AM, Kumar Gala <galak@codeaurora.org> >> wrote: >>> >>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: >>> >>>> On Thu, Sep 12, 2013 at 9:53 AM, Kumar Gala >>>> <galak@codeaurora.org> wrote: >>>>> >>>>> On Sep 12, 2013, at 11:46 AM, Olof Johansson wrote: >>>>> >>>>>> On Thu, Sep 12, 2013 at 9:37 AM, Kumar Gala >>>>>> <galak@codeaurora.org> wrote: >>>>>>> Use the Qualcomm vendor prefix (qcom) as the directory >>>>>>> name for Qualcomm MSM devicetrees going forward. >>>>>>> >>>>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>>>>> >>>>>> Let's not move just one platform like this. If we are to do >>>>>> this, we should move everything, and that will be really >>>>>> painful and needs to be done in a controlled manner, >>>>>> probably scripted and right before a -rc1 or such. >>>>> >>>>> >>>>> Than I suggest we deal with it when we pull the device trees >>>>> out of the kernel tree. >>>>> >>>>> As such, I'd tell Rohit to go forward with the file being >>>>> named apq8074-dragonboard.dtb for the time being. >>>> >>>> My original request to please use a common prefix for your >>>> product families stands. Please prefix with msm-*, or if you >>>> have to, qcom-* instead, since you guys can't seem to make your >>>> mind up on standard prefixes (msm, apq, etc). >>> >>> This is silly, I dont see the reason to go with >>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when >>> we mostly likely shift to a dir structure. >>> >>> As engineers we are all too aware of the lack of sanity in >>> marketing names, but its what we have so we have to live with >>> it. >> >> And we all have a choice whether we let the marketing people's >> insanity spread into our engineering projects, or if we keep it as >> sane as possible in spite of them. >> >> I wouldn't have an objection here if there was some sort of >> rationale between what "apq" and "msm" means. But it seems like >> qualcomm rolls a dice and decides if a platform will have one name >> or the other. Dragonboard dmesg says msm<foo>. DTS file for the >> same board says apq. DTSI file says one thing, overridden by the >> dts to something else. Total chaos. >> >> I would be fine with adding two instead of one (after all, >> platforms like TI has this for AM* vs OMAP*, etc), but there _has_ >> to be some sort of consistency or you might just as well assign a >> random string as name. >> >> So, if you can't come up with a reasonable, rational and >> consistent naming scheme (which, apparantly, you can't since your >> marketing guys are in control of this and they don't get it right), >> then at least prefix with a common string for the platform. That's >> all I'm asking. >> >> >> -Olof > > I'm not sure get why the insanity of naming impacts anything, those > people that care about the platforms know what names mean what. Plus > we have this same set of having to be in the know for other SoC > already. Freescale does this all the time in PPC land, they just do > it with numbers and not prefixes. > > I suggested doing a qcom/ dir, as it addresses your concern, of > putting all of our mess in one place. Just because every other > SoC/mach/plat hasn't done that should stop us from at least doing it > for qcom. > As Stephen W has pointed out previously, the dtb filename itself is or may be an ABI and the bootloader may be hardcoded to a name. So we should avoid future renames. Rob
On Thu, Sep 12, 2013 at 11:20 AM, Rob Herring <robherring2@gmail.com> wrote: > As Stephen W has pointed out previously, the dtb filename itself is or > may be an ABI and the bootloader may be hardcoded to a name. So we > should avoid future renames. We still have the choice of producing the dtb files under arch/arm/boot/dts even if we move dts/dtsi files one level deeper, as long as we keep the filenames consistent. So we can do a move, just not a rename. -Olof
On Sep 12, 2013, at 1:46 PM, Olof Johansson wrote: > On Thu, Sep 12, 2013 at 11:20 AM, Rob Herring <robherring2@gmail.com> wrote: > >> As Stephen W has pointed out previously, the dtb filename itself is or >> may be an ABI and the bootloader may be hardcoded to a name. So we >> should avoid future renames. > > We still have the choice of producing the dtb files under > arch/arm/boot/dts even if we move dts/dtsi files one level deeper, as > long as we keep the filenames consistent. So we can do a move, just > not a rename. Looking at arch/arm/boot/dts/ we are all over the place, so what's the naming convention we are going forward with? - k
On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote: > >On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: >> My original request to please use a common prefix for your product >> families stands. Please prefix with msm-*, or if you have to, qcom-* >> instead, since you guys can't seem to make your mind up on standard >> prefixes (msm, apq, etc). > >This is silly, I dont see the reason to go with >qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we >mostly likely shift to a dir structure. As engineers we are all too >aware of the lack of sanity in marketing names, but its what we have >so we have to live with it. At least what we'd decided a year or two ago was to call _everything_ with an msm* prefix. If marketing comes up with cute prefixes for things, we would basically ignore them. So, under that, it should be an msm8074-dragonboard. Admittedly, it might be a little confusing with the name of the product having the apq in it, but as others have pointed out, I think there is less confusing than not having a common prefix on our MSM products. At least so far, there are no chips where apq vs msm actually distinguishes anything. In fact, a simple "decoder ring" would point out that the 'apq' usually corresponds with the second digit being a zero. It doesn't help that we've added an 'mpq' prefix as well. I don't really see how to satisfy all of this other than qcom-apq*, or just continue to use msm*. David
On Sep 12, 2013, at 5:47 PM, David Brown wrote: > On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote: >> >> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: > >>> My original request to please use a common prefix for your product >>> families stands. Please prefix with msm-*, or if you have to, qcom-* >>> instead, since you guys can't seem to make your mind up on standard >>> prefixes (msm, apq, etc). >> >> This is silly, I dont see the reason to go with >> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we >> mostly likely shift to a dir structure. As engineers we are all too >> aware of the lack of sanity in marketing names, but its what we have >> so we have to live with it. > > At least what we'd decided a year or two ago was to call _everything_ > with an msm* prefix. If marketing comes up with cute prefixes for > things, we would basically ignore them. So, under that, it should be > an msm8074-dragonboard. Admittedly, it might be a little confusing > with the name of the product having the apq in it, but as others have > pointed out, I think there is less confusing than not having a common > prefix on our MSM products. > > At least so far, there are no chips where apq vs msm actually > distinguishes anything. In fact, a simple "decoder ring" would point > out that the 'apq' usually corresponds with the second digit being a > zero. It doesn't help that we've added an 'mpq' prefix as well. > > I don't really see how to satisfy all of this other than qcom-apq*, or > just continue to use msm*. I think msm has run out of steam, especially as more SoCs come out of Qualcomm that aren't just targeting phones & tablets. - k
On 9/12/2013 7:05 PM, Kumar Gala wrote: > On Sep 12, 2013, at 5:47 PM, David Brown wrote: > >> On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote: >>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: >>>> My original request to please use a common prefix for your product >>>> families stands. Please prefix with msm-*, or if you have to, qcom-* >>>> instead, since you guys can't seem to make your mind up on standard >>>> prefixes (msm, apq, etc). >>> This is silly, I dont see the reason to go with >>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we >>> mostly likely shift to a dir structure. As engineers we are all too >>> aware of the lack of sanity in marketing names, but its what we have >>> so we have to live with it. >> At least what we'd decided a year or two ago was to call _everything_ >> with an msm* prefix. If marketing comes up with cute prefixes for >> things, we would basically ignore them. So, under that, it should be >> an msm8074-dragonboard. Admittedly, it might be a little confusing >> with the name of the product having the apq in it, but as others have >> pointed out, I think there is less confusing than not having a common >> prefix on our MSM products. >> >> At least so far, there are no chips where apq vs msm actually >> distinguishes anything. In fact, a simple "decoder ring" would point >> out that the 'apq' usually corresponds with the second digit being a >> zero. It doesn't help that we've added an 'mpq' prefix as well. >> >> I don't really see how to satisfy all of this other than qcom-apq*, or >> just continue to use msm*. I think going ahead with what David mentioned for msm* works if we can be consistent or if we want to explicitly mention apq in the file name, then we can rename them to be qcom-msm* or qcom-apq* if people care about the differences between them. > > I think msm has run out of steam, especially as more SoCs come out of Qualcomm that aren't just targeting phones & tablets. > > - k > Thanks, Rohit Vaswani
On Sep 16, 2013, at 1:28 PM, Rohit Vaswani wrote: > On 9/12/2013 7:05 PM, Kumar Gala wrote: >> On Sep 12, 2013, at 5:47 PM, David Brown wrote: >> >>> On Thu, Sep 12, 2013 at 12:55:36PM -0500, Kumar Gala wrote: >>>> On Sep 12, 2013, at 12:06 PM, Olof Johansson wrote: >>>>> My original request to please use a common prefix for your product >>>>> families stands. Please prefix with msm-*, or if you have to, qcom-* >>>>> instead, since you guys can't seem to make your mind up on standard >>>>> prefixes (msm, apq, etc). >>>> This is silly, I dont see the reason to go with >>>> qcom-apq<SOC>-<BOARD>.dts and than in the future drop qcom- when we >>>> mostly likely shift to a dir structure. As engineers we are all too >>>> aware of the lack of sanity in marketing names, but its what we have >>>> so we have to live with it. >>> At least what we'd decided a year or two ago was to call _everything_ >>> with an msm* prefix. If marketing comes up with cute prefixes for >>> things, we would basically ignore them. So, under that, it should be >>> an msm8074-dragonboard. Admittedly, it might be a little confusing >>> with the name of the product having the apq in it, but as others have >>> pointed out, I think there is less confusing than not having a common >>> prefix on our MSM products. >>> >>> At least so far, there are no chips where apq vs msm actually >>> distinguishes anything. In fact, a simple "decoder ring" would point >>> out that the 'apq' usually corresponds with the second digit being a >>> zero. It doesn't help that we've added an 'mpq' prefix as well. >>> >>> I don't really see how to satisfy all of this other than qcom-apq*, or >>> just continue to use msm*. > > I think going ahead with what David mentioned for msm* works if we can be consistent or if we want to explicitly mention apq in the file name, then > we can rename them to be qcom-msm* or qcom-apq* if people care about the differences between them. > >> >> I think msm has run out of steam, especially as more SoCs come out of Qualcomm that aren't just targeting phones & tablets. >> >> - k I think the two options are either: qcom-msm*, qcom-apq*, etc or qcom/msm-*, qcom/apq*, etc I'm guessing we'll end up without the dir and in the future have: qcom/qcom-msm-*, qcom/qcom-apq-* Olof??? - k
On Mon, Sep 16, 2013 at 11:46 AM, Kumar Gala <galak@codeaurora.org> wrote: > I think the two options are either: > > qcom-msm*, qcom-apq*, etc > > or > > qcom/msm-*, qcom/apq*, etc > > I'm guessing we'll end up without the dir and in the future have: > > qcom/qcom-msm-*, qcom/qcom-apq-* > > Olof??? When you create the dir, you can go from qcom-msm-* to qcom/msm-*, but still produce qcom-msm-*.dtb as the build output. We care about keeping the DTB name stable, not DTS. As long as they just conform to those two patterns it's easy to handle through makefile targets. -Olof
On Sep 16, 2013, at 1:50 PM, Olof Johansson wrote: > On Mon, Sep 16, 2013 at 11:46 AM, Kumar Gala <galak@codeaurora.org> wrote: > >> I think the two options are either: >> >> qcom-msm*, qcom-apq*, etc >> >> or >> >> qcom/msm-*, qcom/apq*, etc >> >> I'm guessing we'll end up without the dir and in the future have: >> >> qcom/qcom-msm-*, qcom/qcom-apq-* >> >> Olof??? > > > When you create the dir, you can go from qcom-msm-* to qcom/msm-*, but > still produce qcom-msm-*.dtb as the build output. We care about > keeping the DTB name stable, not DTS. As long as they just conform to > those two patterns it's easy to handle through makefile targets. Sounds good, Rohit let's go ahead with qcom-msm-*, qcom-apq-*. - k
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index cc0f1fb..d784ba0 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -101,8 +101,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \ kirkwood-ts219-6282.dtb \ kirkwood-openblocks_a6.dtb dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb -dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \ - msm8960-cdp.dtb +dtb-$(CONFIG_ARCH_MSM) += qcom/msm8660-surf.dtb \ + qcom/msm8960-cdp.dtb dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ armada-370-mirabox.dtb \ armada-370-netgear-rn102.dtb \ diff --git a/arch/arm/boot/dts/msm8660-surf.dts b/arch/arm/boot/dts/qcom/msm8660-surf.dts similarity index 97% rename from arch/arm/boot/dts/msm8660-surf.dts rename to arch/arm/boot/dts/qcom/msm8660-surf.dts index 386d428..8c5ea9a 100644 --- a/arch/arm/boot/dts/msm8660-surf.dts +++ b/arch/arm/boot/dts/qcom/msm8660-surf.dts @@ -1,6 +1,6 @@ /dts-v1/; -/include/ "skeleton.dtsi" +/include/ "../skeleton.dtsi" / { model = "Qualcomm MSM8660 SURF"; diff --git a/arch/arm/boot/dts/msm8960-cdp.dts b/arch/arm/boot/dts/qcom/msm8960-cdp.dts similarity index 97% rename from arch/arm/boot/dts/msm8960-cdp.dts rename to arch/arm/boot/dts/qcom/msm8960-cdp.dts index 93e9f7e..fe2659a 100644 --- a/arch/arm/boot/dts/msm8960-cdp.dts +++ b/arch/arm/boot/dts/qcom/msm8960-cdp.dts @@ -1,6 +1,6 @@ /dts-v1/; -/include/ "skeleton.dtsi" +/include/ "../skeleton.dtsi" / { model = "Qualcomm MSM8960 CDP";
Use the Qualcomm vendor prefix (qcom) as the directory name for Qualcomm MSM devicetrees going forward. Signed-off-by: Kumar Gala <galak@codeaurora.org> --- arch/arm/boot/dts/Makefile | 4 ++-- arch/arm/boot/dts/{ => qcom}/msm8660-surf.dts | 2 +- arch/arm/boot/dts/{ => qcom}/msm8960-cdp.dts | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) rename arch/arm/boot/dts/{ => qcom}/msm8660-surf.dts (97%) rename arch/arm/boot/dts/{ => qcom}/msm8960-cdp.dts (97%)