Hi Greg, Stefan, Greg KH <greg@xxxxxxxxx> (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@xxxxxxxx> > > > > > > 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, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
