From: <Christian.Gromm@microchip.com>
To: <gregkh@linuxfoundation.org>
Cc: driverdev-devel@linuxdriverproject.org
Subject: Re: [PATCH RFC v3 4/9] staging: most: move interface dev to private section
Date: Wed, 15 Jan 2020 16:04:19 +0000 [thread overview]
Message-ID: <0f71adefe079f5bc1c0ca777c0b8553f46ccea3a.camel@microchip.com> (raw)
In-Reply-To: <20200115121712.GA3394319@kroah.com>
On Wed, 2020-01-15 at 13:17 +0100, Greg KH wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> On Tue, Jan 14, 2020 at 04:57:53PM +0100, Christian Gromm wrote:
> > This patch moves the struct device of the interface structure to
> > its
> > private section, because only the core should access it directly.
> > For
> > other entities an API is provided.
>
> This feels "wrong".
>
> Shouldn't the struct device in this structure be the thing that is
> handling the reference counting and sysfs integration for this
> structure?
Yes, that's right.
> To put it as a "pointer" in a private section of the
> structure feels like it is now backwards.
>
> What is this helping with? Who was messing with the device structure
> here that needed to not mess with it?
Well, it's not that somebody was messing with it. It's just the
fact that somebody could.
>
> It's good that you are now releasing the memory for the device
> structure
> properly, but this still feels really wrong. What is keeping the
> lifetime of this structure now that the device is removed from it?
It's the most_dev structure of the of USB module (or any other lower
adapter driver), which embeds the most_interface sturcture that
contained the dev struct (which I moved to the private section).
The thing that might be confusing is that the place, where the parent
structure with the device is being allocated, is not the same where
the device actually gets registered with the kernel. These are two
different kernel modules actually.
thanks,
Chris
>
> thanks,
>
> greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-01-15 16:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 15:57 [PATCH RFC v3 0/9] staging: most: move core module out of staging Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 1/9] staging: most: core: fix date in file comment Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 2/9] staging: most: core: use dev_* function for logging Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 3/9] staging: most: core: remove noisy log messages Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 4/9] staging: most: move interface dev to private section Christian Gromm
2020-01-15 12:17 ` Greg KH
2020-01-15 16:04 ` Christian.Gromm [this message]
2020-01-14 15:57 ` [PATCH RFC v3 5/9] staging: most: usb: check for NULL device Christian Gromm
2020-01-15 12:18 ` Greg KH
2020-01-15 15:32 ` Christian.Gromm
2020-01-15 15:37 ` Greg KH
2020-01-14 15:57 ` [PATCH RFC v3 6/9] staging: most: change storage class of struct mostcore Christian Gromm
2020-01-15 12:19 ` Greg KH
2020-01-14 15:57 ` [PATCH RFC v3 7/9] staging: most: move core files out of the staging area Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 8/9] staging: most: Documentation: update ABI description Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 9/9] staging: most: Documentation: move ABI description files out of staging area Christian Gromm
2020-01-15 12:20 ` [PATCH RFC v3 0/9] staging: most: move core module out of staging Greg KH
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=0f71adefe079f5bc1c0ca777c0b8553f46ccea3a.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).