linux-kernel - Re: [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code

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:	Fri, 28 Sep 2012 10:43:03 +0200
From:	Davide Ciminaghi <ciminaghi@...dd.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	sameo@...ux.intel.com, rubini@...dd.com, giancarlo.asnaghi@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code

On Thu, Sep 27, 2012 at 02:49:19PM +0100, Mark Brown wrote:
> On Thu, Sep 27, 2012 at 03:41:10PM +0200, Davide Ciminaghi wrote:
> 
> > Maybe there's another solution: what about adding a couple of function
> > pointers (lock, unlock) to struct regmap_config ? If they're set to NULL,
> > everything works as usual. If they're not NULL, regmap uses such functions
> > to do locking and unlocking instead of the usual ones (and regmap_bus.fast_io
> > is ignored). I think this wouldn't hurt existing regmap users and allow
> > sta2x11-mfd to have just one spinlock for everything, no need for nested
> > locking this way.
> 
> That might work, yes, and would be generally useful I think.  Or we
> could add regmap based versions of the clock utilities (which would also
> be useful anyway).  Or both.

I have a (first, incomplete but working) clock framework implementation for
the sta2x11 ready, but can't submit it until these sta2x11-mfd patches have
been accepted.
And then of course many of the drivers we need on sta2x11 depend on the
clock framework (they're amba drivers). So, since sta2x11-mfd is blocking much
of our work, I would proceed like this:

1. Regmap patch for overriding lock/unlock functions
2. Regmap based reimplementation of sta2x11-mfd (using sta2x11 special
   lock/unlock functions).
3. Submission of sta2x11 common clock framework as is (using the current
   version of the clock framework helpers, no regmap).
4. Patches for some amba drivers to get them to work on sta2x11.
5. Regmap related patches for the common clock framework.

Does this sound reasonable ?

Thanks and regards
Davide

--
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/