[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140318085039.GF25478@lee--X1>
Date: Tue, 18 Mar 2014 08:50:39 +0000
From: Lee Jones <lee.jones@...aro.org>
To: Robert Baldyga <r.baldyga@...sung.com>
Cc: Mark Brown <broonie@...nel.org>,
Chanwoo Choi <cw00.choi@...sung.com>, sameo@...ux.intel.com,
myungjoo.ham@...sung.com, dmitry.torokhov@...il.com,
cooloney@...il.com, rpurdie@...ys.net, dbaryshkov@...il.com,
dwmw2@...radead.org, lgirdwood@...il.com, a.zummo@...ertech.it,
paul.gortmaker@...driver.com, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org, linux-leds@...r.kernel.org,
rtc-linux@...glegroups.com, m.szyprowski@...sung.com,
k.kozlowski@...sung.com
Subject: Re: [PATCH v3 4/4] mfd: max8997: move regmap handling to function
drivers
> >>> Is it necessary? If previous mfd driver has various i2c line, previous mfd driver
> >>> initialize regmap/i2c setting on mfd driver.
> >>> I'm not sure that regmap/i2c setting code move from mfd driver to each driver.
> >>>
> >>> Dear Lee Jones,
> >>> I need your opinion about moving regmap/i2c code from mfd driver to each driver.
> >
> >> I'd rather take advice from Mark on this one.
> >
> > I don't really case that much; I'm having a hard time seeing it as
> > particularly useful to do the refactoring but if it makes people
> > happy... Keeping things in the core would help promote reusability I
> > guess but I'm not sure that's likely to actually happen with this sort
> > of driver/device.
>
> If you think it's not needed, you can ignore this patch. I prepared it
> due to Dmitry Torokhov suggestion. If you think it's useless it doesn't
> make me unhappy :)
Ignored, thanks. ;)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
Powered by blists - more mailing lists