Re: [PATCH 00/20] arm64: add Synaptics SL261X SoCs and RDK boards

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

On Wed, Sep 30, 2026 at 10:32:11PM +0800, Jisheng Zhang wrote:
> On Tue, Sep 29, 2026 at 08:38:52PM +0100, Conor Dooley wrote:
> > On Tue, Sep 29, 2026 at 02:13:57PM +0800, Jisheng Zhang wrote:
> > > Add initial support for the Synaptics SL261X SoCs and corresponding
> > > RDK boards.
> > > 
> > > The SL261X SoCs include five pin-to-pin compatible SoCs: SL2611, SL2613,
> > > SL2615, SL2617, and SL2619.
> > > 
> > > Only reset, pinctrl, clk/pll, uart, gpio, i2c, spi, i3c are included in
> > > this series. The support for Ethernet, USB, SDHCI, CAN, DMAC, XSPI will
> > > be submitted after this series is merged.
> > 
> > This series is filled with wildcard compatibles, which we don't permit
> > typically. The only case for SoCs that I've seen them accepted is when
> > the devices covered are actually just different binnings of the same
> > device. I took a look at the docs for this device, but it wasn't clear
> > to me if these are actually binnings or if there are different
> > integrations here. If they're binnings, I'd rather you used 0 as the
> > final digit, rather than x, since that matches the synaptics
> > documentation for the family. If they're not binnings, there's no
> > guarantee that they share the same errata etc, and must have different
> > compatibles.
> 
> BTW: May I query a qustion?
> After searching the maillist archieves, it seems now maintainers prefer
> spiliting this kind of SoC initial support series into separate patches
> for different subsystems, e.g uart, i2c, i3c, spi and so on, then the
> SoC pinctrl, clk, reset and dtsi/dts files, but AIUI, there will be
> dtb check failures with the SoC dts(i) files patch(es), what's
> the normal solution then?

Depends on the type of failure, but yes it can be okay. If the failure is
some missing schema causing validation to fail, that's fine as long as it
passes in linux-next (same as when you add a new driver and binding, but
the dts goes to a different branch). What's not acceptable is breaking the
build because some header that provides clock defines is missing in the dts
branch or in the driver branch. In that case, either send all that stuff in
one "New SoC" PR to the soc tree, or put the binding headers in a shared
tag that is the basis for your PR to the relevant maintainers (typically
clock) and the dts PR to the soc tree.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]