Re: [PATCH 1/3] ARM: dts: add Raspberry Pi Compute Module 3 and IO board

[Greg KH <greg@kroah.com>]

On Wed, Jul 17, 2019 at 04:04:59AM +0200, Cyril Brulebois wrote:
> 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?

I don't think that anyone has made that same mistake in the past 5+
years that I can recall at the moment, so adding more text to the file
probably will not really save us many issues like this :)

thanks,

greg k-h