linux-kernel - Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <35211759.Jca4RWVLIS@wuerfel>
Date:	Tue, 29 Sep 2015 13:17:20 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Peter Griffin <peter.griffin@...aro.org>,
	Lee Jones <lee.jones@...aro.org>, devicetree@...r.kernel.org,
	vinod.koul@...el.com, srinivas.kandagatla@...il.com,
	patrice.chotard@...com, linux-kernel@...r.kernel.org,
	robh+dt@...nel.org, Ludovic Barre <ludovic.barre@...com>,
	dmaengine@...r.kernel.org, maxime.coquelin@...com
Subject: Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote:
> 
> "The hardware is identical, and different firmware is used to apply
>    it in different ways."
> 
> Which is the case with fdma. By encoding the "way you wish to apply it" into the
> compatible string, it causes problems if you want to change for example fdma0
> to do some other function other than audio.
> 
> You then require a DT update, (when the hardware hasn't changed, just the
> firmware) which is the same problem as using the filename directly in DT.
> 
> Therefore I believe it is important that the DT binding does *not* encode the
> way the hardware is to be applied into the binding in *any* way, and defers this
>  decision to the driver.
> That is the rationale / reasoning behind choosing the fdma instance number.
> 
> Assuming you agree with my arguments above, then the choice becomes between 
> having a fdma instance DT property, or having lots of compatibles where the only
> difference is the appending of the instance number. I think out of the two I prefer
> my original approach.
> 
> Any thoughts from the DT folks?

To me both approaches sound wrong: basing the firmware name on the instance
number requires that each instance is always used in the same way, which
is not guaranteed to be the case, and you correctly describe the problem with
using the compatible string for the firmware name if the driver for the FDMA
does not actually care what firmware is being used here.

Whatever code makes the decision as to how the FDMA is used should also
decide on the name of the firmware file. You can have a mapping in the
driver that contains the file names that are used by ST's distro, possibly
with a fallback mechanism that tries more meaningful names first.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/