diff mbox

[17/25] serial: sh-sci: Correct SCIF type on R-Car for BRG

Message ID 1447958344-836-18-git-send-email-geert+renesas@glider.be (mailing list archive)
State Superseded
Delegated to: Geert Uytterhoeven
Headers show

Commit Message

Geert Uytterhoeven Nov. 19, 2015, 6:38 p.m. UTC
The "renesas,scif" compatible value is currently used for the SCIF
variant in all Renesas SoCs of the R-Car family.  However, the variant
used in the R-Car family is not the common "SH-4(A)" variant, but a
derivative with added "Baud Rate Generator for External Clock" (BRG),
which is also present in sh7734.

Use the (already documented) SoC-specific SCIF compatible values for all
supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate.  The
"renesas,scif" compatible value can still be used as a common
denominator for SCIF variants with the "SH-4(A)" register layout (i.e.
ignoring the "Serial Extension Mode Register" (SCEMR) and the new
BRG-specific registers).

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Comments

Laurent Pinchart Nov. 19, 2015, 8:55 p.m. UTC | #1
Hi Geert,

Thank you for the patch.

On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> The "renesas,scif" compatible value is currently used for the SCIF
> variant in all Renesas SoCs of the R-Car family.  However, the variant
> used in the R-Car family is not the common "SH-4(A)" variant, but a
> derivative with added "Baud Rate Generator for External Clock" (BRG),
> which is also present in sh7734.

Time to introduce a "renesas,scif-rcar" compatible string ? ;-)

As the only DT-enabled platform to have a different SCIF type is r7s72100 we 
could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE 
for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh 
though, but even if that happens due to the J-Core processors I'd be surprised 
to see the old Renesas SH platforms being moved to DT.

> Use the (already documented) SoC-specific SCIF compatible values for all
> supported R-Car Gen1, Gen2, and Gen3 SoCs to differentiate.  The
> "renesas,scif" compatible value can still be used as a common
> denominator for SCIF variants with the "SH-4(A)" register layout (i.e.
> ignoring the "Serial Extension Mode Register" (SCEMR) and the new
> BRG-specific registers).
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/tty/serial/sh-sci.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index b0127f38af744fcf..726c96d5a511c222 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2605,6 +2605,30 @@ static const struct of_device_id of_sci_match[] = {
>  	{
>  		.compatible = "renesas,scif-r7s72100",
>  		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7778",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7779",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7790",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7791",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7792",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7793",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7794",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> +	}, {
> +		.compatible = "renesas,scif-r8a7795",
> +		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
>  	},
>  	/* Generic types */
>  	{
Geert Uytterhoeven Nov. 20, 2015, 7:46 a.m. UTC | #2
Hi Laurent,

On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> The "renesas,scif" compatible value is currently used for the SCIF
>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> which is also present in sh7734.
>
> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>
> As the only DT-enabled platform to have a different SCIF type is r7s72100 we
> could also consider just switching the regtype to SCIx_SH4_SCIF_BRG_REGTYPE
> for the generic "renesas,scif" entry as it's listed after the "renesas,scif-
> r7s72100" entry. That might cause an issue if we want to enable DT on arch/sh
> though, but even if that happens due to the J-Core processors I'd be surprised
> to see the old Renesas SH platforms being moved to DT.

I thought about that, but you never know in which out-of-tree BSP it ended up
being used, too. So better safe than sorry.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Laurent Pinchart Nov. 20, 2015, 2:52 p.m. UTC | #3
Hi Geert,

On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >> The "renesas,scif" compatible value is currently used for the SCIF
> >> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >> which is also present in sh7734.
> > 
> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> > 
> > As the only DT-enabled platform to have a different SCIF type is r7s72100
> > we could also consider just switching the regtype to
> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> > listed after the "renesas,scif- r7s72100" entry. That might cause an
> > issue if we want to enable DT on arch/sh though, but even if that happens
> > due to the J-Core processors I'd be surprised to see the old Renesas SH
> > platforms being moved to DT.
> 
> I thought about that, but you never know in which out-of-tree BSP it ended
> up being used, too. So better safe than sorry.

Out-of-tree should be banned :-)

More seriously, I suppose you wouldn't be thrilled by the idea of a 
"renesas,scif-rcar-gen2" ?
Geert Uytterhoeven Nov. 20, 2015, 3:30 p.m. UTC | #4
Hi Laurent,

On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
>> > On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> >> The "renesas,scif" compatible value is currently used for the SCIF
>> >> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> >> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> >> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> >> which is also present in sh7734.
>> >
>> > Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>> >
>> > As the only DT-enabled platform to have a different SCIF type is r7s72100
>> > we could also consider just switching the regtype to
>> > SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
>> > listed after the "renesas,scif- r7s72100" entry. That might cause an
>> > issue if we want to enable DT on arch/sh though, but even if that happens
>> > due to the J-Core processors I'd be surprised to see the old Renesas SH
>> > platforms being moved to DT.
>>
>> I thought about that, but you never know in which out-of-tree BSP it ended
>> up being used, too. So better safe than sorry.
>
> Out-of-tree should be banned :-)
>
> More seriously, I suppose you wouldn't be thrilled by the idea of a
> "renesas,scif-rcar-gen2" ?

Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Laurent Pinchart Nov. 20, 2015, 3:33 p.m. UTC | #5
Hi Geert,

On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >>>> The "renesas,scif" compatible value is currently used for the SCIF
> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >>>> which is also present in sh7734.
> >>> 
> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >>> 
> >>> As the only DT-enabled platform to have a different SCIF type is
> >>> r7s72100 we could also consider just switching the regtype to
> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
> >>> issue if we want to enable DT on arch/sh though, but even if that
> >>> happens due to the J-Core processors I'd be surprised to see the old
> >>> Renesas SH platforms being moved to DT.
> >> 
> >> I thought about that, but you never know in which out-of-tree BSP it
> >> ended up being used, too. So better safe than sorry.
> > 
> > Out-of-tree should be banned :-)
> > 
> > More seriously, I suppose you wouldn't be thrilled by the idea of a
> > "renesas,scif-rcar-gen2" ?
> 
> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.

Yes, but it would at least cover the whole Gen2 family that behaves the same 
way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat 
strings only.
Geert Uytterhoeven Dec. 10, 2015, 9:21 a.m. UTC | #6
On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
>> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
>> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
>> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
>> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
>> >>>> The "renesas,scif" compatible value is currently used for the SCIF
>> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
>> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
>> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
>> >>>> which is also present in sh7734.
>> >>>
>> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
>> >>>
>> >>> As the only DT-enabled platform to have a different SCIF type is
>> >>> r7s72100 we could also consider just switching the regtype to
>> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
>> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
>> >>> issue if we want to enable DT on arch/sh though, but even if that
>> >>> happens due to the J-Core processors I'd be surprised to see the old
>> >>> Renesas SH platforms being moved to DT.
>> >>
>> >> I thought about that, but you never know in which out-of-tree BSP it
>> >> ended up being used, too. So better safe than sorry.
>> >
>> > Out-of-tree should be banned :-)
>> >
>> > More seriously, I suppose you wouldn't be thrilled by the idea of a
>> > "renesas,scif-rcar-gen2" ?
>>
>> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
>
> Yes, but it would at least cover the whole Gen2 family that behaves the same
> way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat
> strings only.

In light of all the recent "add fallback compatibility strings" patch series
from Simon, perhaps I should reconsider, and just match against three (new)
family-specific compatible values:

    "renesas,scif-rcar-gen1"
    "renesas,scif-rcar-gen2"
    "renesas,scif-rcar-gen3"

instead of the 8 (and more coming) SoC-specific compatible values?

Following that scheme means we will have to add many compatible values
to the existing dtsis. I.e. every SCIx device node (there are more than 100)
will have 3, like

        scif0: serial@e6e60000 {
                compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2",
                              "renesas,scif";

Not having the SoC-specific ones in the driver won't cause an issue when using
an old DTS with a new kernel: you can't use the new BRG features without
adding the extra clocks to the DTS anyway, so you can add the family-specific
compatible value when doing that update.

Simon, what do you think?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman Dec. 11, 2015, 1:12 a.m. UTC | #7
On Thu, Dec 10, 2015 at 10:21:27AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> >> > On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >> >> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >> >>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >> >>>> The "renesas,scif" compatible value is currently used for the SCIF
> >> >>>> variant in all Renesas SoCs of the R-Car family.  However, the variant
> >> >>>> used in the R-Car family is not the common "SH-4(A)" variant, but a
> >> >>>> derivative with added "Baud Rate Generator for External Clock" (BRG),
> >> >>>> which is also present in sh7734.
> >> >>>
> >> >>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >> >>>
> >> >>> As the only DT-enabled platform to have a different SCIF type is
> >> >>> r7s72100 we could also consider just switching the regtype to
> >> >>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as it's
> >> >>> listed after the "renesas,scif- r7s72100" entry. That might cause an
> >> >>> issue if we want to enable DT on arch/sh though, but even if that
> >> >>> happens due to the J-Core processors I'd be surprised to see the old
> >> >>> Renesas SH platforms being moved to DT.
> >> >>
> >> >> I thought about that, but you never know in which out-of-tree BSP it
> >> >> ended up being used, too. So better safe than sorry.
> >> >
> >> > Out-of-tree should be banned :-)
> >> >
> >> > More seriously, I suppose you wouldn't be thrilled by the idea of a
> >> > "renesas,scif-rcar-gen2" ?
> >>
> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
> >
> > Yes, but it would at least cover the whole Gen2 family that behaves the same
> > way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's two compat
> > strings only.
> 
> In light of all the recent "add fallback compatibility strings" patch series
> from Simon, perhaps I should reconsider, and just match against three (new)
> family-specific compatible values:
> 
>     "renesas,scif-rcar-gen1"
>     "renesas,scif-rcar-gen2"
>     "renesas,scif-rcar-gen3"
> 
> instead of the 8 (and more coming) SoC-specific compatible values?
> 
> Following that scheme means we will have to add many compatible values
> to the existing dtsis. I.e. every SCIx device node (there are more than 100)
> will have 3, like
> 
>         scif0: serial@e6e60000 {
>                 compatible = "renesas,scif-r8a7791", "renesas,scif-rcar-gen2",
>                               "renesas,scif";
> 
> Not having the SoC-specific ones in the driver won't cause an issue when using
> an old DTS with a new kernel: you can't use the new BRG features without
> adding the extra clocks to the DTS anyway, so you can add the family-specific
> compatible value when doing that update.
> 
> Simon, what do you think?

This sounds good to me.
In fact it sounds like the kind of upgrade path that I would like
to see in action.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Laurent Pinchart Dec. 13, 2015, 7:18 p.m. UTC | #8
Hi Geert,

On Thursday 10 December 2015 10:21:27 Geert Uytterhoeven wrote:
> On Fri, Nov 20, 2015 at 4:33 PM, Laurent Pinchart wrote:
> > On Friday 20 November 2015 16:30:22 Geert Uytterhoeven wrote:
> >> On Fri, Nov 20, 2015 at 3:52 PM, Laurent Pinchart wrote:
> >>> On Friday 20 November 2015 08:46:56 Geert Uytterhoeven wrote:
> >>>> On Thu, Nov 19, 2015 at 9:55 PM, Laurent Pinchart wrote:
> >>>>> On Thursday 19 November 2015 19:38:56 Geert Uytterhoeven wrote:
> >>>>>> The "renesas,scif" compatible value is currently used for the SCIF
> >>>>>> variant in all Renesas SoCs of the R-Car family.  However, the
> >>>>>> variant used in the R-Car family is not the common "SH-4(A)"
> >>>>>> variant, but a derivative with added "Baud Rate Generator for
> >>>>>> External Clock" (BRG), which is also present in sh7734.
> >>>>> 
> >>>>> Time to introduce a "renesas,scif-rcar" compatible string ? ;-)
> >>>>> 
> >>>>> As the only DT-enabled platform to have a different SCIF type is
> >>>>> r7s72100 we could also consider just switching the regtype to
> >>>>> SCIx_SH4_SCIF_BRG_REGTYPE for the generic "renesas,scif" entry as
> >>>>> it's listed after the "renesas,scif- r7s72100" entry. That might
> >>>>> cause an issue if we want to enable DT on arch/sh though, but even if
> >>>>> that happens due to the J-Core processors I'd be surprised to see the
> >>>>> old Renesas SH platforms being moved to DT.
> >>>> 
> >>>> I thought about that, but you never know in which out-of-tree BSP it
> >>>> ended up being used, too. So better safe than sorry.
> >>> 
> >>> Out-of-tree should be banned :-)
> >>> 
> >>> More seriously, I suppose you wouldn't be thrilled by the idea of a
> >>> "renesas,scif-rcar-gen2" ?
> >> 
> >> Nope. Note that it's also used in R-Car Gen 1 and Gen 3, and sh7734.
> > 
> > Yes, but it would at least cover the whole Gen2 family that behaves the
> > same way. And wouldn't preclude adding "renesas,scif-rcar-gen1". That's
> > two compat strings only.
> 
> In light of all the recent "add fallback compatibility strings" patch series
> from Simon, perhaps I should reconsider, and just match against three (new)
> family-specific compatible values:
> 
>     "renesas,scif-rcar-gen1"
>     "renesas,scif-rcar-gen2"
>     "renesas,scif-rcar-gen3"
> 
> instead of the 8 (and more coming) SoC-specific compatible values?
> 
> Following that scheme means we will have to add many compatible values
> to the existing dtsis. I.e. every SCIx device node (there are more than 100)
> will have 3, like
> 
>         scif0: serial@e6e60000 {
>                 compatible = "renesas,scif-r8a7791",
> "renesas,scif-rcar-gen2", "renesas,scif";
> 
> Not having the SoC-specific ones in the driver won't cause an issue when
> using an old DTS with a new kernel: you can't use the new BRG features
> without adding the extra clocks to the DTS anyway, so you can add the
> family-specific compatible value when doing that update.
> 
> Simon, what do you think?

Needless to say I agree :-)
diff mbox

Patch

diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index b0127f38af744fcf..726c96d5a511c222 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2605,6 +2605,30 @@  static const struct of_device_id of_sci_match[] = {
 	{
 		.compatible = "renesas,scif-r7s72100",
 		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH2_SCIF_FIFODATA_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7778",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7779",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7790",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7791",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7792",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7793",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7794",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
+	}, {
+		.compatible = "renesas,scif-r8a7795",
+		.data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
 	},
 	/* Generic types */
 	{