linux-kernel - Re: [PATCH 1/9] dt-bindings: ti-sysc: Update binding for timers and capabilities

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]

Date:   Wed, 20 Dec 2017 12:10:51 -0600
From:   Rob Herring <robh@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     linux-omap@...r.kernel.org, Nishanth Menon <nm@...com>,
        devicetree@...r.kernel.org, Paul Walmsley <paul@...an.com>,
        Dave Gerlach <d-gerlach@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Matthijs van Duin <matthijsvanduin@...il.com>,
        linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
        Tero Kristo <t-kristo@...com>, Mark Brown <broonie@...nel.org>,
        Sakari Ailus <sakari.ailus@....fi>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Benoît Cousson <bcousson@...libre.com>,
        Mark Rutland <mark.rutland@....com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/9] dt-bindings: ti-sysc: Update binding for timers and
 capabilities

On Sat, Dec 16, 2017 at 11:22:22AM -0800, Tony Lindgren wrote:
> * Rob Herring <robh@...nel.org> [171216 18:33]:
> > >  Optional properties:
> > >  
> > > +- ti,sysc-mask	shall contain mask of supported register bits for the
> > > +		SYSCONFIG register as documented in the Technical Reference
> > > +		Manual (TRM) for the interconnect target module
> > > +
> > > +- ti,sysc-midle	list of master idle modes supported by the interconnect
> > > +		target module as documented in the TRM for SYSCONFIG
> > > +		register MIDLEMODE bits
> > > +
> > > +- ti,sysc-sidle	list of slave idle modes supported by the interconnect
> > > +		target module as documented in the TRM for SYSCONFIG
> > > +		register SIDLEMODE bits
> > > +
> > > +- ti,sysc-delay-us	delay needed after OCP softreset before accssing
> > > +			SYSCONFIG register again
> > > +
> > > +- ti,syss-mask	optional mask of reset done status bits as described in the
> > > +		TRM for SYSSTATUS registers, typically 1 with some devices
> > > +		having separate reset done bits for children like OHCI and
> > > +		EHCI
> > > +
> > 
> > Seems like a lot of this should be implied by specific compatible 
> > strings.
> 
> Unfortunately that would still explode the permutations to almost
> one compatible per module especially for types "ti,sysc-omap2" and
> "ti,sysc-omap4". And the features and idle modes supported by the
> module are all over the place for "ti,sysc-mask", "ti,sysc-midle",
> "ti,sysc-sidle" and "ti,syss-mask"..

Okay.

> I was planning to have "ti,sysc-delay-us" only in the driver, but
> the same IP needs it set on dm814x while not on omap4 for OTG
> for example. I could add SoC specific quirks to the driver
> for that one if you prefer that instead?

No, I don't have a preference.

> I do have a patch also I'm testing to use the revision register
> value for handling further quirks, but unfortunately that
> register is not populated or updated for many modules. And it's
> only usable after the module is already configured to accessible :)
> 
> > Are the bits you've defined all of them or there's more?
> 
> That's it, with this binding I've allocated the data from dts
> for the tests I've done. So that should allow us to replace the
> static data to start with as seen with the following command:
> 
> $ git grep -A10 "struct omap_hwmod_class_sysconfig" \
> 	arch/arm/*hwmod*data*.c
> ...
> 
> So that's to configure a big pile of different module
> configurations we currently have as can be seen with:
> 
> $ git grep "struct omap_hwmod_class_sysconfig" \
> 	arch/arm/*hwmod*data*.c | wc -l
> 194
> 
> I'm sure there's still few duplicates there though..

Okay, then I guess I'm okay with this.

Reviewed-by: Rob Herring <robh@...nel.org>