Hi Greg, Stefan,
Greg KH greg@kroah.com (2019-07-16):
On Mon, Jul 15, 2019 at 05:26:16PM +0200, Stefan Wahren wrote:
Hi Cyril,
On 15.07.19 16:01, Cyril Brulebois wrote:
From: Stefan Wahren stefan.wahren@i2se.com
commit a54fe8a6cf66828499b121c3c39c194b43b8ed94 upstream.
The Raspberry Pi Compute Module 3 (CM3) and the Raspberry Pi Compute Module 3 Lite (CM3L) are SoMs which contains a BCM2837 processor, 1 GB RAM and a GPIO expander. The CM3 has a 4 GB eMMC, but on the CM3L the eMMC is unpopulated and it's up to the user to connect their own SD/MMC device. The dtsi file is designed to work for both modules. There is also a matching carrier board which is called Compute Module IO Board V3.
this patch series doesn't apply to the stable kernel rules.
I'm with Stefan. Cyril, how do you think this matches up with what: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html says?
First off, I'm sorry to have wasted everyone's time with this attempt at getting the DTB addition upstream'd so that other distributions/users could benefit from it as well; it's now been included downstream instead.
stable-kernel-rules has this entry that made me think this would be acceptable:
- New device IDs and quirks are also accepted.
To my non-expert eyes, a DTB looked similar to a bunch of device IDs, mapping specific hardware to the right modules and parameters. I thought that allowing device IDs to be added, mapping new HW to existing and known-to-be-working modules, was similar to what's happening with a DTB.
In hindsight, looking at say 4.9 or 4.19 (baselines for Debian kernels), I see that DTBs were fixed but never added. Maybe having an extra “(DTBs don't qualify)” in the documentation might prevent others from making the same mistake?
Cheers,