ti_scm_syscon driver

[Thomas Skibo]

On Mon, Sep 07, 2020 at 11:56:39AM +0200, Michal Meloun wrote:
> 
> 
> On 07.09.2020 10:40, Oskar Holmlund via freebsd-arm wrote:
> > 
> > Hi Thomas,
> > 
> > I'm sorry I've caused you trouble with ti_scm_syscon.c catchall for syscon.
> > 
> > I will try to point out the situation from TI dts.
> > (head) sys/gnu/dts/arm/am33xx-l4.dtsi from line 270 the control module are defined and 286 the syscon part.
> > The Control module are described here
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/omap/ctrl.txt
> > the syscon part is not directly documented for TI its just there in the example.
> > (of course this exist https://www.kernel.org/doc/Documentation/devicetree/bindings/mfd/syscon.txt )
> > 
> > I'm glad for any suggestions to solve the issue to not interfere with other drivers.
> > I can test your proposal to lower the priority.
> > Or get TI to change syscon to something more specific in the DTS?
> > Maybe its better if i hardcode ti_scm.c to add the syscon child and remove the probe part from ti_scm_syscon.c?
> > Other suggestions?
> >
> 
> I completely overlooked this problem in review, sorry for that.
> I think that we should delete ti_scm_syscon driver at all - it doesn't
> contain a single bit of TI specific code and it incorrectly steals pure
> "syscon" compatibility string.
> Instead, we should expand existing existing extres/syscon_generic driver
> and teach it about ???simple-bus" compatibility string. Exactly as we
> already do in fdt/simple_mfd driver.
> Thomas, priority returned by bus_probe method works only for drivers
> probed at same bus_pass (in other word, bus_pass have precedence over
> priority returned by bus_probe() method. That???s also mean that more
> specific syscon driver must be probed at BUS_PASS_DEFAULT bus pass or
> earlier.
> 
> Both fact (priority interference with bus pass and very late syscon
> instantiation - syscon should be one of first drivers available) looks
> like bugs for me...
> 
> I will try to fix existing syscon_generic ASAP.
> Michal
> 

Thanks for the replies.  It sounds like anything with simple-mfd and/or
syscon shouldn't have any functionality in the top node and everything
should be delegated to drivers attached to the subnodes.  I have moved
the clock functionality to a seperate driver but there are some miscellaneous
registers that aren't even covered by the the subnodes' reg properties
(and the ranges property is broken too).  I'll probably have to rethink
all this.

So, don't go out of your way for me.  I only brought it up because I thought
it would affect many other boards.

Thanks.

--Thomas Skibo