linux-kernel - Re: [PATCH 1/3] ARM: DT: STi: Add support to B2020 revision E board.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 11 Mar 2014 13:23:10 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Maxime Coquelin <maxime.coquelin@...com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	srinivas.kandagatla@...com
Subject: Re: [PATCH 1/3] ARM: DT: STi: Add support to B2020 revision E board.

> >>>From: Srinivas Kandagatla <srinivas.kandagatla@...com>
> >>>
> >>>This patch adds support to rev E board of B2020 which has few minor
> >>>changes :
> >>>	PHY reset PIO (Change from PIO30 to PIO07)
> >>>	Power LED(Green) Control(Change from PIO47 to PIO13)
> >>
> >>I thought we decided last October to support only one revision of
> >>the b2020 board.
> >>
> >>The idea was to create an external git to provide DTS for all our
> >>boards, and only have a minimal subset in in the kernel.
> >
> >Ah, I was unaware of that conversation/decision. If that's the case we
> >can scrap this submission along with the following patch.
> 
> In fact we had the discussion together with Arnd (IIRC) on #armlinux :)

I remember discussing {cpu,machine}_is() implementations with regards
to handling quirks. I wasn't aware that this culminated in the
decision above. When it comes to things like PIO line or other key
hardware changes through revisions, I fully expect this to be
described inside a .dts file.

> The reason is we wanted to avoid flooding arch/arm/dts/ with all the
> possible combinations of board revisions.
> 
> The idea was to put in place a git repository at stlinux.com to
> provide the DTS for all the STi boards, and try to keep
> arch/arm/dts/sti* simple.

I can certainly sympathise with the reasoning, but for me fetching DTS
files from an external Git repo sounds unnecessarily tiresome. I had
thought about creating some per-vendor directories in there to
simplify the format a little, but then I guess we're back to square
one of the old arch/arm/mach-* situation.

> >JOOI, what happens if I want to boot Mainline on my revE board? It
> >won't be fully functional will it? That will be a shame. The LEDs, not
> >so much, but networking is a pretty big piece of functionality to
> >lose.
> 
> I agree this is not comfortable.
> 
> The problem is that your patch is not enough. We would need to
> create much more files, because for example, the i2c used are not
> the same between rev. C and rev. E.
> 
> It gives theses files only for b2020 support:
>   arch/arm/boot/dts/stih415-b2020.dts
>   arch/arm/boot/dts/stih416-b2020e.dts
>   arch/arm/boot/dts/stih41x-b2020e.dtsi
>   arch/arm/boot/dts/stih416-b2020.dts
>   arch/arm/boot/dts/stih41x-b2020.dtsi
>   arch/arm/boot/dts/stih41x-b2020x.dtsi

Right, but you're also talking about supporting two different SoCs
there too, so I guess that's not so bad?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/