Re: [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core

[Marek Szyprowski]

Hello,

On 2013-11-14 11:24, Mark Brown wrote:
> On Thu, Nov 14, 2013 at 10:33:22AM +0900, Kyungmin Park wrote:
> > On Wed, Nov 13, 2013 at 10:13 PM, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> > > Are you *positive* this is a falling triggered IRQ?  All the code to do
> > > with spinning reading the GPIO state during handling makes it look like
> > > this is in fact an active low interrupt and a lot of the code in here is
> > > working around trying to handle that as the wrong kind of IRQ.
>
> > It's not work with level triggering. as wm8994, it requires edge
> > triggering. previous time I send RFC patch to handle edge triggering
> > at regmap.
>
> No, wm8994 is level triggered only - the edge triggering stuff there is
> to work around some SoCs that could only support edge triggering and not
> level triggering.  Is this a similar issue or is there something else
> going on, what's the differeence with a level triggered scheme?
>
> > >> +static int __init max14577_i2c_init(void)
> > >> +{
> > >> +     return i2c_add_driver(&max14577_i2c_driver);
> > >> +}
> > >> +subsys_initcall(max14577_i2c_init);
>
> > > Why not module_i2c_driver?
>
> > there's ordering issue, it should provide regulator which is used
> > others before USB probe. if not, it failed to use USB.
> > Other PMICs use also subsys_initcall for this reason.
>
> Modern systems should be able to use deferred probing to resolve these
> dependencies, subsys_initcall() is mostly there for legacy reasons and
> new systems ought to be able to move away from it.

The main problem here is usb gadget subsystem, which simply doesn't support
deferred probe yet. UDC driver (which uses those regulators) need to be
initialized before usb gadget driver (i.e. mass storage or cdc ethernet)
has been registered.

Best regards
--
Marek Szyprowski
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/