From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Jean Delvare <jdelvare@suse.de>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Dan Carpenter <dan.carpenter@oracle.com>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 WIP 2/4] i2c-parport: modify driver to use new parport device model
Date: Mon, 4 May 2015 12:54:51 +0530 [thread overview]
Message-ID: <20150504072451.GA5912@sudip-PC> (raw)
In-Reply-To: <20150504085858.4209f9ef@endymion.delvare>
On Mon, May 04, 2015 at 08:58:58AM +0200, Jean Delvare wrote:
> On Mon, 4 May 2015 11:10:12 +0530, Sudip Mukherjee wrote:
> > On Sun, May 03, 2015 at 03:33:40PM +0200, Jean Delvare wrote:
> > > On Tue, 28 Apr 2015 17:00:21 +0530, Sudip Mukherjee wrote:
<snip>
> > I didnot get this warning, maybe I need to upgrade my gcc or will
> > W=1 show it?
>
> I see it without W=1, as the message says this type of warning is
> enabled by default (gcc 4.8.1.) The check on const vs. non-const
> pointers is very old so I am very surprised that you don't see it, even
> if your gcc isn't recent.
then maybe I have not looked closely. I will pay attention and look for
it this time. My version is 4.7.3.
>
<snip>
> > remains registered, then what happens to the driver?
>
> This was a key design decision of the (then) new device driver model in
> kernel v2.5 that the lifetime of drivers should be independent from
> the lifetime of device instances. Ideally, devices are even created
> and deleted outside their driver. That works well for enumerated
> devices such as PCI or USB devices. That won't work in your case
> because parallel port devices have no unique ID so they can't be
> enumerated.
>
> Still, the lifetime of devices should be independent from the lifetime
> of the driver. The driver should be registered as long as the module is
> loaded. The devices, however, must be created and deleted dynamically
> whenever the relevant parallel ports appear or disappear from the
> system.
>
> So basically the module's __init function should only register the
> driver, and let the core call back its probe function for every parallel
> port available on the system at that time. And likewise, the __exit
> function should only unregister the driver, and let the core call back
> its remove function for every device that still exists at that point in
> time. This is what the platform bus subsystem does (see for example
> drivers/i2c/busses/i2c-viperboard.c but there are many many others.)
Thanks. This explained many of the doubts I was having. And I have one
more doubt and I need some suggestion for it too.
This current version of the code will register devices like :
If i register i2c-parport0 with parport0 then the sys tree will be:
sys
________|____________
|
parport
_____|_______
| |
parport0 i2c-parport0
|
i2c-parport0
so basically it registers as a subdevice of parport0 and also a device
in the bus. And this is the reason why i needed the device_type.
But i think it is wrong. I think it should have been just:
sys
________|____________
|
parport
_____|_______
|
parport0
|
i2c-parport0
so, which one is actually correct?
Thanks again for that explanation, that really helped a lot.
regards
sudip
>
> > my next WIP will have some changes in the core level also, so I shouldnot
> > add your Tested-by: to it. And I will again request you to check that.
>
> I will do, no problem.
>
> --
> Jean Delvare
> SUSE L3 Support
next prev parent reply other threads:[~2015-05-04 7:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 11:30 [PATCH v4 WIP 1/4] parport: add device-model to parport subsystem Sudip Mukherjee
2015-04-28 11:30 ` [PATCH v4 WIP 2/4] i2c-parport: modify driver to use new parport device model Sudip Mukherjee
2015-05-03 13:33 ` Jean Delvare
2015-05-04 5:40 ` Sudip Mukherjee
2015-05-04 6:58 ` Jean Delvare
2015-05-04 7:24 ` Sudip Mukherjee [this message]
2015-05-04 9:14 ` Jean Delvare
2015-05-03 20:50 ` Jean Delvare
2015-04-28 11:30 ` [PATCH v4 WIP 3/4] paride: " Sudip Mukherjee
2015-04-28 11:30 ` [PATCH v4 WIP 4/4] staging: panel: " Sudip Mukherjee
2015-05-02 14:20 ` [PATCH v4 WIP 1/4] parport: add device-model to parport subsystem Jean Delvare
2015-05-03 6:37 ` Sudip Mukherjee
2015-05-03 7:56 ` Jean Delvare
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=20150504072451.GA5912@sudip-PC \
--to=sudipm.mukherjee@gmail.com \
--cc=dan.carpenter@oracle.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jdelvare@suse.de \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.