Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

On Mon, Aug 01, 2016 at 08:33:55PM +0200, Andrzej Hajda wrote:
> On 08/01/2016 07:06 PM, Mark Brown wrote:

> > The device isn't supposed to work, just not crash - this is mainly used
> > for things that are exposed to userspace where we need to keep returning
> > errors to userspace until they free their reference.  I'm not sure we
> > can get out of that one.

> Could you give some examples? I suppose this is slightly different issue
> than unbinding provider of working resource.

Anything where you have a resource open from userspace pretty much - a
file stored on media that got removed for example.  The struct
representing the open file handle needs to be valid as long as the file
is open.

> > I think a lot of the difference between the two cases above is just
> > about where the default callback comes from and how it's presented to
> > users - having the driver core able to handle critical resources doesn't
> > seem hugely different to providing a list of resources and offsets into
> > driver_data in the struct driver and having a default callback that
> > calls probe() and remove() with an already allocated and initialized
> > driver_data.  That'd definitely cut down a lot on bolilerplate code,

> If you want to driver core handle critical resources you should teach
> it how to get description of these resources (DT/ACPI properties, platform
> data in case of older systems, ...anything else?) and to distinguish
> between critical and optional resources (this info is not available in DT).
> If you leave this task to the device driver it has already this knowledge,
> so you just need to create some helpers.

You don't need to do one or the other, you can do both (though as Lars
pointed out if there's things the core doesn't know about that means it
can do less, like with suspend/resume).

> > but
> > there's problems with the driver trying to clean up when removing (eg,
> > disabling things) when some of the resources it used are in the process
> > of being removed themselves.

> Serialization of this process should solve it (as I proposed in RFC),
> ie. all tasks below:
> - registering callback monitoring given resource,
> - unregistering the callback,
> - registering the resource,
> - unregistering the resource,
> should be serialized.

> There is still a question about granulation of serialization:
> it could be done at framework level but it could be done
> also per resource.

Serialization doesn't help here.  If a resource is unregistering and a
callback is called it's likely that the callback will want to do
something like disable the thing that's trying to free itself which is
potentially messy.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]