From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pawel Moll Subject: Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support Date: Wed, 19 Jun 2013 16:14:58 +0100 Message-ID: <1371654898.3173.11.camel@hornet> References: <1370512763-32200-1-git-send-email-lorenzo.pieralisi@arm.com> <201306191437.20759.arnd@arndb.de> <1371646530.3867.12.camel@hornet> <201306191703.35182.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <201306191703.35182.arnd@arndb.de> Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Samuel Ortiz , Lorenzo Pieralisi , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "devicetree-discuss@lists.ozlabs.org" , Nicolas Pitre , Amit Kucheria , Jon Medhurst , Achin Gupta , Sudeep KarkadaNagesha List-Id: devicetree@vger.kernel.org On Wed, 2013-06-19 at 16:03 +0100, Arnd Bergmann wrote: > On Wednesday 19 June 2013, Pawel Moll wrote: > > ... but sysreg does more than just that. In particular it provides = a > > pseudo-gpio controller (I don't think you want to hide this behind = the > > syscon) and it can act as a bridge to the configuration bus - see > > below. In short - no, I don't think sysreg driver can disappear. It= can > > be reduced in size, yes. >=20 > As I said, the gpio part can be a separate driver that just handles > gpio,=20 I've already promised Samuel that. > and I think the configuration bridge can be part of the > vexpress-config driver, building on top of syscon. I'm not completely > sure about the latter part. I don't think so, no. I appreciate what you are trying to say, but I object to mixing ideas for the sake of reducing number of files. The config infrastructure is completely independent from the sysreg. Each o= f them can exist on its own. The only common thing is a (slightly baroque= ) communication interface between those two. > > > > > 3. Move vexpress-config into drivers/bus as it is (however I = see no one > > > > > in MAINTAINERS for this directory) > > > > ISTR that Arnd originally created that directory, so he may hel= p here. > > > > Arnd also had some concerns about implementing this code as a b= us, > > > > mostly about it not being a discoverable bus. IMHO that's a val= id > > > > concern, and this is why you ended up putting it under MFD whic= h can be > > > > seen as some sort of platform devices bus. But I still believe = the bus > > > > API would make this code look cleaner and easier to maintain. > > >=20 > > > Sorry, I don't see why it would be a bus. I assume that there is = code > > > missing somewhere that is not yet merged, right? > >=20 > > Well, different VE components (configuration microcontrollers on > > motherboard and daughterboards in particular) talk to each other ov= er a > > bus (an SPI derivative, in case you were wondering). So there is a = bus. > > A non-discoverable one, but it does 42 (approximately ;-) different > > things. We already have: clk, hwmon, regulator and reset drivers us= ing > > it. >=20 > Ah, got it. In this case I think what you are looking for is a custom > 'regmap' interface that abstracts those devices. Regmap can already > cover i2c, spi and mmio based sets of registers (syscon is one exampl= e > for mmio), and IIRC there is a simple way of extending it to other > register-level interfaces like this one. This is an interesting idea. The thing that worries me the most is its early (pre-slab) availability, but I will give it a try. Pawe=C5=82