> > 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
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_DEFER,
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:
>>
> > 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:
>
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
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
li...@arm.linux.org.uk wrote:
On Mon, Mar 10,
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.html
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:
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
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 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
li...@arm.linux.org.uk 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 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
li...@arm.linux.org.uk wrote:
On Mon, Mar 10, 2014 at 11:58:08AM +0100, Maxime Ripard wrote:
On Fri, Mar 07,
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
On Mon, Mar 10, 2014 at 7:29 AM, Russell King - ARM Linux
li...@arm.linux.org.uk 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:
@@
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)
> > >
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:
> > -
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 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 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,
> > 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()
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:
> > -
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 &&
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
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
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
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
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() nor
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, or it's going
28 matches
Mail list logo
