Re: [PATCH v3 16/16] ARM: marvell/dt: add crypto node to kirkwood dtsi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, May 26, 2015 at 11:10:51AM +0200, Boris Brezillon wrote:
> On Tue, 26 May 2015 09:06:29 +0000
> Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:
> 
> > On Mon, May 25, 2015 at 08:43:02PM +0200, Boris Brezillon wrote:
> > > Jason, Gregory,
> > > 
> > > On Mon, 25 May 2015 16:46:51 +0000
> > > Jason Cooper <jason@xxxxxxxxxxxxxx> wrote:
> > > 
> > > > On Mon, May 25, 2015 at 05:39:13PM +0200, Gregory CLEMENT wrote:
> > > > > Hi Boris, Arnaud,
> > > > > 
> > > > > On 22/05/2015 15:34, Boris Brezillon wrote:
> > > > > > From: Arnaud Ebalard <arno@xxxxxxxxxxxx>
> > > > > > 
> > > > > > Add crypto related nodes to kirkwood.dtsi.
> > > > > 
> > > > > Here you use a new compatible string but with an old binding
> > > > > to let the user chose between the old and the new driver. Am I right?
> > > 
> > > That was not the intention, but you're right, that's exactly what's
> > > happening here.
> > > 
> > > > 
> > > > I thought we had settled on the user choosing by module load/ which driver is
> > > > compiled in?  The DT should be describing the hardware, not which driver the
> > > > user chooses to use.
> > > 
> > > Right, but I didn't want to add new compatible strings to the old
> > > driver in the first place, neither I wanted to support the new way of
> > > defining/referencing the crypto SRAMs.
> > 
> > 
> > > ITOH, if we want to benefit from the TDMA optimization on Kirkwood SoCs,
> > > we have to add a new compatible (unlike Orion SoCs, Kirkwood ones embed
> > > a TDMA engine).
> > 
> > Ah, there's the HW difference I must have missed in my previous thousand-foot
> > overview scans :-/
> > 
> > So "marvell,orion-crypto" matches IP blocks without the TDMA engine,
> > "marvell,kirkwood-crypto" matches IP blocks *with* the TDMA engine.
> > 
> > > This leaves the following solutions:
> > >  - avoid changing the compatible in existing orion and kirkwood dtsi
> > >    files
> > 
> > no, in light of the above HW difference, it makes sense to change these.
> > 
> > >  - adding kirkwood compatible string support to the existing CESA
> > >    driver (and I think supporting the new approach to retrieve SRAM
> > >    memory region would make sense too)
> > 
> > Or, old driver matches "marvell,orion-crypto", and the new driver matches
> > either compatible string.  If dt has "marvell,kirkwood-crypto" then new driver
> > enables TDMA with the provided properties.
> > 
> > We then update the dtsi for all but orion to "marvell,kirkwood-crypto".
> > 
> > This may be what you are already doing.  If so, please ignore my rambling. ;-)
> 
> Yes, that's what I'm doing :-). But this means we're forcing kirkwood
> users to switch to the new driver, which is not really what you
> suggested in the first place.

well, I suppose I'm still clinging to the DT-as-stable-abi fantasy where
the dtb isn't locked to the kernel version.  :-P  If you're comfortable
with the change adding "marvell,kirkwood-crypto" to the old driver, then
go ahead.  It would indeed make everyone's lives easier.

thx,

Jason.


> 
> 
> -- 
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux