From: <Christian.Gromm@microchip.com>
To: <gregkh@linuxfoundation.org>
Cc: driverdev-devel@linuxdriverproject.org
Subject: Re: [PATCH v4 01/10] staging: most: remove device from interface structure
Date: Fri, 24 Jan 2020 08:56:56 +0000 [thread overview]
Message-ID: <2dc825b7ff12cf90de21f9f2486952a935401dba.camel@microchip.com> (raw)
In-Reply-To: <20200123181837.GA1927902@kroah.com>
On Thu, 2020-01-23 at 19:18 +0100, Greg KH wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> On Thu, Jan 23, 2020 at 04:38:17PM +0100, Christian Gromm wrote:
> > This patch makes the adapter drivers use their own device
> > structures
> > when registering a most interface with the core module.
> > With this the module that actually operates the physical device is
> > the
> > owner of the device.
>
> Ick, why? The interface should be part of sysfs, right, and now it
> isn't?
It still is. What has changed is that the device that actually
represents the attached hardware is used (see probe function of
the USB adapter driver for instance).
> Who handles the lifetime rules of these interfaces now? Why
> remove this?
The struct device that is allocated when attaching a MOST device is
handling the lifetime and the struct most_interface is
representing this device in the kernel. Hence, registered with sysfs.
This ensures that the device is present in the kernel until its
physical stature is being detached from the system.
The core driver is just the man in the middle that registers the
bus and itself as the driver and organizes the configfs, sysfs and
communication paths to user space.
>
> Why isn't the interface dynamically created properly? That should
> solve
> the lifetime rules here, right?
The interface is dynamically allocated. This happens inside the
USB, DIM2, I2C etc. drivers. The struct most_interface is part of
the container struct there.
thanks,
Chris
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-01-24 8:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 15:38 [PATCH v4 00/10] staging: most: move core module out of staging Christian Gromm
2020-01-23 15:38 ` [PATCH v4 01/10] staging: most: remove device from interface structure Christian Gromm
2020-01-23 18:18 ` Greg KH
2020-01-24 8:56 ` Christian.Gromm [this message]
2020-01-24 9:09 ` Greg KH
2020-02-06 9:14 ` Christian.Gromm
2020-02-14 16:17 ` Greg KH
2020-03-23 14:16 ` Christian.Gromm
2020-01-23 15:38 ` [PATCH v4 02/10] staging: most: core: drop device reference Christian Gromm
2020-01-23 15:38 ` [PATCH v4 03/10] staging: most: remove struct device core driver Christian Gromm
2020-01-23 15:38 ` [PATCH v4 04/10] staging: most: core: remove container struct Christian Gromm
2020-01-23 15:38 ` [PATCH v4 05/10] staging: most: core: fix logging messages Christian Gromm
2020-01-23 15:38 ` [PATCH v4 06/10] staging: next: configfs: fix release link Christian Gromm
2020-01-23 15:38 ` [PATCH v4 07/10] staging: most: usb: check for NULL device Christian Gromm
2020-01-23 15:38 ` [PATCH v4 08/10] staging: most: move core files out of the staging area Christian Gromm
2020-01-23 15:38 ` [PATCH v4 09/10] staging: most: Documentation: update ABI description Christian Gromm
2020-01-23 15:38 ` [PATCH v4 10/10] staging: most: Documentation: move ABI description files out of staging area Christian Gromm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2dc825b7ff12cf90de21f9f2486952a935401dba.camel@microchip.com \
--to=christian.gromm@microchip.com \
--cc=driverdev-devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).