linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Victor Ascroft <victorascroft@gmail.com>
To: Mason <mpeg.blue@free.fr>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: Looking for good references for ARM driver development
Date: Fri, 21 Nov 2014 11:30:39 +0530	[thread overview]
Message-ID: <546ED507.1020503@gmail.com> (raw)
In-Reply-To: <546E600F.8020704@free.fr>


On Friday 21 November 2014 03:11 AM, Mason wrote:
> On 19/11/2014 17:57, Victor Ascroft wrote:
>
>> On 11/19/2014 06:20 PM, Mason wrote:
>>
>>> Are there more recent technical references, as good as LDD3, that
>>> cover "modern" aspects of kernel development?
>> The LDD3 is one of the best there is. A fourth edition is supposed
>> to come out sometime next year.
>> http://www.amazon.com/Linux-Device-Drivers-Jessica-McKellar/dp/1449371612
> That's the best news I've heard this week!
> Hope Jonathan gets well and lives happily ever after.
>
>>> How do I "leave device registration for the system infrastructure"?
>>> Where should I put that code?
>>> Is it a good idea to separate device registration and driver registration
>>> in the case of a SoC, where the device is embedded in the SoC and is not
>>> "hot-plugged" (or anything-plugged for that matter, it's just "there").
>> For understanding this you need to understand how the platform infrastructure
>> works and why is it used.
>> http://lwn.net/Articles/448499/
>> http://lwn.net/Articles/448502/
>> and go through some of the relevant drivers.
> More of Jon's (great) work ;-)
> Will definitely read these articles carefully.
>
>>> 3) Why is the function used to "destroy a platform device" named
>>> platform_device_put? Why put?
>>> Put on a list of things to destroy at a later time?
>> This should be more clear once you go through LDD3.
> I'm coming up empty.
> AFAICT, it's unrelated to the _put_user* family of functions.
> I see that it has something to do with ref count decrement.
> [more reading...]
> Something about kref.
> https://lwn.net/Articles/336224/
>
> They mention "put" but not *why* it's called "put".
> Is it related to Dijkstra's P and V for semaphores?
> https://cs.nyu.edu/~yap/classes/os/resources/origin_of_PV.html
> Still confused...
It has been quiet a while since I read LDD3, but, I remember this information
being somewhere in it or may be I am wrong. Not aware if these are related to
the P and V concept for semaphores.

Hmm.. You surprised me, I was not aware of put_user etc. myself. Never seen
them anywhere. I have only used and seen copy_(to/from)_user or may be it's
just that I have not worked, where these are used. I guess these _put_user family
of functions, do not carry out any kind of verification.

Yes, you are right. The platform_device_put has got to with the reference count.
platform_device_put in turn calls put_device and which in turn calls kobject_put.
The reference count for the kobject is decremented. When the reference count
reaches 0 for the kobject, kobject_cleanup is called to free the resources.

You will find good explanation of all this, the Chapter 14 Linux Device Model  of
LDD3. That is one of the best chapters to read in that book.

-Regards

>
> Regards.


      reply	other threads:[~2014-11-21  6:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-19 12:50 Looking for good references for ARM driver development Mason
2014-11-19 15:02 ` Andreas Färber
2014-11-19 16:05   ` Mason
2014-11-20  9:18     ` Viresh Kumar
2014-11-20 14:33     ` Antony Pavlov
2014-11-19 16:57 ` Victor Ascroft
2014-11-19 17:19   ` Mason
2014-11-19 17:30     ` Victor Ascroft
2014-11-20 21:41   ` Mason
2014-11-21  6:00     ` Victor Ascroft [this message]

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=546ED507.1020503@gmail.com \
    --to=victorascroft@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpeg.blue@free.fr \
    /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).