Re: [PATCH v2 2/2] rust: regulator: add devm_enable and devm_enable_optional

[Boqun Feng]

On Tue, Sep 09, 2025 at 06:11:24PM +0100, Mark Brown wrote:
> On Tue, Sep 09, 2025 at 09:27:46AM -0700, Boqun Feng wrote:
> > On Tue, Sep 09, 2025 at 05:58:34PM +0200, Miguel Ojeda wrote:
> 
> > > It depends on what the C API does -- if the C API is supposed to
> > > "always work" (even if it is no-op or if it returns errors) even when
> > > disabled (so that callers are easier), then we likely need to
> > > replicate that on our side.
> 
> > While I don't disagree with the rule in general, but I do want to say
> > the cost is the binary size (at least without inlining helpers), so I
> > think we are allowed to apply this rule case by case, i.e. even if a C
> > API is supposed to "always work" but Rust can avoid exposing the API at
> > some configurations.
> 
> The C stubs are all inlined so should have zero impact on the resulting
> binary (as are all equivalent stubs generally).

Yeah, but for a rust_helper, right now a function and an exported symbol
will be generated so that Rust can do FFI. That's the size impact I'm
talking about. And for regulator, we only have helpers if
CONFIG_REGULATOR=n.

Regards,
Boqun