linux-kernel - Re: [PATCH v3] USB: PHY: Palmas USB Transceiver Driver

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]

Message-ID: <5151D37A.4020300@slimlogic.co.uk>
Date:	Tue, 26 Mar 2013 16:57:30 +0000
From:	Graeme Gregory <gg@...mlogic.co.uk>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Laxman Dewangan <ldewangan@...dia.com>,
	Kishon Vijay Abraham I <kishon@...com>,
	"balbi@...com" <balbi@...com>, Rajendra Nayak <rnayak@...com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"s-guiriec@...com" <s-guiriec@...com>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Ian Lartey <ian@...mlogic.co.uk>
Subject: Re: [PATCH v3] USB: PHY: Palmas USB Transceiver Driver

On 26/03/13 16:22, Stephen Warren wrote:
> On 03/26/2013 03:27 AM, Graeme Gregory wrote:
> ...
>> If we are tightly coupling as above then using platform_irq is an extra
>> inefficiency. You both have to populate this then parse it afterwards.
>> Why not just use the regmap helper? Ill admit this code is like this as
>> there was a period where platform irqs in DT just was not working right!
>>
>> We should really agree now if we are going for loose or tight coupling
>> now rather than keep switching?
> Yes, this is something that I think needs to be fully resolved before
> any more Palmas patches are discussed.
>
> So you can have the MFD components fully coupled or completely
> standalone. We should fully pick one or the other, not some mish-mash of
> the two.
>
> In practical terms, this means that:
>
> a) Tightly coupled
>
> The top-level MFD device knows exactly which child devices are present.
> It has an internal table to defined the set of child devices, and
> instantiate them. It provides them with IRQs, I2C addresses and register
> base addresses (or regmaps), etc. etc., using purely Palmas-internal
> APIs. If using device tree, the DT won't include any representation of
> which child devices are present, nor their I2C addresses, nor their
> register addresses, nor their IRQs, etc. That's all inside the driver.
>
> b) Completely decoupled.
>
> The top-level MFD device knows nothing about its children. It simply
> provides a bus into which they can be instantiated, and a generic IRQ
> controller into which they can hook.
>
> Platform data or device tree is solely used to define which children
> exist, which of the top-level MFD's I2C addresses is used for each
> child, the base register address for each child device, the IRQs used by
> each child device, etc.
>
>
> Which of those two models are different people expecting?
>
> (b) appears to be the most flexible, and since you have defined the DT
> bindings to contain a separate node for each MFD child device, each with
> its own compatible value, seems to be what you're aiming for. In this
> scenario, there should be no private APIs between the top-level MFD
> device and the children though; everything should be using standard bus
> APIs.
I was aiming towards (b) which would allow drivers for IP blocks that I
know are shared between multiple devices such as RTC which is shared by
twl6030, twl6032, tps80032, tps65910, tps65911, tps65912, tps80035,
tps80036 and probably many more.

Finishing (b) implementation is currently beyond the time I have
available I think.

If we choose to ignore path (b) and ignore the code duplication of half
a dozen RTC drivers for the same IP than the path to (a) is much quicker
and easier. Can just rip out a lot of the DT stuff, use mfd_add_devices.
Makes the binding much simpler. Means we don't have to use platform
resources for IRQs. Makes palmas and palmas-charger just 2 black boxes
which is in line with other MFDs.

So I think I have come around to just do it the easy way and select (a)

I shall work on the main palmas series to implement (a).

This will obviously invalidate some comments on this patch and the main
series.

Graeme

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