From: Greg KH <gregkh@linuxfoundation.org>
To: Roman Kiryanov <rkir@google.com>
Cc: linux-kernel@vger.kernel.org, Todd Kjos <tkjos@google.com>
Subject: Re: [PATCH v3 06/15] platform: goldfish: pipe: Move memory allocation from probe to init
Date: Tue, 16 Oct 2018 08:27:21 +0200 [thread overview]
Message-ID: <20181016062721.GA882@kroah.com> (raw)
In-Reply-To: <CAOGAQerxP0hsVF2ArpXJ4HrPj=-XKfdqvAdUGoC4xo+sc4UYvw@mail.gmail.com>
On Mon, Oct 15, 2018 at 12:06:12PM -0700, Roman Kiryanov wrote:
> > > probe does not know what memory to allocate. We have several versions
> > > of the driver (with different init) and different versions allocate
> > > different state.
> >
> > I only see one driver here.
>
> It will be added in "PATCH v3 15/15". There will be two init functions
> allocating different states.
I think we are getting our terms confused here.
"init" usually means module_init(), is that what you are referring to
here?
probe means when your bus-specific driver's probe function is called
because the kernel recognizes your hardware as being present.
At module_init time, you should do nothing except register your bus
specific driver.
At probe time, allocate memory all you want, that is the correct point
in time to do it.
So yes, if you have two separate drivers, you will have two separate
init functions, but both of them should just register the bus specific
driver.
> > Why does probe not know what to allocate? That is exactly when the
> > device is bound to the driver, you have _way_ more information than you
> > do at init time.
>
> We have two versions of the driver. Probe asks for the version and
> calls the init function for this version.
> I don't want probe to know everything about all versions.
Why would your probe function know, or care, about versions? That's up
to the driver core. How is your probe function learning about the
"version" to use here?
> > > >, not init time as what
> > > > happens if the hardware is not present yet your driver is loaded?
> > >
> > > init will have to rollback what it allocated.
> >
> > But those resources it will sit there wasted until unload happens. And
> > unload _never_ happens on a system unless you are a developer working on
> > the module.
>
> If probe fails I expect the kernel to release all resources. Is this
> not the case?
You have to clean up after your probe function failing before you return
from it.
thanks,
greg k-h
next prev parent reply other threads:[~2018-10-16 6:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 17:17 [PATCH v3 01/15] platform: goldfish: pipe: Move the file-scope goldfish_interrupt_tasklet variable into the driver state rkir
2018-10-03 17:17 ` [PATCH v3 02/15] platform: goldfish: pipe: Move the file-scope goldfish_pipe_miscdev " rkir
2018-10-03 17:17 ` [PATCH v3 03/15] platform: goldfish: pipe: Move the file-scope goldfish_pipe_dev " rkir
2018-10-03 17:17 ` [PATCH v3 04/15] platform: goldfish: pipe: Call misc_deregister if init fails rkir
2018-10-03 17:17 ` [PATCH v3 05/15] platform: goldfish: pipe: Remove redundant casting rkir
2018-10-03 17:17 ` [PATCH v3 06/15] platform: goldfish: pipe: Move memory allocation from probe to init rkir
2018-10-15 18:34 ` Greg KH
2018-10-15 18:48 ` Roman Kiryanov
2018-10-15 18:56 ` Greg KH
2018-10-15 19:06 ` Roman Kiryanov
2018-10-16 6:27 ` Greg KH [this message]
2018-10-16 20:48 ` Roman Kiryanov
2018-10-03 17:17 ` [PATCH v3 07/15] platform: goldfish: pipe: Return status from "deinit" since "remove" does not do much rkir
2018-10-15 18:36 ` Greg KH
2018-10-15 22:04 ` Roman Kiryanov
2018-10-16 6:30 ` Greg KH
2018-10-03 17:17 ` [PATCH v3 08/15] platform: goldfish: pipe: Add a blank line to separate varibles and code rkir
2018-10-03 17:17 ` [PATCH v3 09/15] platform: goldfish: pipe: Move goldfish_pipe to goldfish_pipe_v2 rkir
2018-10-15 18:38 ` Greg KH
2018-10-15 18:55 ` Roman Kiryanov
2018-10-15 19:01 ` Greg KH
2018-10-15 20:23 ` Roman Kiryanov
2018-10-16 6:29 ` Greg KH
2018-10-16 21:02 ` Roman Kiryanov
2018-10-03 17:17 ` [PATCH v3 10/15] platform: goldfish: pipe: Remove the license boilerplate rkir
2018-10-03 17:17 ` [PATCH v3 11/15] platform: goldfish: pipe: Split the driver to v2 specific and the rest rkir
2018-10-03 17:17 ` [PATCH v3 12/15] platform: goldfish: pipe: Rename the init function (add "v2") rkir
2018-10-03 17:17 ` [PATCH v3 13/15] platform: goldfish: pipe: Add a dedicated constant for the device name rkir
2018-10-03 17:17 ` [PATCH v3 14/15] platform: goldfish: pipe: Rename PIPE_REG to PIPE_V2_REG rkir
2018-10-03 17:17 ` [PATCH v3 15/15] platform: goldfish: pipe: Add the goldfish_pipe_v1 driver rkir
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=20181016062721.GA882@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rkir@google.com \
--cc=tkjos@google.com \
/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