> > I think there is something wrong with an interface that makes you use
> > IS_ERR_OR_NULL(). If you are calling reset_control_get_optional(), that'
> > should not return an error when there is no reset controller listed
> > in the device tree. We should still have a way to propagate -EPROBE_DEF
Arnd, Olof, Kevin,
On 24/03/2014 14:33, Wolfram Sang wrote:
>
>>> Looping linux-next into the CC since this is the cause of the failure
>>> in orion5x_defconfig there, and no point in anyone else re-doing the
>>> same bisect.
>>
>> I sent a fix for this that hasn't been picked up yet:
>> http://l
> > Looping linux-next into the CC since this is the cause of the failure
> > in orion5x_defconfig there, and no point in anyone else re-doing the
> > same bisect.
>
> I sent a fix for this that hasn't been picked up yet:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/239069.h
On Sat, Mar 22, 2014 at 12:11:24PM +0100, Arnd Bergmann wrote:
> On Friday 21 March 2014 20:17:39 Maxime Ripard wrote:
> > On Fri, Mar 21, 2014 at 11:49:59AM -0400, Paul Gortmaker wrote:
> > > On Mon, Mar 10, 2014 at 7:29 AM, Russell King - ARM Linux
> > > wrote:
> > > > On Mon, Mar 10, 2014 at 11
On Friday 21 March 2014 20:17:39 Maxime Ripard wrote:
> On Fri, Mar 21, 2014 at 11:49:59AM -0400, Paul Gortmaker wrote:
> > On Mon, Mar 10, 2014 at 7:29 AM, Russell King - ARM Linux
> > wrote:
> > > On Mon, Mar 10, 2014 at 11:58:08AM +0100, Maxime Ripard wrote:
> > >> On Fri, Mar 07, 2014 at 04:08
On Fri, Mar 21, 2014 at 11:49:59AM -0400, Paul Gortmaker wrote:
> On Mon, Mar 10, 2014 at 7:29 AM, Russell King - ARM Linux
> wrote:
> > On Mon, Mar 10, 2014 at 11:58:08AM +0100, Maxime Ripard wrote:
> >> On Fri, Mar 07, 2014 at 04:08:36PM +, Russell King - ARM Linux wrote:
> >> > On Fri, Mar
On Mon, Mar 10, 2014 at 7:29 AM, Russell King - ARM Linux
wrote:
> On Mon, Mar 10, 2014 at 11:58:08AM +0100, Maxime Ripard wrote:
>> On Fri, Mar 07, 2014 at 04:08:36PM +, Russell King - ARM Linux wrote:
>> > On Fri, Mar 07, 2014 at 03:59:30PM +0100, Maxime Ripard wrote:
>> > > @@ -900,7 +902,8
On Mon, Mar 10, 2014 at 11:58:08AM +0100, Maxime Ripard wrote:
> On Fri, Mar 07, 2014 at 04:08:36PM +, Russell King - ARM Linux wrote:
> > On Fri, Mar 07, 2014 at 03:59:30PM +0100, Maxime Ripard wrote:
> > > @@ -900,7 +902,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> > > exit_free_irq:
On Fri, Mar 07, 2014 at 04:08:36PM +, Russell King - ARM Linux wrote:
> On Fri, Mar 07, 2014 at 03:59:30PM +0100, Maxime Ripard wrote:
> > @@ -900,7 +902,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> > exit_free_irq:
> > free_irq(drv_data->irq, drv_data);
> > exit_reset:
> > - if
On Fri, Mar 07, 2014 at 06:29:49PM +0100, Wolfram Sang wrote:
>
> > > Another question is... why do we need to check pd->dev.of_node here?
> > > If CONFIG_RESET_CONTROLLER is set, we always try to get the reset
> > > controller node, so drv_data->rstc is either going to be a valid
> > > pointer, o
> > Another question is... why do we need to check pd->dev.of_node here?
> > If CONFIG_RESET_CONTROLLER is set, we always try to get the reset
> > controller node, so drv_data->rstc is either going to be a valid
> > pointer, or it's going to be an error pointer - neither
> > reset_control_get() no
On Fri, Mar 07, 2014 at 04:08:36PM +, Russell King - ARM Linux wrote:
> On Fri, Mar 07, 2014 at 03:59:30PM +0100, Maxime Ripard wrote:
> > @@ -900,7 +902,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> > exit_free_irq:
> > free_irq(drv_data->irq, drv_data);
> > exit_reset:
> > - if
On Fri, Mar 07, 2014 at 03:59:30PM +0100, Maxime Ripard wrote:
> @@ -900,7 +902,8 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> exit_free_irq:
> free_irq(drv_data->irq, drv_data);
> exit_reset:
> - if (pd->dev.of_node && !IS_ERR(drv_data->rstc))
> + if (pd->dev.of_node && IS_EN
Commit 370136bc67c3 ("i2c: mv64xxx: Add reset deassert call"), introduced a
recursive dependency, which was fixed by commit 80c69915e5fb ("i2c: mv64xxx:
fix circular Kconfig dependency", that in turn, by dropping the dependency on
RESET_CONTROLLER, introduced a compilation breakage whenever this op
14 matches
Mail list logo