Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1463850 > unrolled thread

Re: Why do we need reset_control_get_optional() ?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why do we need reset_control_get_optional() ? Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-08-16 16:40 +0200
    Re: Why do we need reset_control_get_optional() ? Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-08-24 09:00 +0200
      Re: Why do we need reset_control_get_optional() ? Philipp Zabel <p.zabel@pengutronix.de> - 2016-08-24 14:40 +0200

#1463850 — Re: Why do we need reset_control_get_optional() ?

Hi Philipp, Arnd.



2016-08-09 1:39 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Freitag, den 05.08.2016, 17:50 +0200 schrieb Arnd Bergmann:
>> On Thursday, July 28, 2016 1:00:49 PM CEST Philipp Zabel wrote:
>> > Am Donnerstag, den 28.07.2016, 19:52 +0900 schrieb Masahiro Yamada:
>>
>> > > > In my experimental patch, I make the _optional functions
>> > > > return NULL if no "resets" property is provided but return
>> > > > an error if there are reset lines but the subsystem is
>> > > > disabled, i.e. an optional reset must be used if it's in the
>> > > > DT, but can be ignored otherwise.
>> > >
>> > > I do not like this idea.
>> > >
>> > > reset_control_get() (or variants) should not return NULL, it is ambiguous.
>> > > It should return ERR_PTR(-ENOENT) if no "resets" property.
>> > >
>> > > I only want two types for functions that return a pointer.
>> > >
>> > > [1] return a valid pointer on success, or return NULL on failure
>> > >     (for example, kmalloc())
>> > > [2] return a valid pointer on success, or return error pointer on failure
>> > >    (many of _register() functions)
>> > >
>> > > Mixing [1] and [2] will be a mess.
>>
>> Ah, right. I was thinking only of the case where the reset subsystem
>> is completely disabled here, so returning NULL could be considered
>> a valid return code that can in turn be passed into the other
>> functions.
>>
>> However, I agree that returning NULL as a valid result from
>> ..._get_optional() would be bad style, so let's drop my idea
>> there.
>>
>> > I too would prefer to keep that as-is. The reset_control_get_optional
>> > stub could return -ENOENT if there is no resets device tree property.
>>
>> Now I'm also confused about what we really need
>> reset_control_get_optional() for, and which error codes the callers
>> are supposed to check.
>>
>> This is the matrix I think you mean for _get_optional:
>>
> [...]
>> CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP
>> CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT
>
> ^^ I didn't consider this distiction.
>
>> Is this what you had in mind? If so, what is the value of the
>> added runtime warning for reset_control_get? Any caller of that
>> function would already check for errors, the only difference
>> I see is that callers of _optional can ignore -ENOENT.
>
> My initial motivation was to make it as hard as possible to misconfigure
> the kernel, which is why I initially didn't want stubs for the
> non-optional variant. Of course that would cause build failures and/or
> reduced compile test coverage, so we added the stubs and the warning to
> make it obvious when a misconfigured kernel is running: on a kernel with
> RESET_CONTROLLER=n drivers that use reset_control_get are expected to
> build, but they are not expected to work. I suppose the same is the case
> for _optional, if the dt entry is present, so maybe we should drop
> reset_control_get_optional and add always a warning in case of
> -EOPNOTSUPP.
> I don't want all drivers to have to differentiate between -EOPNOTSUPP
> and -ENOENT error codes, only current reset_control_get_optional users
> have to do that.


I've posted a patch to drop reset_control_get_optional;
https://patchwork.kernel.org/patch/9284063/

Could you check if it works?

If we go this way, my patch
289363fd99a17d6249ee1373541f1da43cbb22c5
in your reset/next branch is completely useless.

As the commits in the reset-subsystem do not appear
even in linux-next until they are pulled into the ASOC tree,
how about dropping 289363fd and turning around?


-- 
Best Regards
Masahiro Yamada

[toc] | [next] | [standalone]

#1469121

Hi Philipp,

2016-08-16 23:36 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Hi Philipp, Arnd.
>
>
>
> 2016-08-09 1:39 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> Am Freitag, den 05.08.2016, 17:50 +0200 schrieb Arnd Bergmann:
>>> On Thursday, July 28, 2016 1:00:49 PM CEST Philipp Zabel wrote:
>>> > Am Donnerstag, den 28.07.2016, 19:52 +0900 schrieb Masahiro Yamada:
>>>
>>> > > > In my experimental patch, I make the _optional functions
>>> > > > return NULL if no "resets" property is provided but return
>>> > > > an error if there are reset lines but the subsystem is
>>> > > > disabled, i.e. an optional reset must be used if it's in the
>>> > > > DT, but can be ignored otherwise.
>>> > >
>>> > > I do not like this idea.
>>> > >
>>> > > reset_control_get() (or variants) should not return NULL, it is ambiguous.
>>> > > It should return ERR_PTR(-ENOENT) if no "resets" property.
>>> > >
>>> > > I only want two types for functions that return a pointer.
>>> > >
>>> > > [1] return a valid pointer on success, or return NULL on failure
>>> > >     (for example, kmalloc())
>>> > > [2] return a valid pointer on success, or return error pointer on failure
>>> > >    (many of _register() functions)
>>> > >
>>> > > Mixing [1] and [2] will be a mess.
>>>
>>> Ah, right. I was thinking only of the case where the reset subsystem
>>> is completely disabled here, so returning NULL could be considered
>>> a valid return code that can in turn be passed into the other
>>> functions.
>>>
>>> However, I agree that returning NULL as a valid result from
>>> ..._get_optional() would be bad style, so let's drop my idea
>>> there.
>>>
>>> > I too would prefer to keep that as-is. The reset_control_get_optional
>>> > stub could return -ENOENT if there is no resets device tree property.
>>>
>>> Now I'm also confused about what we really need
>>> reset_control_get_optional() for, and which error codes the callers
>>> are supposed to check.
>>>
>>> This is the matrix I think you mean for _get_optional:
>>>
>> [...]
>>> CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP
>>> CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT
>>
>> ^^ I didn't consider this distiction.
>>
>>> Is this what you had in mind? If so, what is the value of the
>>> added runtime warning for reset_control_get? Any caller of that
>>> function would already check for errors, the only difference
>>> I see is that callers of _optional can ignore -ENOENT.
>>
>> My initial motivation was to make it as hard as possible to misconfigure
>> the kernel, which is why I initially didn't want stubs for the
>> non-optional variant. Of course that would cause build failures and/or
>> reduced compile test coverage, so we added the stubs and the warning to
>> make it obvious when a misconfigured kernel is running: on a kernel with
>> RESET_CONTROLLER=n drivers that use reset_control_get are expected to
>> build, but they are not expected to work. I suppose the same is the case
>> for _optional, if the dt entry is present, so maybe we should drop
>> reset_control_get_optional and add always a warning in case of
>> -EOPNOTSUPP.
>> I don't want all drivers to have to differentiate between -EOPNOTSUPP
>> and -ENOENT error codes, only current reset_control_get_optional users
>> have to do that.
>
>
> I've posted a patch to drop reset_control_get_optional;
> https://patchwork.kernel.org/patch/9284063/
>
> Could you check if it works?
>
> If we go this way, my patch
> 289363fd99a17d6249ee1373541f1da43cbb22c5
> in your reset/next branch is completely useless.
>
> As the commits in the reset-subsystem do not appear
> even in linux-next until they are pulled into the ASOC tree,
> how about dropping 289363fd and turning around?
>


If you want to take time for this topic,
how about dropping 289363fd99a17d6249ee1373541f1da43cbb22c5
("reset: add WARN_ON(1) to non-optional reset_control_get variants")
for now?


I noticed some reset consumers already started dropping _optional,
while their reset lines should be really optional.

See
commit d0e08b0077f49e209bc90305ddf1ca434ac6cc0e
commit 62d9694a003dba585026df36c181e3ca930aeafc

Even generic drivers such as ehci-platform.c / ohci-platform.c
opted out of _optional.


If commit 289363fd99a17d6249ee1373541f1da43cbb22c5 is merged,
users of the generic drivers but without reset-controller
will start to complain about the WARN_ON(1)  sooner or later.


-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [next] | [standalone]

#1469388

Am Mittwoch, den 24.08.2016, 15:58 +0900 schrieb Masahiro Yamada:
> Hi Philipp,
> 
> 2016-08-16 23:36 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> > Hi Philipp, Arnd.
> >
> >
> >
> > 2016-08-09 1:39 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> >> Am Freitag, den 05.08.2016, 17:50 +0200 schrieb Arnd Bergmann:
> >>> On Thursday, July 28, 2016 1:00:49 PM CEST Philipp Zabel wrote:
> >>> > Am Donnerstag, den 28.07.2016, 19:52 +0900 schrieb Masahiro Yamada:
> >>>
> >>> > > > In my experimental patch, I make the _optional functions
> >>> > > > return NULL if no "resets" property is provided but return
> >>> > > > an error if there are reset lines but the subsystem is
> >>> > > > disabled, i.e. an optional reset must be used if it's in the
> >>> > > > DT, but can be ignored otherwise.
> >>> > >
> >>> > > I do not like this idea.
> >>> > >
> >>> > > reset_control_get() (or variants) should not return NULL, it is ambiguous.
> >>> > > It should return ERR_PTR(-ENOENT) if no "resets" property.
> >>> > >
> >>> > > I only want two types for functions that return a pointer.
> >>> > >
> >>> > > [1] return a valid pointer on success, or return NULL on failure
> >>> > >     (for example, kmalloc())
> >>> > > [2] return a valid pointer on success, or return error pointer on failure
> >>> > >    (many of _register() functions)
> >>> > >
> >>> > > Mixing [1] and [2] will be a mess.
> >>>
> >>> Ah, right. I was thinking only of the case where the reset subsystem
> >>> is completely disabled here, so returning NULL could be considered
> >>> a valid return code that can in turn be passed into the other
> >>> functions.
> >>>
> >>> However, I agree that returning NULL as a valid result from
> >>> ..._get_optional() would be bad style, so let's drop my idea
> >>> there.
> >>>
> >>> > I too would prefer to keep that as-is. The reset_control_get_optional
> >>> > stub could return -ENOENT if there is no resets device tree property.
> >>>
> >>> Now I'm also confused about what we really need
> >>> reset_control_get_optional() for, and which error codes the callers
> >>> are supposed to check.
> >>>
> >>> This is the matrix I think you mean for _get_optional:
> >>>
> >> [...]
> >>> CONFIG_RESET_CONTROLLER=n, dt entry present: -EOPNOTSUPP
> >>> CONFIG_RESET_CONTROLLER=n, dt entry missing: -ENOENT
> >>
> >> ^^ I didn't consider this distiction.
> >>
> >>> Is this what you had in mind? If so, what is the value of the
> >>> added runtime warning for reset_control_get? Any caller of that
> >>> function would already check for errors, the only difference
> >>> I see is that callers of _optional can ignore -ENOENT.
> >>
> >> My initial motivation was to make it as hard as possible to misconfigure
> >> the kernel, which is why I initially didn't want stubs for the
> >> non-optional variant. Of course that would cause build failures and/or
> >> reduced compile test coverage, so we added the stubs and the warning to
> >> make it obvious when a misconfigured kernel is running: on a kernel with
> >> RESET_CONTROLLER=n drivers that use reset_control_get are expected to
> >> build, but they are not expected to work. I suppose the same is the case
> >> for _optional, if the dt entry is present, so maybe we should drop
> >> reset_control_get_optional and add always a warning in case of
> >> -EOPNOTSUPP.
> >> I don't want all drivers to have to differentiate between -EOPNOTSUPP
> >> and -ENOENT error codes, only current reset_control_get_optional users
> >> have to do that.
> >
> >
> > I've posted a patch to drop reset_control_get_optional;
> > https://patchwork.kernel.org/patch/9284063/
> >
> > Could you check if it works?
> >
> > If we go this way, my patch
> > 289363fd99a17d6249ee1373541f1da43cbb22c5
> > in your reset/next branch is completely useless.
> >
> > As the commits in the reset-subsystem do not appear
> > even in linux-next until they are pulled into the ASOC tree,
> > how about dropping 289363fd and turning around?
> >
> 
> 
> If you want to take time for this topic,
> how about dropping 289363fd99a17d6249ee1373541f1da43cbb22c5
> ("reset: add WARN_ON(1) to non-optional reset_control_get variants")
> for now?
> 
> 
> I noticed some reset consumers already started dropping _optional,
> while their reset lines should be really optional.
> 
> See
> commit d0e08b0077f49e209bc90305ddf1ca434ac6cc0e
> commit 62d9694a003dba585026df36c181e3ca930aeafc
> 
> Even generic drivers such as ehci-platform.c / ohci-platform.c
> opted out of _optional.
> 
> 
> If commit 289363fd99a17d6249ee1373541f1da43cbb22c5 is merged,
> users of the generic drivers but without reset-controller
> will start to complain about the WARN_ON(1)  sooner or later.

Hmm, I would really like to keep the warnings, but as Arnd suggested,
only if the device tree property is present. I'll drop your patch for
now.

regards
Philipp

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web