Received-SPF: pass (google.com: domain of linux-kernel+bounces-90968-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 4 Mar 2024 10:56:35 -0600
From: Rob Herring <robh@kernel.org>
To: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
	Mark Brown <broonie@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	andi.shyti@kernel.org, conor+dt@kernel.org,
	linux-spi@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	andre.draszik@linaro.org, peter.griffin@linaro.org,
	willmcvicker@google.com, kernel-team@android.com
Subject: Re: [PATCH] spi: dt-bindings: samsung: make dma properties not
 required
Message-ID: <20240304165635.GA739022-robh@kernel.org>
References: <20240301115546.2266676-1-tudor.ambarus@linaro.org>
 <CAPLW+4=6oYcs0NPXo4ffLiCvtNQ-tY1s_isaxTX8dcPkV56xMw@mail.gmail.com>
 <cb426fb0-2f27-4c9b-89f5-7139354ea425@sirena.org.uk>
 <f06328e4-b283-4302-b9c1-6473aa3cfa25@linaro.org>
 <CAPLW+4kjXK=EWx__h0bX0rJMrL33E=t4YDzSOfObmvtG9aS+jg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAPLW+4kjXK=EWx__h0bX0rJMrL33E=t4YDzSOfObmvtG9aS+jg@mail.gmail.com>

On Sat, Mar 02, 2024 at 10:23:16AM -0600, Sam Protsenko wrote:
> On Sat, Mar 2, 2024 at 3:36 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >
> >
> >
> > On 01.03.2024 22:42, Mark Brown wrote:
> > > On Fri, Mar 01, 2024 at 01:28:35PM -0600, Sam Protsenko wrote:
> > >> On Fri, Mar 1, 2024 at 5:55 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> > >
> > >>> Since the addition of the driver in 2009, the driver selects between DMA
> > >>> and polling mode depending on the transfer length - DMA mode for
> > >>> transfers bigger than the FIFO depth, polling mode otherwise. All
> > >>> versions of the IP support polling mode, make the dma properties not
> > >>> required.
> > >
> > >> AFAIU, the device tree has nothing to do with drivers, it's about
> > >> hardware description. Does making DMA properties not required here
> >
> > correct
> >
> > >> mean that there are some HW out there which doesn't integrate DMA in
> >
> > no, to me it means that the IP can work without DMA, only in PIO mode,
> > regardless if DMA is integrated or not. Not required means that the
> > property is not mandatory, which is what I'm trying to achieve here.
> >
> > >> SPI blocks? Even if this change is ok (I'm not sure), the
> > >> argumentation doesn't look sound to me.
> >
> > switching to PIO mode in the driver for sizes smaller than FIFO depths
> > in the driver guarantees that all existing compatibles support PIO mode.
> >
> > Are you saying that if there is a physical line between an IP and DMA
> > controller, then the DMA properties must always be specified in dt? I
> > thought they can be marked as optional in this case, and that's what I
> > did with this patch.
> >
> 
> No, I would wait for maintainers to clarify on that bit. Change itself
> can be ok. But the commit message shouldn't mention the driver,
> because the driver uses (depends on) device tree, not vice versa. The
> device tree can be used in other projects as well (like U-Boot and
> OP-TEE), so it should be designed to be universal and not depend on
> kernel drivers. The commit message should be based on particular HW
> layout features and how the patch makes the bindings describe that HW
> better. It shouldn't rely on driver implementations.

If the controller is DMA capable then it should have dma properties. The 
compatible should be enough to tell if it is a case of 'can only work 
with DMA'. Otherwise, it is going to be up to a specific user. Even 
within Linux, you may have a serial port that doesn't use DMA for the 
console, but uses it for the tty or serdev.

Of course, if a new device is added without DMA properties and they 
are added later on, then they are going to be optional even though the 
DMA support is always there. I can't fully understand everyone's h/w. 

Rob