Fine, fine. Much improved etc. :) Thanks.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://ww
On 12-08-15, 12:03, Dan Carpenter wrote:
> It's a lot better but it would be better yet with a return 0;. There is
> an earlier goto put_opp_np on the success path, but that's fine. It's
> not the normal success path so it's necessarily complicated.
I see where you are coming from and it makes l
On Wed, Aug 12, 2015 at 01:53:02PM +0530, Viresh Kumar wrote:
> On 12-08-15, 11:11, Dan Carpenter wrote:
> > If it doesn't WARN() then it's not buggy, but it's still ugly. We
> > should not call of_free_opp_table() because we *tried* to add an OPP, we
> > should only call it if we *succeeded*.
>
On 12-08-15, 11:11, Dan Carpenter wrote:
> If it doesn't WARN() then it's not buggy, but it's still ugly. We
> should not call of_free_opp_table() because we *tried* to add an OPP, we
> should only call it if we *succeeded*.
This is done in order to write lesser code. Otherwise we need
something
On Wed, Aug 12, 2015 at 12:13:09PM +0530, Viresh Kumar wrote:
> > If the first call to _opp_add_static_v2() fails we call
> > of_free_opp_table() and you say that triggers a WARN().
>
> No it doesn't.
>
> So, coming back to the point you made about freeing table on !count,
> because there were no
On 11-08-15, 20:11, Dan Carpenter wrote:
> On Tue, Aug 11, 2015 at 08:29:38PM +0530, Viresh Kumar wrote:
> > > This is weird to me, because we are going backwards. What happens if
> > > we goto free_table without adding anything?
> >
> > It will WARN() today.
>
> Then the current code is buggy.
On Tue, Aug 11, 2015 at 08:29:38PM +0530, Viresh Kumar wrote:
> > This is weird to me, because we are going backwards. What happens if
> > we goto free_table without adding anything?
>
> It will WARN() today.
Then the current code is buggy.
>
> > I suspect it's fine, but if
> > it's a bug then
On 11-08-15, 17:43, Dan Carpenter wrote:
> > @@ -1323,28 +1323,29 @@ static int _of_init_opp_table_v2(struct device *dev,
> > if (ret) {
> > dev_err(dev, "%s: Failed to add OPP, %d\n", __func__,
> > ret);
> > - break;
> >
On Tue, Aug 11, 2015 at 04:04:34PM +0530, Viresh Kumar wrote:
> _of_init_opp_table_v2() isn't freeing up resources on some errors and
> the error values returned are also not correct always.
>
> This fixes following problems:
> - Return -ENOENT, if no entries are found in the table.
> - Use IS_ERR
_of_init_opp_table_v2() isn't freeing up resources on some errors and
the error values returned are also not correct always.
This fixes following problems:
- Return -ENOENT, if no entries are found in the table.
- Use IS_ERR() to properly check return value of _find_device_opp().
- Return error va
10 matches
Mail list logo
