Re: [PATCH] ARM: dts: omap3-gta04: Drop superfluous omap36xx compatible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Am 04.10.2023 um 13:03 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
> 
> On Wed, 4 Oct 2023 12:50:16 +0200
> "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx> wrote:
> 
>> Hi Andreas,
>> 
>>> Am 04.10.2023 um 08:53 schrieb Andreas Kemnade <andreas@xxxxxxxxxxxx>:
>>> 
>>> Drop omap36xx compatible as done in other omap3630 devices.
>>> This has apparently fallen through the lattice.
>>> 
>>> Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
>>> ---
>>> arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> index b6b27e93857f..3661340009e7 100644
>>> --- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> +++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> @@ -11,7 +11,7 @@
>>> 
>>> / {
>>> 	model = "OMAP3 GTA04";
>>> -	compatible = "goldelico,gta04", "ti,omap3630", "ti,omap36xx", "ti,omap3";  
>> 
>> there seem to be some more references to ti,omap36xx:
>> 
>> arch/arm/boot/dts/ti/omap/omap3-lilly-a83x.dtsi:	compatible = "incostartec,omap3-lilly-a83x", "ti,omap3630", "ti,omap36xx", "ti,omap3";
> 
> apperently all the dtsi are fallen through the lattice when handling the dts.
> 
> 
>> arch/arm/mach-omap2/board-generic.c:	"ti,omap36xx",
>> drivers/clk/ti/dpll.c:	     of_machine_is_compatible("ti,omap36xx")) &&
>> drivers/cpufreq/ti-cpufreq.c:	{ .compatible = "ti,omap36xx", .data = &omap36xx_soc_data, },
>> 
>> So are you sure that we can remove it without replacement or code fixes in dpll and cpufreq (board-generic is probably no issue)?
>> 
> see discussion of:
> 
> commit e341f338180c84cd98af3016cf5bcfde45a041fb
> Author: Andrew Davis <afd@xxxxxx>
> Date:   Thu Feb 16 09:33:38 2023 -0600
> 
>    ARM: dts: omap: Drop ti,omap36xx compatible

Ah, I wasn't aware of this.

> 
> all the places also basically check for omap36xx || omap3630.


Yes, I have checked but drivers/cpufreq/ti-cpufreq.c seems to be an
exception (unless I am missing some other patch).

Generally it could be good to remove the double checks
for omap36xx || omap3630 in code? Is this planned as well?

BR,
Nikolaus





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux