[RESEND RFC V2] devicetree: Dialog Semiconductor consolidate existing vendor prefixes to standardise on 'dlg'

[horms@verge.net.au (Simon Horman)]

On Wed, Jul 30, 2014 at 11:05:01AM +0000, Opensource [Steve Twiss] wrote:
> 
> On 30 July 2014 03:37 Simon Horman wrote:
> >On Mon, Jul 28, 2014 at 09:53:56AM +0000, Opensource [Steve Twiss] wrote:
> >> On 25 July 2014 08:00, Lee Jones wrote:
> >>
> >> >On Thu, 24 Jul 2014, Opensource [Steve Twiss] wrote:
> >> >> From: Steve Twiss <stwiss.opensource@diasemi.com>
> >> >>
> >> >> This patch series updates the device tree vendor prefix for
> >> >> Dialog Semiconductor.
> >> >>
> >> >> Various methods are currently used throughout the kernel: 'diasemi',
> >> >> 'dialog' and 'dlg'. Others have also been suggested.
> >> >>
> >> >> This patch set aims to consolidate the usage of the vendor prefix to
> >> >> use a common standard. The prefix 'dlg' is used.
> >> >>
> >> >>
> >> >> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> >> >
> >> >Didn't I Ack the MFD parts already?
> >> >
> >>
> >> Yes -- certainly.
> >>  (I should have put them in the main body of the e-mail shouldn't I ..?)
> >>
> >> I just need the SHMobile responses now.
> >> I will try to make contact with those guys this week.
> >
> >Hi Steve,
> >
> >I apologise for not noticing this earlier:
> >I am entirely unsure how I missed it.
> 
> Hi Simon,
> 
> Thank you for responding to this. No problem.
> 
> >
> >In principle I am fine with this change so long as it does not
> >introduce any backwards-compatibility problems. In particular removing
> >compatibility strings that may already be in use by DTB blobs in the wild.
> >
> >For SH Mobile it seems that Lager and Koelsch were using "diasemi,da9210"
> >which is unsupported by the driver at this time. So it seems there is no
> >backwards-compatibility problem there. I'm less sure about other aspects of
> >the patch. And I'm also less concerned about them.
> >
> >I do have a slight preference for SH Mobile changes to go through my
> >renesas tree rather than elsewhere (as part of a more global change)
> >principally to try to avoid the possibility of conflicts. The SH Mobile dts
> >files in question are often updated. And for example I notice some fuzz
> >when applying this patch on top of the next-20140729 tag of linux-next.
> 
> I have applied the patch to linux-next/next-20140729 and the patch
> program does throw some warnings,
> 
> patching file arch/arm/boot/dts/r8a7790-lager.dts
> Hunk #1 succeeded at 378 (offset 4 lines).
> patching file arch/arm/boot/dts/r8a7791-koelsch.dts
> Hunk #1 succeeded at 430 (offset 4 lines).
> 
> But when I checked the output, the patch was applied correctly.
> They are one-line changes in both cases:
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index 7853c2c..becaaab 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -378,7 +378,7 @@
>         status = "okay";
>  
>         vdd_dvfs: regulator at 68 {
> -               compatible = "diasemi,da9210";
> +               compatible = "dlg,da9210";
>                 reg = <0x68>;
>  
>                 regulator-min-microvolt = <1000000>;
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 8f36d4f..684fc44 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -430,7 +430,7 @@
>         clock-frequency = <100000>;
>  
>         vdd_dvfs: regulator at 68 {
> -               compatible = "diasemi,da9210";
> +               compatible = "dlg,da9210";
>                 reg = <0x68>;
>  
>                 regulator-min-microvolt = <1000000>;
> 
> 
> >
> >If you were to break out the SH Mobile portion of this patch I would be
> >happy to take it once the driver portion is accepted.  That said, I do see
> >that everyone else has acked the change so clearly this is not an issue
> >from their point of view. So I will not complain if you decide not to break
> >the patch up (though please note my warning about possible conflicts).
> 
> I have been trying to get Acked-by: tags for a while now, and it has taken a
> fair amount of time to get everybody's responses. For that reason and
> because the patch managed to be applied cleanly to next-20140729 (despite
> 4 line offsets) I would like to resend this patch with your Acked-by: applied
> instead of splitting up the patch into several sections and then touting
> for new Acked-by: all over again.
> 
> I realise that your DTS files are updated constantly -- I do hope this will
> not cause any problems with the merge.

Hi Steve,

thanks. I'm happy for you to proceed with the plan you outline above.
I think the risk of a non-trivial conflict is minimal.