[PATCH 00/11] Cortina Systems CS75xx: interrupt controller, GPIO, I2C and TWD watchdog

[Conor Dooley]

On Tue, Oct 13, 2026 at 10:10:22AM +0300, Fil Dunsky wrote:
> Hi Conor,
> 
> Sorry for the late reply, and for sending v2 and v3 without addressing
> this - I missed your mail.
> 
> On Mon, Oct 12, 2026 at 07:48:00PM +0100, Conor Dooley wrote:
> > I think what's here looks really suspect - regions of two registers
> > wide, interlaced between devices etc.
> > You mention syscons here, and really that's where I think that this
> > should go. The region at 0xf007_0000 looks exactly like a syscon to me
> > and should be modelled as one.
> 
> Understood. The block at 0xf007_0000 is the "peripheral" register block
> of the vendor kernel: the interrupt status/enable pairs, the UARTs, GPIO
> banks, the I2C (BIW), SPI, MDIO and timer registers are all packed into
> it. Would you be fine with a "cortina,cs7542-peripheral", "syscon",
> "simple-mfd" node covering it, with the interrupt controller as a child
> node without its own reg that gets a regmap from the parent? The UART,
> GPIO and I2C nodes would stay separate devices with their own reg, as
> you suggest below.

If things are just tightly packed, that's fine and you don't need to
make it a syscon. Just because something looks suspect doesn't mean that
it is actually wrong.

In your shoes, I think what I would do is leave i2c/interrupt
controller/gpios etc all as independent nodes.

I would however model the pinctrl as a single node, with
reg = <0xf000001c 0x14>
I think, rather than 5 instances 0x4 wide.

> 
> > I think it's fine to make a GPIO controller at this point, and leave
> > pinctrl to later, but I don't think that it is acceptable to pretend
> > that the mux registers are part of the GPIO controller. The pinctrl-less
> > GPIO controller would have to either rely on something else (e.g.
> > firmware) setting the mux registers or be not entirely functional until
> > the pinctrl arrives
> 
> Agreed. The next version drops the mux register from the GPIO binding
> and driver and relies on the boot loader's pin mux. A line that the
> boot loader leaves muxed to a peripheral then stays unusable as a GPIO
> until the pin controller exists; I will check which of the Almond+
> lines (reset button, touchscreen interrupt) that affects before
> sending, and leave those out of the dts if needed.
> 
> I will not send it before the interrupt controller question is settled,
> and not before 48 hours have passed in any case.

My take would probably be not sending new versions until at least 48h
has passed since the last reply on the current version, rather than 48h
or w/e from time of posting. Of course, exceptions apply, and you can
use common sense to guide you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20261013/ec9780b2/attachment.sig>