Re: Fwd: Surface Go VCM type (was: Need to pass acpi_enforce_resources=lax on the Surface Go (version1))

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Fri, Nov 12, 2021 at 01:37:27PM +0200, Andy Shevchenko wrote:
> On Fri, Nov 12, 2021 at 12:46:56PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 12, 2021 at 10:32:31AM +0000, Dave Stevenson wrote:
> > > On Thu, 11 Nov 2021 at 22:04, Laurent Pinchart wrote:
> 
> > > Sorry, just my two-penneth as someone who has to support general
> > > users, rather than just develop platforms or address specific use
> > > cases.
> > 
> > As mentioned above, I certainly don't oppose improving power management
> > for VCMs, as well as the VCM control API in general, as long as we can
> > cover all use cases. I'm not familiar enough with the use cases to tell
> > whether making the kernel side more "clever" would be just fine or could
> > cause issues.
> 
> Personally I found the
> 
>   kernel <--> library in userspace <--> another library or app
> 
> schema is more flexible in many ways:
>  - we unburden kernel from the heavy code that has nothing to
>    do directly with HW
>  - we allow nevertheless to use kernel ABIs if needed
>  - we decrease burden of the ABI evolution by doing it in only
>    two places

I think that's generally true (provided the low-level userspace library
is well designed). In this specific case, we're moving towards that
model, and even if it ends up being better, I agree with Dave that the
transition can be painful.

> After all this kind of schema might lead us at some point to the
> shifting of 'we don't break user space' paradigm to the 'we hardly
> try not to break user space and do not break library ABIs / APIs
> in user space'.

Is that an officially allowed policy for kernel subsystems ?

-- 
Regards,

Laurent Pinchart