linux-kernel - Re: [PATCH v2 16/21] dt-bindings: spi: document support for SA8255p

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5fc36c6-6ca5-424a-b68a-f5695af00562@lunn.ch>
Date: Wed, 4 Sep 2024 23:49:29 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Nikunj Kela <quic_nkela@...cinc.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, andersson@...nel.org,
	konradybcio@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, rafael@...nel.org, viresh.kumar@...aro.org,
	herbert@...dor.apana.org.au, davem@...emloft.net,
	sudeep.holla@....com, andi.shyti@...nel.org, tglx@...utronix.de,
	will@...nel.org, robin.murphy@....com, joro@...tes.org,
	jassisinghbrar@...il.com, lee@...nel.org, linus.walleij@...aro.org,
	amitk@...nel.org, thara.gopinath@...il.com, broonie@...nel.org,
	cristian.marussi@....com, rui.zhang@...el.com, lukasz.luba@....com,
	wim@...ux-watchdog.org, linux@...ck-us.net,
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-crypto@...r.kernel.org, arm-scmi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-i2c@...r.kernel.org,
	iommu@...ts.linux.dev, linux-gpio@...r.kernel.org,
	linux-serial@...r.kernel.org, linux-spi@...r.kernel.org,
	linux-watchdog@...r.kernel.org, kernel@...cinc.com,
	quic_psodagud@...cinc.com,
	Praveen Talari <quic_ptalari@...cinc.com>
Subject: Re: [PATCH v2 16/21] dt-bindings: spi: document support for SA8255p

> Qualcomm QUPs chips have serial engines that can be configured as
> UART/I2C/SPI so QUPs changes require to be pushed in one series for all
> 3 subsystems as they all are dependent.

So leave that until later. And when you do, explicit mention why you
are cross posting to three subsystems, because the hardware is
designed like that. And suggest a way it could be merged, which
subsystem should take the lead, and the others just need to provide
Acked-by. The Maintainers might disagree, want to do it differently,
but i find it always helps to state this from the beginning, otherwise
sometimes no Maintainer take the lead role.

But this patchset appears to be much more than QUPs. You should be
able the break the rest up into smaller patchsets, one per subsystem.

	Andrew