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: <20150929100440.GC16955@griffinp-ThinkPad-X1-Carbon-2nd>
Date:	Tue, 29 Sep 2015 11:04:40 +0100
From:	Peter Griffin <peter.griffin@...aro.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	srinivas.kandagatla@...il.com, maxime.coquelin@...com,
	patrice.chotard@...com, vinod.koul@...el.com,
	devicetree@...r.kernel.org, robh+dt@...nel.org,
	dmaengine@...r.kernel.org, Ludovic Barre <ludovic.barre@...com>
Subject: Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA
 DT binding documentation

Hi Lee,

On Mon, 14 Sep 2015, Lee Jones wrote:

> > On Fri, 11 Sep 2015, Arnd Bergmann wrote:
> > 
> > > On Friday 11 September 2015 15:14:23 Peter Griffin wrote:
> > > > +- st,fdma-id	: Must contain fdma controller number
> > > 
> > > What for?
> > 
> > It is used by the driver to generate a unique firmware name.
> > Basically we need to know which controller instance we
> > are as each controller has a different firmware which needs
> > to be loaded.
> > 
> > Rob did say that having a index type property is undesirable
> > over here, see my reply at the bottom
> > http://www.spinics.net/lists/devicetree/msg92529.html.
> > 
> > However I can't think of any other useful properties we could add
> > to derive this information.
> 
> I wouldn't use a property at all.  Why not use the compatible string?
> 
> Who chooses the naming scheme of the firmware binary?

ST

> 
> Is there any reason they can't be:
> 
>   fdma_STiH407_audio.elf
>   fdma_STiH407_app.elf
>   fdma_STiH407_free_running.elf

Not sure, we could easily rename them locally. Getting ST to change
the firmware names in the stlinux distro might be harder.
My personal preference is to leave the firmware names "as is", unless
there is a real show stopper reason where we *have* to change them e.g.
we can't support all STi platforms with the same userspace because
the firmware filenames aren't unique enough.

> 
> Then you can have a different compatible for each:
> 
>   compatible = "st,stih407-fdma-mpe31-audio";
>   compatible = "st,stih407-fdma-mpe31-app";
>   compatible = "st,stih407-fdma-mpe31-free-running";

I think if you took the approach of only using the compatible
you would still need to use the fdma instance number
otherwise you end up with the same problems discussed in the 
"Firmware filename in DT" thread [1] e.g.

   compatible = "st,stih407-fdma-mpe31-0";
   compatible = "st,stih407-fdma-mpe31-1";
   compatible = "st,stih407-fdma-mpe31-2";

Specifically the problem is related to

"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?

regards,

Peter.

[1] http://comments.gmane.org/gmane.linux.drivers.devicetree/133782
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ