* Re: [PATCH v7 4/6] block: loop: prepare for supporing direct IO
From: Ming Lei @ 2015-07-27 9:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Linux Kernel Mailing List, Justin M. Forbes,
Jeff Moyer, Tejun Heo, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150727084020.GA28336-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Mon, Jul 27, 2015 at 4:40 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>> + /*
>> + * loop block's logical block size is 512, now
>> + * we support direct I/O only if the backing
>> + * block devices' minimize I/O size is 512 and
>> + * the offset is aligned with 512.
>> + */
>> + if (dio) {
>> + if (inode->i_sb->s_bdev &&
>> + bdev_io_min(inode->i_sb->s_bdev) == 512 &&
>> + !(lo->lo_offset & 511))
>
> Why the hardcoded value? I suspect this should be more like:
>
> if (dio && inode->i_sb->s_bdev &&
> (lo->lo_offset & (bdev_io_min(inode->i_sb->s_bdev) - 1)) != 0)
> dio = false;
The above can't work if the backing device has a bigger sector size
(such as 4K), that is why loop's direct-io requires 512 min_io_size of
backing device.
>
>> + blk_mq_freeze_queue(lo->lo_queue);
>> + lo->use_dio = use_dio;
>> + if (use_dio)
>> + lo->lo_flags |= LO_FLAGS_DIRECT_IO;
>> + else
>> + lo->lo_flags &= ~LO_FLAGS_DIRECT_IO;
>> + blk_mq_unfreeze_queue(lo->lo_queue);
>
> Locking?
__loop_update_dio() is only called inside ioctl path, so
mutex of lo->lo_ctl_mutex has been held already.
Thanks,
^ permalink raw reply
* Re: [PATCH v7 4/6] block: loop: prepare for supporing direct IO
From: Christoph Hellwig @ 2015-07-27 9:45 UTC (permalink / raw)
To: Ming Lei
Cc: Christoph Hellwig, Jens Axboe, Linux Kernel Mailing List,
Justin M. Forbes, Jeff Moyer, Tejun Heo, linux-api
In-Reply-To: <CACVXFVOvnVHNtTkt_kiNZu9BuZHZ==EF4y3qXx+Qo=LHoytODQ@mail.gmail.com>
On Mon, Jul 27, 2015 at 05:41:57AM -0400, Ming Lei wrote:
> > Why the hardcoded value? I suspect this should be more like:
> >
> > if (dio && inode->i_sb->s_bdev &&
> > (lo->lo_offset & (bdev_io_min(inode->i_sb->s_bdev) - 1)) != 0)
> > dio = false;
>
> The above can't work if the backing device has a bigger sector size
> (such as 4K), that is why loop's direct-io requires 512 min_io_size of
> backing device.
Why doesn't it work? If the backing device sector size is 4k
and lo_offset is 0 or a multiple of 4k it should allow direct I/O,
and my code sniplet will allow that.
^ permalink raw reply
* Attention: Email ID Owner RE: 2000 - 2015 SCAM VICTIM'S COMPENSATION FROM THE IMF BENIN.
From: Mark Damion @ 2015-07-27 9:48 UTC (permalink / raw)
Attention: Email ID Owner RE: 2000 - 2015 SCAM VICTIM'S COMPENSATION
FROM THE IMF BENIN.
The International Monetary Fund (IMF) is compensating all the scam
victims and your email address was found in the scam victim's list.
This Western Union office has been fully mandated by the IMF to
transfer your compensation to you via Western Union® Money Transfer.
However, we have concluded to affect your own payment through Western
Union® Money Transfer, $5,000 twice daily until the total sum of
$1.800.000 Million is completely transferred to you. We can not be
able to send the payment with your email address alone; thereby we
need your information as to where we will be sending the funds, such
as;
Receiver’s name:................... (Your Full Name)
Address:......................
Country:..................&
Phone number:...................
Copy of your ID ..................
Sex ....................
Age ......................
Reply back to this E-mail: (markdamion46-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) with your full
information. Note that your payment files will be returned to the IMF
within 72 hours if we did not hear from you, this instruction was
given by general official of IMF Benin. We will start the transfer as
soon as we received your information.
Much Oblige,
Mr.Mark Damion
Director Western Union®
Tel; +229-98889902
^ permalink raw reply
* Re: [PATCH v7 4/6] block: loop: prepare for supporing direct IO
From: Ming Lei @ 2015-07-27 9:53 UTC (permalink / raw)
To: Christoph Hellwig, Dave Chinner
Cc: Jens Axboe, Linux Kernel Mailing List, Justin M. Forbes,
Jeff Moyer, Tejun Heo, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150727094530.GA15507-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Mon, Jul 27, 2015 at 5:45 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Mon, Jul 27, 2015 at 05:41:57AM -0400, Ming Lei wrote:
>> > Why the hardcoded value? I suspect this should be more like:
>> >
>> > if (dio && inode->i_sb->s_bdev &&
>> > (lo->lo_offset & (bdev_io_min(inode->i_sb->s_bdev) - 1)) != 0)
>> > dio = false;
>>
>> The above can't work if the backing device has a bigger sector size
>> (such as 4K), that is why loop's direct-io requires 512 min_io_size of
>> backing device.
>
> Why doesn't it work? If the backing device sector size is 4k
> and lo_offset is 0 or a multiple of 4k it should allow direct I/O,
> and my code sniplet will allow that.
Because size has to be 4k aligned too.
And it can't work in the example posted by Dave Chinner:
> I have a 4k sector backing device and a 512 byte sector filesystem
> image. I can't do 512 byte direct IO to the filesystem image, so I
> can't run tools that handle fs images in files using direct Io on
> that file. Create a loop device with the filesystem image, and now I
> can do 512 byte direct IO to the filesystem image, because all that
> direct IO to the filesystem image is now buffered by the loop
> device.
>
> If the loop device does direct io in this situation, the backing
> filesystem rejects direct IO from the loop device because it is not
> sector (4k) sized/aligned. User now swears, shouts and curses you
> from afar.
Thanks,
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 11:00 UTC (permalink / raw)
To: Davidlohr Bueso, Peter Zijlstra
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Thomas Gleixner, Darren Hart,
Carlos O'Donell, Ingo Molnar, Jakub Jelinek,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml,
Arnd Bergmann, Steven Rostedt, Linux API, Torvald Riegel,
Roland McGrath, Darren Hart, Anton Blanchard, Eric Dumazet,
bill o gallmeister, Jan Kiszka, Daniel Wagner, Rich Felker,
Andy Lutomirski, bert hubert, Rusty Russell,
Heinrich Schuchardt <xypron>
In-Reply-To: <1427834205.20009.19.camel-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
Hi David,
On 03/31/2015 10:36 PM, Davidlohr Bueso wrote:
> On Sat, 2015-03-28 at 13:03 +0100, Peter Zijlstra wrote:
>>> If the timeout argument is non-NULL, its contents specify a rel‐
>>> ative timeout for the wait, measured according to the
>>> CLOCK_MONOTONIC clock. (This interval will be rounded up to the
>>> system clock granularity, and kernel scheduling delays mean that
>>> the blocking interval may overrun by a small amount.) If time‐
>>> out is NULL, the call blocks indefinitely.
>>
>> Would it not be better to only state that the wait will not return
>> before the timeout -- unless woken -- and not bother with clock
>> granularity and scheduling delays?
>
> Yeah, similarly we also have this:
>
> FUTEX_PRIVATE_FLAG (since Linux 2.6.22)
> This option bit can be employed with all futex operations. It
> tells the kernel that the futex is process-private and not
> shared with another process (i.e., it is only being used for
> synchronization between threads of the same process). This
> allows the kernel to choose the fast path for validating the
> user-space address and avoids expensive VMA lookups, taking ref‐
> erence counts on file backing store, and so on.
>
> This to me reads a bit too much into the kernel (fastpath, refcnt,
> vmas). Why not just mention that it avoids overhead in the kernel or
> something? I don't recall any manpage mentioning such details, but I
> could be wrong.
Thanks. Agreed. I changed this to
This allows the kernel to make some additional performance optimizations.
> In any case its a nit, the whole doc is pretty good and
> I hope you can merge it soon and then just increment ;)
I ran out of time and energy at a certain point. And also got a little
disheartened that I got more people complaining about groff markup
than actually looked looked at the FIXMEs in the page source :-).
I'll try to reboot the process.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 11:03 UTC (permalink / raw)
To: Rusty Russell, Thomas Gleixner, Darren Hart
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Carlos O'Donell,
Ingo Molnar, Jakub Jelinek,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml,
Davidlohr Bueso, Arnd Bergmann, Steven Rostedt, Peter Zijlstra,
Linux API, Torvald Riegel, Roland McGrath, Darren Hart,
Anton Blanchard, Eric Dumazet, bill o gallmeister, Jan Kiszka,
Daniel Wagner, Rich Felker, Andy Lutomirski, bert hubert,
Heinrich Schuchardt
In-Reply-To: <871tk6os1y.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
On 03/31/2015 03:48 AM, Rusty Russell wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> When executing a futex operation that requests to block a thread,
>> the kernel will only block if the futex word has the value that the
>> calling thread supplied as expected value.
>> The load from the futex word, the comparison with
>> the expected value,
>> and the actual blocking will happen atomically and totally
>> ordered with respect to concurrently executing futex operations
>> on the same futex word,
>> such as operations that wake threads blocked on this futex word.
>> Thus, the futex word is used to connect the synchronization in user spac
>
> Missing 'e' in "space".
Already fixed.
>> .\" FIXME Please confirm that the following is correct:
>> No guarantee is provided about which waiters are awoken
>> (e.g., a waiter with a higher scheduling priority is not guaranteed
>> to be awoken in preference to a waiter with a lower priority).
>
> This is true.
Thanks! FIXME removed.
Cheers,
Michael
> I didn't read the rest, as that stuff was all written by others.
> Documenting them is pretty heroic; good job!
>
> Thanks,
> Rusty.
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 11:10 UTC (permalink / raw)
To: Torvald Riegel, Thomas Gleixner
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Peter Zijlstra, Darren Hart,
Carlos O'Donell, Ingo Molnar, Jakub Jelinek,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml,
Davidlohr Bueso, Arnd Bergmann, Steven Rostedt, Linux API,
Roland McGrath, Darren Hart, Anton Blanchard, Eric Dumazet,
bill o gallmeister, Jan Kiszka, Daniel Wagner, Rich Felker,
Andy Lutomirski, bert hubert, Rusty Russell,
Heinrich Schuchardt <xypro>
In-Reply-To: <1429093725.2909.29.camel-I2ZjUw8blINjztcc/or7kQ@public.gmane.org>
On 04/15/2015 12:28 PM, Torvald Riegel wrote:
> On Tue, 2015-04-14 at 23:40 +0200, Thomas Gleixner wrote:
>> On Sat, 28 Mar 2015, Peter Zijlstra wrote:
>>> On Sat, Mar 28, 2015 at 09:53:21AM +0100, Michael Kerrisk (man-pages) wrote:
>>>> So, please take a look at the page below. At this point,
>>>> I would most especially appreciate help with the FIXMEs.
>>>
>>> For people who cannot read that troff gibberish (me)..
>>
>> Ditto :)
>>
>>> NOTES
>>> Glibc does not provide a wrapper for this system call; call it using
>>> syscall(2).
>>
>> You might mention that pthread_mutex, pthread_condvar interfaces are
>> high level wrappers for the syscall and recommended to be used for
>> normal use cases. IIRC unnamed semaphores are implemented with futexes
>> as well.
>
> If we add this, I'd rephrase it to something like that there are
> high-level programming abstractions such as the pthread_condvar
> interfaces or semaphores that are implemented using the syscall and that
> are typically a better fit for normal use cases. I'd consider only the
> condvars as something like a wrapper, or targeting a similar use case.
I added this under NOTES:
Various higher-level programming abstractions are implemented via
futexes, including POSIX threads mutexes and condition variables,
as well as POSIX semaphores.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 11:10 UTC (permalink / raw)
To: Davidlohr Bueso, Peter Zijlstra
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Thomas Gleixner, Darren Hart,
Carlos O'Donell, Ingo Molnar, Jakub Jelinek,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml,
Arnd Bergmann, Steven Rostedt, Linux API, Torvald Riegel,
Roland McGrath, Darren Hart, Anton Blanchard, Eric Dumazet,
bill o gallmeister, Jan Kiszka, Daniel Wagner, Rich Felker,
Andy Lutomirski, bert hubert, Rusty Russell,
Heinrich Schuchardt <xypron>
In-Reply-To: <1427813146.20009.2.camel-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
Hi David,
On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
> On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>
>> The condition is represented by the futex word, which is an address in
>> memory supplied to the futex() system call, and the value at this mem‐
>> ory location. (While the virtual addresses for the same memory in sep‐
>> arate processes may not be equal, the kernel maps them internally so
>> that the same memory mapped in different locations will correspond for
>> futex() calls.)
>>
>> When executing a futex operation that requests to block a thread, the
>> kernel will only block if the futex word has the value that the calling
>
> Given the use of "word", you should probably state right away that
> futexes are only 32bit.
So, I made the opening sentence here:
The condition is represented by the futex word, which is an
address in memory supplied to the futex() system call, and the
32-bit value at this memory location.
Okay?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 11:10 UTC (permalink / raw)
To: Pavel Machek, Peter Zijlstra
Cc: mtk.manpages, Thomas Gleixner, Darren Hart, Carlos O'Donell,
Ingo Molnar, Jakub Jelinek, linux-man@vger.kernel.org, lkml,
Davidlohr Bueso, Arnd Bergmann, Steven Rostedt, Linux API,
Torvald Riegel, Roland McGrath, Darren Hart, Anton Blanchard,
Eric Dumazet, bill o gallmeister, Jan Kiszka, Daniel Wagner,
Rich Felker, Andy Lutomirski, bert hubert, Rusty Russell
In-Reply-To: <20150427203705.GE29351@xo-6d-61-c0.localdomain>
Hello Pavel,
On 04/27/2015 10:37 PM, Pavel Machek wrote:
> Hi!
>
>> The FUTEX_WAIT_OP operation is equivalent to execute the follow???
>> ing code atomically and totally ordered with respect to other
>> futex operations on any of the two supplied futex words:
>
> "to executing"?
Yep. Fixed.
>> The operation and comparison that are to be performed are
>> encoded in the bits of the argument val3. Pictorially, the
>> encoding is:
>>
>> +---+---+-----------+-----------+
>> |op |cmp| oparg | cmparg |
>> +---+---+-----------+-----------+
>> 4 4 12 12 <== # of bits
>>
>
> :-)
>
>> RETURN VALUE
>> In the event of an error, all operations return -1 and set errno to
>> indicate the cause of the error. The return value on success depends
>> on the operation, as described in the following list:
>
> Did you say (at the begining) that there is no glibc wrapper?
Yes, this could be clearer. I changed it to
RETURN VALUE
In the event of an error (and assuming that futex() was invoked
via syscall(2)), all operations return -1 and set errno to indi‐
cate the cause of the error.
>> EINVAL The operation in futex_op is one of those that employs a time???
>> out, but the supplied timeout argument was invalid (tv_sec was
>> less than zero, or tv_nsec was not less than 1000,000,000).
>
> 1,000...?
Fixed.
Thanks for the comments!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: Revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 11:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mtk.manpages, Thomas Gleixner, Darren Hart, Carlos O'Donell,
Ingo Molnar, Jakub Jelinek, linux-man@vger.kernel.org, lkml,
Davidlohr Bueso, Arnd Bergmann, Steven Rostedt, Linux API,
Torvald Riegel, Roland McGrath, Darren Hart, Anton Blanchard,
Eric Dumazet, bill o gallmeister, Jan Kiszka, Daniel Wagner,
Rich Felker, Andy Lutomirski, bert hubert, Rusty Russell
In-Reply-To: <20150328120337.GB32047@worktop.ger.corp.intel.com>
Hi Peter,
On 03/28/2015 01:03 PM, Peter Zijlstra wrote:
> On Sat, Mar 28, 2015 at 12:47:25PM +0100, Peter Zijlstra wrote:
>> FUTEX_WAIT (since Linux 2.6.0)
>> This operation tests that the value at the futex word pointed to
>> by the address uaddr still contains the expected value val, and
>> if so, then sleeps awaiting FUTEX_WAKE on the futex word. The
>> load of the value of the futex word is an atomic memory access
>> (i.e., using atomic machine instructions of the respective
>> architecture). This load, the comparison with the expected
>> value, and starting to sleep are performed atomically and
>> totally ordered with respect to other futex operations on the
>> same futex word. If the thread starts to sleep, it is consid‐
>> ered a waiter on this futex word. If the futex value does not
>> match val, then the call fails immediately with the error
>> EAGAIN.
>>
>> The purpose of the comparison with the expected value is to pre‐
>> vent lost wake-ups: If another thread changed the value of the
>> futex word after the calling thread decided to block based on
>> the prior value, and if the other thread executed a FUTEX_WAKE
>> operation (or similar wake-up) after the value change and before
>> this FUTEX_WAIT operation, then the latter will observe the
>> value change and will not start to sleep.
>>
>> If the timeout argument is non-NULL, its contents specify a rel‐
>> ative timeout for the wait, measured according to the
>> CLOCK_MONOTONIC clock. (This interval will be rounded up to the
>> system clock granularity, and kernel scheduling delays mean that
>> the blocking interval may overrun by a small amount.) If time‐
>> out is NULL, the call blocks indefinitely.
>
> Would it not be better to only state that the wait will not return
> before the timeout -- unless woken -- and not bother with clock
> granularity and scheduling delays?
Many of the pages that talk about system calls that have timeouts
carry similar language, since people often have confusions about what time
timeout (e.g., that it's an upper limit, not a minimum; or that it's precise
to some very small granularity). Why do you think the language here is a
problem?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* [PATCH v9 0/9] Add simple NVMEM Framework via regmap.
From: Srinivas Kandagatla @ 2015-07-27 11:12 UTC (permalink / raw)
To: khilman-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
mporter-OWPKS81ov/FWk0Htik3J/w, stefan.wahren-eS4NqCHxEME,
wxt-TNX95d0MmH7DzftRWevZcw, Srinivas Kandagatla
Hi Greg/Kevin,
This patchset adds a new simple NVMEM framework to kernel, and it is tested
with various drivers like "QCOM thermal sensors", "QCOM cpr driver",
"begal bone cape manager" and few more on the way.
Can you please consider this as 4.3 material, AFAIK there are more than 3 drivers
depending on this framework which are wating since last 2 merge windows.
Should these patches go via ARM-SOC tree or via Greg's tree?
Thankyou all for providing inputs and comments on previous versions of this
patchset. Here is the v9 of the patchset addressing all the issues raised as
part of previous versions review.
Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they
all had to duplicate pretty much the same code to register a sysfs file, allow
in-kernel users to access the content of the devices they were driving, etc.
This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.
Introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs.
After learning few things about QCOM qfprom and other eeprom/efuses, which
has packed fields at bit level. Which makes it important to add support to
such memories. This version adds support to this type of non volatile
memories by adding support to bit level nvmem-cells.
Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.
patch 1-4 Introduces the NVMEM framework.
Patch 5-6 Adds Qualcomm specific qfprom driver.
Patch 7 migrates an existing driver to nvmem framework.
Patch 8 adds entry in MAINTAINERS.
Its also possible to migrate other nvmem drivers to this framework, and I think
some of them already posted patches based on this framework.
Providers APIs:
nvmem_register/unregister();
Consumers APIs:
Cell based apis for both DT/Non-DT:
nvmem_cell_get()/nvmem_cell_put();
devm_nvmem_cell_get()/devm_nvmem_cell_put();
of_nvmem_cell_get()
nvmem_cell_read()/nvmem_cell_write();
Raw byte access apis for both DT/non-DT.
nvmem_device_get()/nvmem_device_put()
devm_nvmem_device_get()/nvmem_device_put()
of_nvmem_device_get()
nvmem_device_read()/nvmem_device_write();
nvmem_device_cell_read()/nvmem_device_cell_write();
Device Tree:
/* Provider */
qfprom: qfprom@00700000 {
...
/* Data cells */
tsens_calibration: calib@404 {
reg = <0x404 0x10>;
};
tsens_calibration_bckp: calib_bckp@504 {
reg = <0x504 0x11>;
bits = <6 128>
};
pvs_version: pvs-version@6 {
reg = <0x6 0x2>
bit-offset = 7;
bits = <7 2>
};
speed_bin: speed-bin@c{
reg = <0xc 0x1>;
bits = <2 3>;
};
...
};
/* Consumer */
tsens {
...
nvmem-cells = <&tsens_calibration>;
nvmem-cell-names = "calibration";
};
userspace interface: binary file in /sys/bus/nvmem/devices/*/nvmem
ex:
hexdump /sys/bus/nvmem/devices/qfprom0/nvmem
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00
0000000 0000 0000 0000 0000 0000 0000 0000 0000
...
*
0001000
Changes since v8 (https://lkml.org/lkml/2015/7/20/352)
* remove un-necessary header from qfprom, spotted by Stephen Boyd.
* moved to usage of kcalloc as suggested by Stephen Boyd.
* used u32 instead of int for cell sizes, suggested by Stefan Wahren
* Fixed possible null pointer access, spotted by Stephen Boyd.
* replaced orignal adding of device randomness in sunxi driver,
spotted by Stefan Wahren.
Changes since v7 (https://lwn.net/Articles/650734/)
* Fixed various style and documentation reated comments
from Stephen Boyd, Stephen Wahren and Joe Perches.
* Fixed read-only flag as suggested by Philipp Zabel
* Changed bit level bindings as suggesed by Rob Herring.
(Removed long change log to make it readable.)
Thanks,
srini
Maxime Ripard (1):
nvmem: sunxi: Move the SID driver to the nvmem framework
Srinivas Kandagatla (8):
nvmem: Add a simple NVMEM framework for nvmem providers
nvmem: Add a simple NVMEM framework for consumers
nvmem: Add nvmem_device based consumer apis.
nvmem: Add bindings for simple nvmem framework
Documentation: nvmem: add nvmem api level and how-to doc
nvmem: qfprom: Add Qualcomm QFPROM support.
nvmem: qfprom: Add bindings for qfprom
nvmem: Add to MAINTAINERS for nvmem framework
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 -
.../bindings/misc/allwinner,sunxi-sid.txt | 17 -
.../bindings/nvmem/allwinner,sunxi-sid.txt | 21 +
Documentation/devicetree/bindings/nvmem/nvmem.txt | 80 ++
Documentation/devicetree/bindings/nvmem/qfprom.txt | 35 +
Documentation/nvmem/nvmem.txt | 152 +++
MAINTAINERS | 9 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/misc/eeprom/Kconfig | 13 -
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c | 156 ---
drivers/nvmem/Kconfig | 39 +
drivers/nvmem/Makefile | 12 +
drivers/nvmem/core.c | 1083 ++++++++++++++++++++
drivers/nvmem/qfprom.c | 85 ++
drivers/nvmem/sunxi_sid.c | 171 ++++
include/linux/nvmem-consumer.h | 157 +++
include/linux/nvmem-provider.h | 47 +
19 files changed, 1894 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
delete mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/qfprom.txt
create mode 100644 Documentation/nvmem/nvmem.txt
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
create mode 100644 drivers/nvmem/Kconfig
create mode 100644 drivers/nvmem/Makefile
create mode 100644 drivers/nvmem/core.c
create mode 100644 drivers/nvmem/qfprom.c
create mode 100644 drivers/nvmem/sunxi_sid.c
create mode 100644 include/linux/nvmem-consumer.h
create mode 100644 include/linux/nvmem-provider.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v9 1/9] nvmem: Add a simple NVMEM framework for nvmem providers
From: Srinivas Kandagatla @ 2015-07-27 11:13 UTC (permalink / raw)
To: khilman-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
mporter-OWPKS81ov/FWk0Htik3J/w, stefan.wahren-eS4NqCHxEME,
wxt-TNX95d0MmH7DzftRWevZcw, Srinivas Kandagatla, Maxime Ripard
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds just providers part of the framework just to enable easy
review.
Up until now, NVMEM drivers like eeprom were stored in drivers/misc,
where they all had to duplicate pretty much the same code to register
a sysfs file, allow in-kernel users to access the content of the devices
they were driving, etc.
This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data
they require (MAC Addresses, SoC/Revision ID, part numbers, and so on)
from the nvmems.
Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Tested-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
---
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/nvmem/Kconfig | 13 ++
drivers/nvmem/Makefile | 6 +
drivers/nvmem/core.c | 406 +++++++++++++++++++++++++++++++++++++++++
include/linux/nvmem-consumer.h | 23 +++
include/linux/nvmem-provider.h | 47 +++++
7 files changed, 498 insertions(+)
create mode 100644 drivers/nvmem/Kconfig
create mode 100644 drivers/nvmem/Makefile
create mode 100644 drivers/nvmem/core.c
create mode 100644 include/linux/nvmem-consumer.h
create mode 100644 include/linux/nvmem-provider.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 6e973b8..4e2e6aa 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -184,4 +184,6 @@ source "drivers/android/Kconfig"
source "drivers/nvdimm/Kconfig"
+source "drivers/nvmem/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index b64b49f..4c270f5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
obj-$(CONFIG_ANDROID) += android/
+obj-$(CONFIG_NVMEM) += nvmem/
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
new file mode 100644
index 0000000..de90c82
--- /dev/null
+++ b/drivers/nvmem/Kconfig
@@ -0,0 +1,13 @@
+menuconfig NVMEM
+ tristate "NVMEM Support"
+ select REGMAP
+ help
+ Support for NVMEM(Non Volatile Memory) devices like EEPROM, EFUSES...
+
+ This framework is designed to provide a generic interface to NVMEM
+ from both the Linux Kernel and the userspace.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem_core.
+
+ If unsure, say no.
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
new file mode 100644
index 0000000..6df2c69
--- /dev/null
+++ b/drivers/nvmem/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for nvmem drivers.
+#
+
+obj-$(CONFIG_NVMEM) += nvmem_core.o
+nvmem_core-y := core.o
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
new file mode 100644
index 0000000..2b02491
--- /dev/null
+++ b/drivers/nvmem/core.c
@@ -0,0 +1,406 @@
+/*
+ * nvmem framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * Copyright (C) 2013 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/export.h>
+#include <linux/fs.h>
+#include <linux/idr.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+struct nvmem_device {
+ const char *name;
+ struct regmap *regmap;
+ struct module *owner;
+ struct device dev;
+ int stride;
+ int word_size;
+ int ncells;
+ int id;
+ int users;
+ size_t size;
+ bool read_only;
+};
+
+struct nvmem_cell {
+ const char *name;
+ int offset;
+ int bytes;
+ int bit_offset;
+ int nbits;
+ struct nvmem_device *nvmem;
+ struct list_head node;
+};
+
+static DEFINE_MUTEX(nvmem_mutex);
+static DEFINE_IDA(nvmem_ida);
+
+static LIST_HEAD(nvmem_cells);
+static DEFINE_MUTEX(nvmem_cells_mutex);
+
+#define to_nvmem_device(d) container_of(d, struct nvmem_device, dev)
+
+static ssize_t bin_attr_nvmem_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t pos, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct nvmem_device *nvmem = to_nvmem_device(dev);
+ int rc;
+
+ /* Stop the user from reading */
+ if (pos > nvmem->size)
+ return 0;
+
+ if (pos + count > nvmem->size)
+ count = nvmem->size - pos;
+
+ count = round_down(count, nvmem->word_size);
+
+ rc = regmap_raw_read(nvmem->regmap, pos, buf, count);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return count;
+}
+
+static ssize_t bin_attr_nvmem_write(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t pos, size_t count)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct nvmem_device *nvmem = to_nvmem_device(dev);
+ int rc;
+
+ /* Stop the user from writing */
+ if (pos > nvmem->size)
+ return 0;
+
+ if (pos + count > nvmem->size)
+ count = nvmem->size - pos;
+
+ count = round_down(count, nvmem->word_size);
+
+ rc = regmap_raw_write(nvmem->regmap, pos, buf, count);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return count;
+}
+
+/* default read/write permissions */
+static struct bin_attribute bin_attr_rw_nvmem = {
+ .attr = {
+ .name = "nvmem",
+ .mode = S_IWUSR | S_IRUGO,
+ },
+ .read = bin_attr_nvmem_read,
+ .write = bin_attr_nvmem_write,
+};
+
+static struct bin_attribute *nvmem_bin_rw_attributes[] = {
+ &bin_attr_rw_nvmem,
+ NULL,
+};
+
+static const struct attribute_group nvmem_bin_rw_group = {
+ .bin_attrs = nvmem_bin_rw_attributes,
+};
+
+static const struct attribute_group *nvmem_rw_dev_groups[] = {
+ &nvmem_bin_rw_group,
+ NULL,
+};
+
+/* read only permission */
+static struct bin_attribute bin_attr_ro_nvmem = {
+ .attr = {
+ .name = "nvmem",
+ .mode = S_IRUGO,
+ },
+ .read = bin_attr_nvmem_read,
+};
+
+static struct bin_attribute *nvmem_bin_ro_attributes[] = {
+ &bin_attr_ro_nvmem,
+ NULL,
+};
+
+static const struct attribute_group nvmem_bin_ro_group = {
+ .bin_attrs = nvmem_bin_ro_attributes,
+};
+
+static const struct attribute_group *nvmem_ro_dev_groups[] = {
+ &nvmem_bin_ro_group,
+ NULL,
+};
+
+static void nvmem_release(struct device *dev)
+{
+ struct nvmem_device *nvmem = to_nvmem_device(dev);
+
+ ida_simple_remove(&nvmem_ida, nvmem->id);
+ kfree(nvmem);
+}
+
+static const struct device_type nvmem_provider_type = {
+ .release = nvmem_release,
+};
+
+static struct bus_type nvmem_bus_type = {
+ .name = "nvmem",
+};
+
+static int of_nvmem_match(struct device *dev, void *nvmem_np)
+{
+ return dev->of_node == nvmem_np;
+}
+
+static struct nvmem_device *of_nvmem_find(struct device_node *nvmem_np)
+{
+ struct device *d;
+
+ if (!nvmem_np)
+ return NULL;
+
+ d = bus_find_device(&nvmem_bus_type, NULL, nvmem_np, of_nvmem_match);
+
+ if (!d)
+ return NULL;
+
+ return to_nvmem_device(d);
+}
+
+static struct nvmem_cell *nvmem_find_cell(const char *cell_id)
+{
+ struct nvmem_cell *p;
+
+ list_for_each_entry(p, &nvmem_cells, node)
+ if (p && !strcmp(p->name, cell_id))
+ return p;
+
+ return NULL;
+}
+
+static void nvmem_cell_drop(struct nvmem_cell *cell)
+{
+ mutex_lock(&nvmem_cells_mutex);
+ list_del(&cell->node);
+ mutex_unlock(&nvmem_cells_mutex);
+ kfree(cell);
+}
+
+static void nvmem_device_remove_all_cells(const struct nvmem_device *nvmem)
+{
+ struct nvmem_cell *cell;
+ struct list_head *p, *n;
+
+ list_for_each_safe(p, n, &nvmem_cells) {
+ cell = list_entry(p, struct nvmem_cell, node);
+ if (cell->nvmem == nvmem)
+ nvmem_cell_drop(cell);
+ }
+}
+
+static void nvmem_cell_add(struct nvmem_cell *cell)
+{
+ mutex_lock(&nvmem_cells_mutex);
+ list_add_tail(&cell->node, &nvmem_cells);
+ mutex_unlock(&nvmem_cells_mutex);
+}
+
+static int nvmem_cell_info_to_nvmem_cell(struct nvmem_device *nvmem,
+ const struct nvmem_cell_info *info,
+ struct nvmem_cell *cell)
+{
+ cell->nvmem = nvmem;
+ cell->offset = info->offset;
+ cell->bytes = info->bytes;
+ cell->name = info->name;
+
+ cell->bit_offset = info->bit_offset;
+ cell->nbits = info->nbits;
+
+ if (cell->nbits)
+ cell->bytes = DIV_ROUND_UP(cell->nbits + cell->bit_offset,
+ BITS_PER_BYTE);
+
+ if (!IS_ALIGNED(cell->offset, nvmem->stride)) {
+ dev_err(&nvmem->dev,
+ "cell %s unaligned to nvmem stride %d\n",
+ cell->name, nvmem->stride);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int nvmem_add_cells(struct nvmem_device *nvmem,
+ const struct nvmem_config *cfg)
+{
+ struct nvmem_cell **cells;
+ const struct nvmem_cell_info *info = cfg->cells;
+ int i, rval;
+
+ cells = kcalloc(cfg->ncells, sizeof(*cells), GFP_KERNEL);
+ if (!cells)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->ncells; i++) {
+ cells[i] = kzalloc(sizeof(**cells), GFP_KERNEL);
+ if (!cells[i]) {
+ rval = -ENOMEM;
+ goto err;
+ }
+
+ rval = nvmem_cell_info_to_nvmem_cell(nvmem, &info[i], cells[i]);
+ if (IS_ERR_VALUE(rval)) {
+ kfree(cells[i]);
+ goto err;
+ }
+
+ nvmem_cell_add(cells[i]);
+ }
+
+ nvmem->ncells = cfg->ncells;
+ /* remove tmp array */
+ kfree(cells);
+
+ return 0;
+err:
+ while (--i)
+ nvmem_cell_drop(cells[i]);
+
+ return rval;
+}
+
+/**
+ * nvmem_register() - Register a nvmem device for given nvmem_config.
+ * Also creates an binary entry in /sys/bus/nvmem/devices/dev-name/nvmem
+ *
+ * @config: nvmem device configuration with which nvmem device is created.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer to nvmem_device
+ * on success.
+ */
+
+struct nvmem_device *nvmem_register(const struct nvmem_config *config)
+{
+ struct nvmem_device *nvmem;
+ struct device_node *np;
+ struct regmap *rm;
+ int rval;
+
+ if (!config->dev)
+ return ERR_PTR(-EINVAL);
+
+ rm = dev_get_regmap(config->dev, NULL);
+ if (!rm) {
+ dev_err(config->dev, "Regmap not found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
+ if (!nvmem)
+ return ERR_PTR(-ENOMEM);
+
+ rval = ida_simple_get(&nvmem_ida, 0, 0, GFP_KERNEL);
+ if (rval < 0) {
+ kfree(nvmem);
+ return ERR_PTR(rval);
+ }
+
+ nvmem->id = rval;
+ nvmem->regmap = rm;
+ nvmem->owner = config->owner;
+ nvmem->stride = regmap_get_reg_stride(rm);
+ nvmem->word_size = regmap_get_val_bytes(rm);
+ nvmem->size = regmap_get_max_register(rm) + nvmem->stride;
+ nvmem->dev.type = &nvmem_provider_type;
+ nvmem->dev.bus = &nvmem_bus_type;
+ nvmem->dev.parent = config->dev;
+ np = config->dev->of_node;
+ nvmem->dev.of_node = np;
+ dev_set_name(&nvmem->dev, "%s%d",
+ config->name ? : "nvmem", config->id);
+
+ nvmem->read_only = of_property_read_bool(np, "read-only") |
+ config->read_only;
+
+ nvmem->dev.groups = nvmem->read_only ? nvmem_ro_dev_groups :
+ nvmem_rw_dev_groups;
+
+ device_initialize(&nvmem->dev);
+
+ dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name);
+
+ rval = device_add(&nvmem->dev);
+ if (rval) {
+ ida_simple_remove(&nvmem_ida, nvmem->id);
+ kfree(nvmem);
+ return ERR_PTR(rval);
+ }
+
+ if (config->cells)
+ nvmem_add_cells(nvmem, config);
+
+ return nvmem;
+}
+EXPORT_SYMBOL_GPL(nvmem_register);
+
+/**
+ * nvmem_unregister() - Unregister previously registered nvmem device
+ *
+ * @nvmem: Pointer to previously registered nvmem device.
+ *
+ * Return: Will be an negative on error or a zero on success.
+ */
+int nvmem_unregister(struct nvmem_device *nvmem)
+{
+ if (nvmem->users)
+ return -EBUSY;
+
+ nvmem_device_remove_all_cells(nvmem);
+ device_del(&nvmem->dev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(nvmem_unregister);
+
+static int __init nvmem_init(void)
+{
+ return bus_register(&nvmem_bus_type);
+}
+
+static void __exit nvmem_exit(void)
+{
+ bus_unregister(&nvmem_bus_type);
+}
+
+subsys_initcall(nvmem_init);
+module_exit(nvmem_exit);
+
+MODULE_AUTHOR("Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org");
+MODULE_DESCRIPTION("nvmem Driver Core");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
new file mode 100644
index 0000000..1e9e767
--- /dev/null
+++ b/include/linux/nvmem-consumer.h
@@ -0,0 +1,23 @@
+/*
+ * nvmem framework consumer.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * Copyright (C) 2013 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _LINUX_NVMEM_CONSUMER_H
+#define _LINUX_NVMEM_CONSUMER_H
+
+struct nvmem_cell_info {
+ const char *name;
+ unsigned int offset;
+ unsigned int bytes;
+ unsigned int bit_offset;
+ unsigned int nbits;
+};
+
+#endif /* ifndef _LINUX_NVMEM_CONSUMER_H */
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
new file mode 100644
index 0000000..0b68caf
--- /dev/null
+++ b/include/linux/nvmem-provider.h
@@ -0,0 +1,47 @@
+/*
+ * nvmem framework provider.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * Copyright (C) 2013 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _LINUX_NVMEM_PROVIDER_H
+#define _LINUX_NVMEM_PROVIDER_H
+
+struct nvmem_device;
+struct nvmem_cell_info;
+
+struct nvmem_config {
+ struct device *dev;
+ const char *name;
+ int id;
+ struct module *owner;
+ const struct nvmem_cell_info *cells;
+ int ncells;
+ bool read_only;
+};
+
+#if IS_ENABLED(CONFIG_NVMEM)
+
+struct nvmem_device *nvmem_register(const struct nvmem_config *cfg);
+int nvmem_unregister(struct nvmem_device *nvmem);
+
+#else
+
+static inline struct nvmem_device *nvmem_register(const struct nvmem_config *c)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline int nvmem_unregister(struct nvmem_device *nvmem)
+{
+ return -ENOSYS;
+}
+
+#endif /* CONFIG_NVMEM */
+
+#endif /* ifndef _LINUX_NVMEM_PROVIDER_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v9 2/9] nvmem: Add a simple NVMEM framework for consumers
From: Srinivas Kandagatla @ 2015-07-27 11:13 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla, Maxime Ripard
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds just consumers part of the framework just to enable easy
review.
Up until now, nvmem drivers were stored in drivers/misc, where they all
had to duplicate pretty much the same code to register a sysfs file,
allow in-kernel users to access the content of the devices they were
driving, etc.
This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.
This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data they
require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from
the nvmems.
Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/nvmem/core.c | 421 ++++++++++++++++++++++++++++++++++++++++-
include/linux/nvmem-consumer.h | 61 ++++++
2 files changed, 481 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 2b02491..8c16ae2 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -377,8 +377,12 @@ EXPORT_SYMBOL_GPL(nvmem_register);
*/
int nvmem_unregister(struct nvmem_device *nvmem)
{
- if (nvmem->users)
+ mutex_lock(&nvmem_mutex);
+ if (nvmem->users) {
+ mutex_unlock(&nvmem_mutex);
return -EBUSY;
+ }
+ mutex_unlock(&nvmem_mutex);
nvmem_device_remove_all_cells(nvmem);
device_del(&nvmem->dev);
@@ -387,6 +391,421 @@ int nvmem_unregister(struct nvmem_device *nvmem)
}
EXPORT_SYMBOL_GPL(nvmem_unregister);
+static struct nvmem_device *__nvmem_device_get(struct device_node *np,
+ struct nvmem_cell **cellp,
+ const char *cell_id)
+{
+ struct nvmem_device *nvmem = NULL;
+
+ mutex_lock(&nvmem_mutex);
+
+ if (np) {
+ nvmem = of_nvmem_find(np);
+ if (!nvmem) {
+ mutex_unlock(&nvmem_mutex);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+ } else {
+ struct nvmem_cell *cell = nvmem_find_cell(cell_id);
+
+ if (cell) {
+ nvmem = cell->nvmem;
+ *cellp = cell;
+ }
+
+ if (!nvmem) {
+ mutex_unlock(&nvmem_mutex);
+ return ERR_PTR(-ENOENT);
+ }
+ }
+
+ nvmem->users++;
+ mutex_unlock(&nvmem_mutex);
+
+ if (!try_module_get(nvmem->owner)) {
+ dev_err(&nvmem->dev,
+ "could not increase module refcount for cell %s\n",
+ nvmem->name);
+
+ mutex_lock(&nvmem_mutex);
+ nvmem->users--;
+ mutex_unlock(&nvmem_mutex);
+
+ return ERR_PTR(-EINVAL);
+ }
+
+ return nvmem;
+}
+
+static void __nvmem_device_put(struct nvmem_device *nvmem)
+{
+ module_put(nvmem->owner);
+ mutex_lock(&nvmem_mutex);
+ nvmem->users--;
+ mutex_unlock(&nvmem_mutex);
+}
+
+static struct nvmem_cell *nvmem_cell_get_from_list(const char *cell_id)
+{
+ struct nvmem_cell *cell = NULL;
+ struct nvmem_device *nvmem;
+
+ nvmem = __nvmem_device_get(NULL, &cell, cell_id);
+ if (IS_ERR(nvmem))
+ return ERR_CAST(nvmem);
+
+ return cell;
+}
+
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+/**
+ * of_nvmem_cell_get() - Get a nvmem cell from given device node and cell id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name from nvmem-cell-names property.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell. The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+ const char *name)
+{
+ struct device_node *cell_np, *nvmem_np;
+ struct nvmem_cell *cell;
+ struct nvmem_device *nvmem;
+ const __be32 *addr;
+ int rval, len, index;
+
+ index = of_property_match_string(np, "nvmem-cell-names", name);
+
+ cell_np = of_parse_phandle(np, "nvmem-cells", index);
+ if (!cell_np)
+ return ERR_PTR(-EINVAL);
+
+ nvmem_np = of_get_next_parent(cell_np);
+ if (!nvmem_np)
+ return ERR_PTR(-EINVAL);
+
+ nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
+ if (IS_ERR(nvmem))
+ return ERR_CAST(nvmem);
+
+ addr = of_get_property(cell_np, "reg", &len);
+ if (!addr || (len < 2 * sizeof(u32))) {
+ dev_err(&nvmem->dev, "nvmem: invalid reg on %s\n",
+ cell_np->full_name);
+ rval = -EINVAL;
+ goto err_mem;
+ }
+
+ cell = kzalloc(sizeof(*cell), GFP_KERNEL);
+ if (!cell) {
+ rval = -ENOMEM;
+ goto err_mem;
+ }
+
+ cell->nvmem = nvmem;
+ cell->offset = be32_to_cpup(addr++);
+ cell->bytes = be32_to_cpup(addr);
+ cell->name = cell_np->name;
+
+ addr = of_get_property(cell_np, "bits", &len);
+ if (addr && len == (2 * sizeof(u32))) {
+ cell->bit_offset = be32_to_cpup(addr++);
+ cell->nbits = be32_to_cpup(addr);
+ }
+
+ if (cell->nbits)
+ cell->bytes = DIV_ROUND_UP(cell->nbits + cell->bit_offset,
+ BITS_PER_BYTE);
+
+ if (!IS_ALIGNED(cell->offset, nvmem->stride)) {
+ dev_err(&nvmem->dev,
+ "cell %s unaligned to nvmem stride %d\n",
+ cell->name, nvmem->stride);
+ rval = -EINVAL;
+ goto err_sanity;
+ }
+
+ nvmem_cell_add(cell);
+
+ return cell;
+
+err_sanity:
+ kfree(cell);
+
+err_mem:
+ __nvmem_device_put(nvmem);
+
+ return ERR_PTR(rval);
+}
+EXPORT_SYMBOL_GPL(of_nvmem_cell_get);
+#endif
+
+/**
+ * nvmem_cell_get() - Get nvmem cell of device form a given cell name
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem cell name to get.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell. The nvmem_cell will be freed by the
+ * nvmem_cell_put().
+ */
+struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *cell_id)
+{
+ struct nvmem_cell *cell;
+
+ if (dev->of_node) { /* try dt first */
+ cell = of_nvmem_cell_get(dev->of_node, cell_id);
+ if (!IS_ERR(cell) || PTR_ERR(cell) == -EPROBE_DEFER)
+ return cell;
+ }
+
+ return nvmem_cell_get_from_list(cell_id);
+}
+EXPORT_SYMBOL_GPL(nvmem_cell_get);
+
+static void devm_nvmem_cell_release(struct device *dev, void *res)
+{
+ nvmem_cell_put(*(struct nvmem_cell **)res);
+}
+
+/**
+ * devm_nvmem_cell_get() - Get nvmem cell of device form a given id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem id in nvmem-names property.
+ *
+ * Return: Will be an ERR_PTR() on error or a valid pointer
+ * to a struct nvmem_cell. The nvmem_cell will be freed by the
+ * automatically once the device is freed.
+ */
+struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, const char *id)
+{
+ struct nvmem_cell **ptr, *cell;
+
+ ptr = devres_alloc(devm_nvmem_cell_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ cell = nvmem_cell_get(dev, id);
+ if (!IS_ERR(cell)) {
+ *ptr = cell;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return cell;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_cell_get);
+
+static int devm_nvmem_cell_match(struct device *dev, void *res, void *data)
+{
+ struct nvmem_cell **c = res;
+
+ if (WARN_ON(!c || !*c))
+ return 0;
+
+ return *c == data;
+}
+
+/**
+ * devm_nvmem_cell_put() - Release previously allocated nvmem cell
+ * from devm_nvmem_cell_get.
+ *
+ * @cell: Previously allocated nvmem cell by devm_nvmem_cell_get()
+ */
+void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell)
+{
+ int ret;
+
+ ret = devres_release(dev, devm_nvmem_cell_release,
+ devm_nvmem_cell_match, cell);
+
+ WARN_ON(ret);
+}
+EXPORT_SYMBOL(devm_nvmem_cell_put);
+
+/**
+ * nvmem_cell_put() - Release previously allocated nvmem cell.
+ *
+ * @cell: Previously allocated nvmem cell by nvmem_cell_get()
+ */
+void nvmem_cell_put(struct nvmem_cell *cell)
+{
+ struct nvmem_device *nvmem = cell->nvmem;
+
+ __nvmem_device_put(nvmem);
+ nvmem_cell_drop(cell);
+}
+EXPORT_SYMBOL_GPL(nvmem_cell_put);
+
+static inline void nvmem_shift_read_buffer_in_place(struct nvmem_cell *cell,
+ void *buf)
+{
+ u8 *p, *b;
+ int i, bit_offset = cell->bit_offset;
+
+ p = b = buf;
+ if (bit_offset) {
+ /* First shift */
+ *b++ >>= bit_offset;
+
+ /* setup rest of the bytes if any */
+ for (i = 1; i < cell->bytes; i++) {
+ /* Get bits from next byte and shift them towards msb */
+ *p |= *b << (BITS_PER_BYTE - bit_offset);
+
+ p = b;
+ *b++ >>= bit_offset;
+ }
+
+ /* result fits in less bytes */
+ if (cell->bytes != DIV_ROUND_UP(cell->nbits, BITS_PER_BYTE))
+ *p-- = 0;
+ }
+ /* clear msb bits if any leftover in the last byte */
+ *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
+}
+
+static int __nvmem_cell_read(struct nvmem_device *nvmem,
+ struct nvmem_cell *cell,
+ void *buf, size_t *len)
+{
+ int rc;
+
+ rc = regmap_raw_read(nvmem->regmap, cell->offset, buf, cell->bytes);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ /* shift bits in-place */
+ if (cell->bit_offset || cell->bit_offset)
+ nvmem_shift_read_buffer_in_place(cell, buf);
+
+ *len = cell->bytes;
+
+ return 0;
+}
+
+/**
+ * nvmem_cell_read() - Read a given nvmem cell
+ *
+ * @cell: nvmem cell to be read.
+ * @len: pointer to length of cell which will be populated on successful read.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a char * buffer on success.
+ * The buffer should be freed by the consumer with a kfree().
+ */
+void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len)
+{
+ struct nvmem_device *nvmem = cell->nvmem;
+ u8 *buf;
+ int rc;
+
+ if (!nvmem || !nvmem->regmap)
+ return ERR_PTR(-EINVAL);
+
+ buf = kzalloc(cell->bytes, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ rc = __nvmem_cell_read(nvmem, cell, buf, len);
+ if (IS_ERR_VALUE(rc)) {
+ kfree(buf);
+ return ERR_PTR(rc);
+ }
+
+ return buf;
+}
+EXPORT_SYMBOL_GPL(nvmem_cell_read);
+
+static inline void *nvmem_cell_prepare_write_buffer(struct nvmem_cell *cell,
+ u8 *_buf, int len)
+{
+ struct nvmem_device *nvmem = cell->nvmem;
+ int i, rc, nbits, bit_offset = cell->bit_offset;
+ u8 v, *p, *buf, *b, pbyte, pbits;
+
+ nbits = cell->nbits;
+ buf = kzalloc(cell->bytes, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ memcpy(buf, _buf, len);
+ p = b = buf;
+
+ if (bit_offset) {
+ pbyte = *b;
+ *b <<= bit_offset;
+
+ /* setup the first byte with lsb bits from nvmem */
+ rc = regmap_raw_read(nvmem->regmap, cell->offset, &v, 1);
+ *b++ |= GENMASK(bit_offset - 1, 0) & v;
+
+ /* setup rest of the byte if any */
+ for (i = 1; i < cell->bytes; i++) {
+ /* Get last byte bits and shift them towards lsb */
+ pbits = pbyte >> (BITS_PER_BYTE - 1 - bit_offset);
+ pbyte = *b;
+ p = b;
+ *b <<= bit_offset;
+ *b++ |= pbits;
+ }
+ }
+
+ /* if it's not end on byte boundary */
+ if ((nbits + bit_offset) % BITS_PER_BYTE) {
+ /* setup the last byte with msb bits from nvmem */
+ rc = regmap_raw_read(nvmem->regmap,
+ cell->offset + cell->bytes - 1, &v, 1);
+ *p |= GENMASK(7, (nbits + bit_offset) % BITS_PER_BYTE) & v;
+
+ }
+
+ return buf;
+}
+
+/**
+ * nvmem_cell_write() - Write to a given nvmem cell
+ *
+ * @cell: nvmem cell to be written.
+ * @buf: Buffer to be written.
+ * @len: length of buffer to be written to nvmem cell.
+ *
+ * Return: length of bytes written or negative on failure.
+ */
+int nvmem_cell_write(struct nvmem_cell *cell, void *buf, size_t len)
+{
+ struct nvmem_device *nvmem = cell->nvmem;
+ int rc;
+
+ if (!nvmem || !nvmem->regmap || nvmem->read_only ||
+ (cell->bit_offset == 0 && len != cell->bytes))
+ return -EINVAL;
+
+ if (cell->bit_offset || cell->nbits) {
+ buf = nvmem_cell_prepare_write_buffer(cell, buf, len);
+ if (IS_ERR(buf))
+ return PTR_ERR(buf);
+ }
+
+ rc = regmap_raw_write(nvmem->regmap, cell->offset, buf, cell->bytes);
+
+ /* free the tmp buffer */
+ if (cell->bit_offset)
+ kfree(buf);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(nvmem_cell_write);
+
static int __init nvmem_init(void)
{
return bus_register(&nvmem_bus_type);
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 1e9e767..297cc67 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -12,6 +12,11 @@
#ifndef _LINUX_NVMEM_CONSUMER_H
#define _LINUX_NVMEM_CONSUMER_H
+struct device;
+struct device_node;
+/* consumer cookie */
+struct nvmem_cell;
+
struct nvmem_cell_info {
const char *name;
unsigned int offset;
@@ -20,4 +25,60 @@ struct nvmem_cell_info {
unsigned int nbits;
};
+#if IS_ENABLED(CONFIG_NVMEM)
+
+/* Cell based interface */
+struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *name);
+struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, const char *name);
+void nvmem_cell_put(struct nvmem_cell *cell);
+void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
+void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len);
+int nvmem_cell_write(struct nvmem_cell *cell, void *buf, size_t len);
+
+#else
+
+static inline struct nvmem_cell *nvmem_cell_get(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline struct nvmem_cell *devm_nvmem_cell_get(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline void devm_nvmem_cell_put(struct device *dev,
+ struct nvmem_cell *cell)
+{
+
+}
+static inline void nvmem_cell_put(struct nvmem_cell *cell)
+{
+}
+
+static inline char *nvmem_cell_read(struct nvmem_cell *cell, size_t *len)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline int nvmem_cell_write(struct nvmem_cell *cell,
+ const char *buf, size_t len)
+{
+ return -ENOSYS;
+}
+#endif /* CONFIG_NVMEM */
+
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+ const char *name);
+#else
+static inline struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
+ const char *name)
+{
+ return ERR_PTR(-ENOSYS);
+}
+#endif /* CONFIG_NVMEM && CONFIG_OF */
+
#endif /* ifndef _LINUX_NVMEM_CONSUMER_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v9 3/9] nvmem: Add nvmem_device based consumer apis.
From: Srinivas Kandagatla @ 2015-07-27 11:13 UTC (permalink / raw)
To: khilman-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
mporter-OWPKS81ov/FWk0Htik3J/w, stefan.wahren-eS4NqCHxEME,
wxt-TNX95d0MmH7DzftRWevZcw, Srinivas Kandagatla
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch adds read/write apis which are based on nvmem_device. It is
common that the drivers like omap cape manager or qcom cpr driver to
access bytes directly at particular offset in the eeprom and not from
nvmem cell info in DT. These driver would need to get access to the nvmem
directly, which is what these new APIS provide.
These wrapper apis would help such users to avoid code duplication in
there drivers and also avoid them reading a big eeprom blob and parsing
it internally in there driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Tested-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
---
drivers/nvmem/core.c | 258 +++++++++++++++++++++++++++++++++++++++++
include/linux/nvmem-consumer.h | 73 ++++++++++++
2 files changed, 331 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 8c16ae2..d3c6676 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -445,6 +445,148 @@ static void __nvmem_device_put(struct nvmem_device *nvmem)
mutex_unlock(&nvmem_mutex);
}
+static int nvmem_match(struct device *dev, void *data)
+{
+ return !strcmp(dev_name(dev), data);
+}
+
+static struct nvmem_device *nvmem_find(const char *name)
+{
+ struct device *d;
+
+ d = bus_find_device(&nvmem_bus_type, NULL, (void *)name, nvmem_match);
+
+ if (!d)
+ return NULL;
+
+ return to_nvmem_device(d);
+}
+
+#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
+/**
+ * of_nvmem_device_get() - Get nvmem device from a given id
+ *
+ * @dev node: Device tree node that uses the nvmem device
+ * @id: nvmem name from nvmem-names property.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *of_nvmem_device_get(struct device_node *np, const char *id)
+{
+
+ struct device_node *nvmem_np;
+ int index;
+
+ index = of_property_match_string(np, "nvmem-names", id);
+
+ nvmem_np = of_parse_phandle(np, "nvmem", index);
+ if (!nvmem_np)
+ return ERR_PTR(-EINVAL);
+
+ return __nvmem_device_get(nvmem_np, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(of_nvmem_device_get);
+#endif
+
+/**
+ * nvmem_device_get() - Get nvmem device from a given id
+ *
+ * @dev : Device that uses the nvmem device
+ * @id: nvmem name from nvmem-names property.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_device
+ * on success.
+ */
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *dev_name)
+{
+ if (dev->of_node) { /* try dt first */
+ struct nvmem_device *nvmem;
+
+ nvmem = of_nvmem_device_get(dev->of_node, dev_name);
+
+ if (!IS_ERR(nvmem) || PTR_ERR(nvmem) == -EPROBE_DEFER)
+ return nvmem;
+
+ }
+
+ return nvmem_find(dev_name);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_get);
+
+static int devm_nvmem_device_match(struct device *dev, void *res, void *data)
+{
+ struct nvmem_device **nvmem = res;
+
+ if (WARN_ON(!nvmem || !*nvmem))
+ return 0;
+
+ return *nvmem == data;
+}
+
+static void devm_nvmem_device_release(struct device *dev, void *res)
+{
+ nvmem_device_put(*(struct nvmem_device **)res);
+}
+
+/**
+ * devm_nvmem_device_put() - put alredy got nvmem device
+ *
+ * @nvmem: pointer to nvmem device allocated by devm_nvmem_cell_get(),
+ * that needs to be released.
+ */
+void devm_nvmem_device_put(struct device *dev, struct nvmem_device *nvmem)
+{
+ int ret;
+
+ ret = devres_release(dev, devm_nvmem_device_release,
+ devm_nvmem_device_match, nvmem);
+
+ WARN_ON(ret);
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_device_put);
+
+/**
+ * nvmem_device_put() - put alredy got nvmem device
+ *
+ * @nvmem: pointer to nvmem device that needs to be released.
+ */
+void nvmem_device_put(struct nvmem_device *nvmem)
+{
+ __nvmem_device_put(nvmem);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_put);
+
+/**
+ * devm_nvmem_device_get() - Get nvmem cell of device form a given id
+ *
+ * @dev node: Device tree node that uses the nvmem cell
+ * @id: nvmem name in nvmems property.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct nvmem_cell
+ * on success. The nvmem_cell will be freed by the automatically once the
+ * device is freed.
+ */
+struct nvmem_device *devm_nvmem_device_get(struct device *dev, const char *id)
+{
+ struct nvmem_device **ptr, *nvmem;
+
+ ptr = devres_alloc(devm_nvmem_device_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ nvmem = nvmem_device_get(dev, id);
+ if (!IS_ERR(nvmem)) {
+ *ptr = nvmem;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return nvmem;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_device_get);
+
static struct nvmem_cell *nvmem_cell_get_from_list(const char *cell_id)
{
struct nvmem_cell *cell = NULL;
@@ -806,6 +948,122 @@ int nvmem_cell_write(struct nvmem_cell *cell, void *buf, size_t len)
}
EXPORT_SYMBOL_GPL(nvmem_cell_write);
+/**
+ * nvmem_device_cell_read() - Read a given nvmem device and cell
+ *
+ * @nvmem: nvmem device to read from.
+ * @info: nvmem cell info to be read.
+ * @buf: buffer pointer which will be populated on successful read.
+ *
+ * Return: length of successful bytes read on success and negative
+ * error code on error.
+ */
+ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf)
+{
+ struct nvmem_cell cell;
+ int rc;
+ ssize_t len;
+
+ if (!nvmem || !nvmem->regmap)
+ return -EINVAL;
+
+ rc = nvmem_cell_info_to_nvmem_cell(nvmem, info, &cell);
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ rc = __nvmem_cell_read(nvmem, &cell, buf, &len);
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(nvmem_device_cell_read);
+
+/**
+ * nvmem_device_cell_write() - Write cell to a given nvmem device
+ *
+ * @nvmem: nvmem device to be written to.
+ * @info: nvmem cell info to be written
+ * @buf: buffer to be written to cell.
+ *
+ * Return: length of bytes written or negative error code on failure.
+ * */
+int nvmem_device_cell_write(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf)
+{
+ struct nvmem_cell cell;
+ int rc;
+
+ if (!nvmem || !nvmem->regmap)
+ return -EINVAL;
+
+ rc = nvmem_cell_info_to_nvmem_cell(nvmem, info, &cell);
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return nvmem_cell_write(&cell, buf, cell.bytes);
+}
+EXPORT_SYMBOL_GPL(nvmem_device_cell_write);
+
+/**
+ * nvmem_device_read() - Read from a given nvmem device
+ *
+ * @nvmem: nvmem device to read from.
+ * @offset: offset in nvmem device.
+ * @bytes: number of bytes to read.
+ * @buf: buffer pointer which will be populated on successful read.
+ *
+ * Return: length of successful bytes read on success and negative
+ * error code on error.
+ */
+int nvmem_device_read(struct nvmem_device *nvmem,
+ unsigned int offset,
+ size_t bytes, void *buf)
+{
+ int rc;
+
+ if (!nvmem || !nvmem->regmap)
+ return -EINVAL;
+
+ rc = regmap_raw_read(nvmem->regmap, offset, buf, bytes);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+ return bytes;
+}
+EXPORT_SYMBOL_GPL(nvmem_device_read);
+
+/**
+ * nvmem_device_write() - Write cell to a given nvmem device
+ *
+ * @nvmem: nvmem device to be written to.
+ * @offset: offset in nvmem device.
+ * @bytes: number of bytes to write.
+ * @buf: buffer to be written.
+ *
+ * Return: length of bytes written or negative error code on failure.
+ * */
+int nvmem_device_write(struct nvmem_device *nvmem,
+ unsigned int offset,
+ size_t bytes, void *buf)
+{
+ int rc;
+
+ if (!nvmem || !nvmem->regmap)
+ return -EINVAL;
+
+ rc = regmap_raw_write(nvmem->regmap, offset, buf, bytes);
+
+ if (IS_ERR_VALUE(rc))
+ return rc;
+
+
+ return bytes;
+}
+EXPORT_SYMBOL_GPL(nvmem_device_write);
+
static int __init nvmem_init(void)
{
return bus_register(&nvmem_bus_type);
diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
index 297cc67..9bb77d3 100644
--- a/include/linux/nvmem-consumer.h
+++ b/include/linux/nvmem-consumer.h
@@ -16,6 +16,7 @@ struct device;
struct device_node;
/* consumer cookie */
struct nvmem_cell;
+struct nvmem_device;
struct nvmem_cell_info {
const char *name;
@@ -35,6 +36,21 @@ void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
void *nvmem_cell_read(struct nvmem_cell *cell, size_t *len);
int nvmem_cell_write(struct nvmem_cell *cell, void *buf, size_t len);
+/* direct nvmem device read/write interface */
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *name);
+struct nvmem_device *devm_nvmem_device_get(struct device *dev,
+ const char *name);
+void nvmem_device_put(struct nvmem_device *nvmem);
+void devm_nvmem_device_put(struct device *dev, struct nvmem_device *nvmem);
+int nvmem_device_read(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+int nvmem_device_write(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf);
+int nvmem_device_cell_write(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf);
+
#else
static inline struct nvmem_cell *nvmem_cell_get(struct device *dev,
@@ -68,17 +84,74 @@ static inline int nvmem_cell_write(struct nvmem_cell *cell,
{
return -ENOSYS;
}
+
+static inline struct nvmem_device *nvmem_device_get(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline struct nvmem_device *devm_nvmem_device_get(struct device *dev,
+ const char *name)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+static inline void nvmem_device_put(struct nvmem_device *nvmem)
+{
+}
+
+static inline void devm_nvmem_device_put(struct device *dev,
+ struct nvmem_device *nvmem)
+{
+}
+
+static inline ssize_t nvmem_device_cell_read(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info,
+ void *buf)
+{
+ return -ENOSYS;
+}
+
+static inline int nvmem_device_cell_write(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info,
+ void *buf)
+{
+ return -ENOSYS;
+}
+
+static inline int nvmem_device_read(struct nvmem_device *nvmem,
+ unsigned int offset, size_t bytes,
+ void *buf)
+{
+ return -ENOSYS;
+}
+
+static inline int nvmem_device_write(struct nvmem_device *nvmem,
+ unsigned int offset, size_t bytes,
+ void *buf)
+{
+ return -ENOSYS;
+}
#endif /* CONFIG_NVMEM */
#if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
const char *name);
+struct nvmem_device *of_nvmem_device_get(struct device_node *np,
+ const char *name);
#else
static inline struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
const char *name)
{
return ERR_PTR(-ENOSYS);
}
+
+static inline struct nvmem_device *of_nvmem_device_get(struct device_node *np,
+ const char *name)
+{
+ return ERR_PTR(-ENOSYS);
+}
#endif /* CONFIG_NVMEM && CONFIG_OF */
#endif /* ifndef _LINUX_NVMEM_CONSUMER_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v9 4/9] nvmem: Add bindings for simple nvmem framework
From: Srinivas Kandagatla @ 2015-07-27 11:13 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla, Maxime Ripard
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds bindings for simple nvmem framework which allows nvmem
consumers to talk to nvmem providers to get access to nvmem cell data.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Documentation/devicetree/bindings/nvmem/nvmem.txt | 80 +++++++++++++++++++++++
1 file changed, 80 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nvmem.txt
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt b/Documentation/devicetree/bindings/nvmem/nvmem.txt
new file mode 100644
index 0000000..b52bc11
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
@@ -0,0 +1,80 @@
+= NVMEM(Non Volatile Memory) Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in NVMEMs like eeprom, efuses and so on.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on NVMEM, for the OS to be able to retrieve these information
+and act upon it. Obviously, the OS has to know about where to retrieve
+these data from, and where they are stored on the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+of this node.
+
+Optional properties:
+ read-only: Mark the provider as read only.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in nvmem provider.
+
+Required properties:
+reg: specifies the offset in byte within the storage device.
+
+Optional properties:
+
+bits: Is pair of bit location and number of bits, which specifies offset
+ in bit and number of bits within the address range specified by reg property.
+ Offset takes values from 0-7.
+
+For example:
+
+ /* Provider */
+ qfprom: qfprom@00700000 {
+ ...
+
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x404 0x10>;
+ };
+
+ tsens_calibration_bckp: calib_bckp@504 {
+ reg = <0x504 0x11>;
+ bits = <6 128>
+ };
+
+ pvs_version: pvs-version@6 {
+ reg = <0x6 0x2>
+ bits = <7 2>
+ };
+
+ speed_bin: speed-bin@c{
+ reg = <0xc 0x1>;
+ bits = <2 3>;
+
+ };
+ ...
+ };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells/providers.
+
+Required-properties:
+nvmem-cells: list of phandle to the nvmem data cells.
+nvmem-cell-names: names for the each nvmem-cells specified. Required if
+ nvmem-cells is used.
+
+Optional-properties:
+nvmem : list of phandles to nvmem providers.
+nvmem-names: names for the each nvmem provider. required if nvmem is used.
+
+For example:
+
+ tsens {
+ ...
+ nvmem-cells = <&tsens_calibration>;
+ nvmem-cell-names = "calibration";
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v9 5/9] Documentation: nvmem: add nvmem api level and how-to doc
From: Srinivas Kandagatla @ 2015-07-27 11:14 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch add basic how-to and api summary documentation for simple
NVMEM framework.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Documentation/nvmem/nvmem.txt | 152 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 152 insertions(+)
create mode 100644 Documentation/nvmem/nvmem.txt
diff --git a/Documentation/nvmem/nvmem.txt b/Documentation/nvmem/nvmem.txt
new file mode 100644
index 0000000..dbd40d8
--- /dev/null
+++ b/Documentation/nvmem/nvmem.txt
@@ -0,0 +1,152 @@
+ NVMEM SUBSYSTEM
+ Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+
+This document explains the NVMEM Framework along with the APIs provided,
+and how to use it.
+
+1. Introduction
+===============
+*NVMEM* is the abbreviation for Non Volatile Memory layer. It is used to
+retrieve configuration of SOC or Device specific data from non volatile
+memories like eeprom, efuses and so on.
+
+Before this framework existed, NVMEM drivers like eeprom were stored in
+drivers/misc, where they all had to duplicate pretty much the same code to
+register a sysfs file, allow in-kernel users to access the content of the
+devices they were driving, etc.
+
+This was also a problem as far as other in-kernel users were involved, since
+the solutions used were pretty much different from one driver to another, there
+was a rather big abstraction leak.
+
+This framework aims at solve these problems. It also introduces DT
+representation for consumer devices to go get the data they require (MAC
+Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. This
+framework is based on regmap, so that most of the abstraction available in
+regmap can be reused, across multiple types of buses.
+
+NVMEM Providers
++++++++++++++++
+
+NVMEM provider refers to an entity that implements methods to initialize, read
+and write the non-volatile memory.
+
+2. Registering/Unregistering the NVMEM provider
+===============================================
+
+A NVMEM provider can register with NVMEM core by supplying relevant
+nvmem configuration to nvmem_register(), on success core would return a valid
+nvmem_device pointer.
+
+nvmem_unregister(nvmem) is used to unregister a previously registered provider.
+
+For example, a simple qfprom case:
+
+static struct nvmem_config econfig = {
+ .name = "qfprom",
+ .owner = THIS_MODULE,
+};
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+ ...
+ econfig.dev = &pdev->dev;
+ nvmem = nvmem_register(&econfig);
+ ...
+}
+
+It is mandatory that the NVMEM provider has a regmap associated with its
+struct device. Failure to do would return error code from nvmem_register().
+
+NVMEM Consumers
++++++++++++++++
+
+NVMEM consumers are the entities which make use of the NVMEM provider to
+read from and to NVMEM.
+
+3. NVMEM cell based consumer APIs
+=================================
+
+NVMEM cells are the data entries/fields in the NVMEM.
+The NVMEM framework provides 3 APIs to read/write NVMEM cells.
+
+struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *name);
+struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, const char *name);
+
+void nvmem_cell_put(struct nvmem_cell *cell);
+void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
+
+void *nvmem_cell_read(struct nvmem_cell *cell, ssize_t *len);
+int nvmem_cell_write(struct nvmem_cell *cell, void *buf, ssize_t len);
+
+*nvmem_cell_get() apis will get a reference to nvmem cell for a given id,
+and nvmem_cell_read/write() can then read or write to the cell.
+Once the usage of the cell is finished the consumer should call *nvmem_cell_put()
+to free all the allocation memory for the cell.
+
+4. Direct NVMEM device based consumer APIs
+==========================================
+
+In some instances it is necessary to directly read/write the NVMEM.
+To facilitate such consumers NVMEM framework provides below apis.
+
+struct nvmem_device *nvmem_device_get(struct device *dev, const char *name);
+struct nvmem_device *devm_nvmem_device_get(struct device *dev,
+ const char *name);
+void nvmem_device_put(struct nvmem_device *nvmem);
+int nvmem_device_read(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+int nvmem_device_write(struct nvmem_device *nvmem, unsigned int offset,
+ size_t bytes, void *buf);
+int nvmem_device_cell_read(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf);
+int nvmem_device_cell_write(struct nvmem_device *nvmem,
+ struct nvmem_cell_info *info, void *buf);
+
+Before the consumers can read/write NVMEM directly, it should get hold
+of nvmem_controller from one of the *nvmem_device_get() api.
+
+The difference between these apis and cell based apis is that these apis always
+take nvmem_device as parameter.
+
+5. Releasing a reference to the NVMEM
+=====================================
+
+When a consumers no longer needs the NVMEM, it has to release the reference
+to the NVMEM it has obtained using the APIs mentioned in the above section.
+The NVMEM framework provides 2 APIs to release a reference to the NVMEM.
+
+void nvmem_cell_put(struct nvmem_cell *cell);
+void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell);
+void nvmem_device_put(struct nvmem_device *nvmem);
+void devm_nvmem_device_put(struct device *dev, struct nvmem_device *nvmem);
+
+Both these APIs are used to release a reference to the NVMEM and
+devm_nvmem_cell_put and devm_nvmem_device_put destroys the devres associated
+with this NVMEM.
+
+Userspace
++++++++++
+
+6. Userspace binary interface
+==============================
+
+Userspace can read/write the raw NVMEM file located at
+/sys/bus/nvmem/devices/*/nvmem
+
+ex:
+
+hexdump /sys/bus/nvmem/devices/qfprom0/nvmem
+
+0000000 0000 0000 0000 0000 0000 0000 0000 0000
+*
+00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00
+0000000 0000 0000 0000 0000 0000 0000 0000 0000
+...
+*
+0001000
+
+7. DeviceTree Binding
+=====================
+
+See Documentation/devicetree/bindings/nvmem/nvmem.txt
--
1.9.1
^ permalink raw reply related
* [PATCH v9 6/9] nvmem: qfprom: Add Qualcomm QFPROM support.
From: Srinivas Kandagatla @ 2015-07-27 11:15 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.
On MSM parts there are some efuses (called qfprom) these fuses store
things like calibration data, speed bins.. etc. Drivers like cpufreq,
thermal sensors would read out this data for configuring the driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/nvmem/Kconfig | 15 +++++++++
drivers/nvmem/Makefile | 4 +++
drivers/nvmem/qfprom.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 104 insertions(+)
create mode 100644 drivers/nvmem/qfprom.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index de90c82..fa85805 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -11,3 +11,18 @@ menuconfig NVMEM
will be called nvmem_core.
If unsure, say no.
+
+if NVMEM
+
+config QCOM_QFPROM
+ tristate "QCOM QFPROM Support"
+ depends on ARCH_QCOM || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Say y here to enable QFPROM support. The QFPROM provides access
+ functions for QFPROM data to rest of the drivers via nvmem interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem_qfprom.
+
+endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 6df2c69..ff44fe9 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -4,3 +4,7 @@
obj-$(CONFIG_NVMEM) += nvmem_core.o
nvmem_core-y := core.o
+
+# Devices
+obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
+nvmem_qfprom-y := qfprom.o
diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
new file mode 100644
index 0000000..afb67e7
--- /dev/null
+++ b/drivers/nvmem/qfprom.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+static struct regmap_config qfprom_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .reg_stride = 1,
+};
+
+static struct nvmem_config econfig = {
+ .name = "qfprom",
+ .owner = THIS_MODULE,
+};
+
+static int qfprom_remove(struct platform_device *pdev)
+{
+ struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+ return nvmem_unregister(nvmem);
+}
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct nvmem_device *nvmem;
+ struct regmap *regmap;
+ void __iomem *base;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ qfprom_regmap_config.max_register = resource_size(res) - 1;
+
+ regmap = devm_regmap_init_mmio(dev, base, &qfprom_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "regmap init failed\n");
+ return PTR_ERR(regmap);
+ }
+ econfig.dev = dev;
+ nvmem = nvmem_register(&econfig);
+ if (IS_ERR(nvmem))
+ return PTR_ERR(nvmem);
+
+ platform_set_drvdata(pdev, nvmem);
+
+ return 0;
+}
+
+static const struct of_device_id qfprom_of_match[] = {
+ { .compatible = "qcom,qfprom",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+ .probe = qfprom_probe,
+ .remove = qfprom_remove,
+ .driver = {
+ .name = "qcom,qfprom",
+ .of_match_table = qfprom_of_match,
+ },
+};
+module_platform_driver(qfprom_driver);
+MODULE_AUTHOR("Srinivas Kandagatla <srinivas.kandagatla@linaro.org>");
+MODULE_DESCRIPTION("Qualcomm QFPROM driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v9 7/9] nvmem: qfprom: Add bindings for qfprom
From: Srinivas Kandagatla @ 2015-07-27 11:16 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple nvmem framework.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
---
Documentation/devicetree/bindings/nvmem/qfprom.txt | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/qfprom.txt
diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.txt b/Documentation/devicetree/bindings/nvmem/qfprom.txt
new file mode 100644
index 0000000..4ad68b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/qfprom.txt
@@ -0,0 +1,35 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be "qcom,qfprom"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+ qfprom: qfprom@00700000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00700000 0x8000>;
+ ...
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x4404 0x10>;
+ };
+ };
+
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+
+ tsens {
+ ...
+ nvmem-cells = <&tsens_calibration>;
+ nvmem-cell-names = "calibration";
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v9 8/9] nvmem: sunxi: Move the SID driver to the nvmem framework
From: Srinivas Kandagatla @ 2015-07-27 11:17 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla, Maxime Ripard
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
From: Maxime Ripard <maxime.ripard@free-electrons.com>
Now that we have the nvmem framework, we can consolidate the common
driver code. Move the driver to the framework, and hopefully, it will
fix the sysfs file creation race.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
Documentation/ABI/testing/sysfs-driver-sunxi-sid | 22 ---
.../bindings/misc/allwinner,sunxi-sid.txt | 17 --
.../bindings/nvmem/allwinner,sunxi-sid.txt | 21 +++
drivers/misc/eeprom/Kconfig | 13 --
drivers/misc/eeprom/Makefile | 1 -
drivers/misc/eeprom/sunxi_sid.c | 156 -------------------
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/sunxi_sid.c | 171 +++++++++++++++++++++
9 files changed, 205 insertions(+), 209 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
delete mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
create mode 100644 Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
delete mode 100644 drivers/misc/eeprom/sunxi_sid.c
create mode 100644 drivers/nvmem/sunxi_sid.c
diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
deleted file mode 100644
index ffb9536..0000000
--- a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
+++ /dev/null
@@ -1,22 +0,0 @@
-What: /sys/devices/*/<our-device>/eeprom
-Date: August 2013
-Contact: Oliver Schinagl <oliver@schinagl.nl>
-Description: read-only access to the SID (Security-ID) on current
- A-series SoC's from Allwinner. Currently supports A10, A10s, A13
- and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
- whereas the newer A20 SoC exposes 512 bytes split into sections.
- Besides the 16 bytes of SID, there's also an SJTAG area,
- HDMI-HDCP key and some custom keys. Below a quick overview, for
- details see the user manual:
- 0x000 128 bit root-key (sun[457]i)
- 0x010 128 bit boot-key (sun7i)
- 0x020 64 bit security-jtag-key (sun7i)
- 0x028 16 bit key configuration (sun7i)
- 0x02b 16 bit custom-vendor-key (sun7i)
- 0x02c 320 bit low general key (sun7i)
- 0x040 32 bit read-control access (sun7i)
- 0x064 224 bit low general key (sun7i)
- 0x080 2304 bit HDCP-key (sun7i)
- 0x1a0 768 bit high general key (sun7i)
-Users: any user space application which wants to read the SID on
- Allwinner's A-series of CPU's.
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
deleted file mode 100644
index fabdf64..0000000
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner sunxi-sid
-
-Required properties:
-- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
-- reg: Should contain registers location and length
-
-Example for sun4i:
- sid@01c23800 {
- compatible = "allwinner,sun4i-a10-sid";
- reg = <0x01c23800 0x10>
- };
-
-Example for sun7i:
- sid@01c23800 {
- compatible = "allwinner,sun7i-a20-sid";
- reg = <0x01c23800 0x200>
- };
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
new file mode 100644
index 0000000..d543ed3
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example for sun4i:
+ sid@01c23800 {
+ compatible = "allwinner,sun4i-a10-sid";
+ reg = <0x01c23800 0x10>
+ };
+
+Example for sun7i:
+ sid@01c23800 {
+ compatible = "allwinner,sun7i-a20-sid";
+ reg = <0x01c23800 0x200>
+ };
diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 9536852f..04f2e1f 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -96,17 +96,4 @@ config EEPROM_DIGSY_MTC_CFG
If unsure, say N.
-config EEPROM_SUNXI_SID
- tristate "Allwinner sunxi security ID support"
- depends on ARCH_SUNXI && SYSFS
- help
- This is a driver for the 'security ID' available on various Allwinner
- devices.
-
- Due to the potential risks involved with changing e-fuses,
- this driver is read-only.
-
- This driver can also be built as a module. If so, the module
- will be called sunxi_sid.
-
endmenu
diff --git a/drivers/misc/eeprom/Makefile b/drivers/misc/eeprom/Makefile
index 9507aec..fc1e81d 100644
--- a/drivers/misc/eeprom/Makefile
+++ b/drivers/misc/eeprom/Makefile
@@ -4,5 +4,4 @@ obj-$(CONFIG_EEPROM_LEGACY) += eeprom.o
obj-$(CONFIG_EEPROM_MAX6875) += max6875.o
obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
obj-$(CONFIG_EEPROM_93XX46) += eeprom_93xx46.o
-obj-$(CONFIG_EEPROM_SUNXI_SID) += sunxi_sid.o
obj-$(CONFIG_EEPROM_DIGSY_MTC_CFG) += digsy_mtc_eeprom.o
diff --git a/drivers/misc/eeprom/sunxi_sid.c b/drivers/misc/eeprom/sunxi_sid.c
deleted file mode 100644
index 8385177..0000000
--- a/drivers/misc/eeprom/sunxi_sid.c
+++ /dev/null
@@ -1,156 +0,0 @@
-/*
- * Copyright (c) 2013 Oliver Schinagl <oliver@schinagl.nl>
- * http://www.linux-sunxi.org
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * This driver exposes the Allwinner security ID, efuses exported in byte-
- * sized chunks.
- */
-
-#include <linux/compiler.h>
-#include <linux/device.h>
-#include <linux/err.h>
-#include <linux/export.h>
-#include <linux/fs.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/kobject.h>
-#include <linux/module.h>
-#include <linux/of_device.h>
-#include <linux/platform_device.h>
-#include <linux/random.h>
-#include <linux/slab.h>
-#include <linux/stat.h>
-#include <linux/sysfs.h>
-#include <linux/types.h>
-
-#define DRV_NAME "sunxi-sid"
-
-struct sunxi_sid_data {
- void __iomem *reg_base;
- unsigned int keysize;
-};
-
-/* We read the entire key, due to a 32 bit read alignment requirement. Since we
- * want to return the requested byte, this results in somewhat slower code and
- * uses 4 times more reads as needed but keeps code simpler. Since the SID is
- * only very rarely probed, this is not really an issue.
- */
-static u8 sunxi_sid_read_byte(const struct sunxi_sid_data *sid_data,
- const unsigned int offset)
-{
- u32 sid_key;
-
- if (offset >= sid_data->keysize)
- return 0;
-
- sid_key = ioread32be(sid_data->reg_base + round_down(offset, 4));
- sid_key >>= (offset % 4) * 8;
-
- return sid_key; /* Only return the last byte */
-}
-
-static ssize_t sid_read(struct file *fd, struct kobject *kobj,
- struct bin_attribute *attr, char *buf,
- loff_t pos, size_t size)
-{
- struct platform_device *pdev;
- struct sunxi_sid_data *sid_data;
- int i;
-
- pdev = to_platform_device(kobj_to_dev(kobj));
- sid_data = platform_get_drvdata(pdev);
-
- if (pos < 0 || pos >= sid_data->keysize)
- return 0;
- if (size > sid_data->keysize - pos)
- size = sid_data->keysize - pos;
-
- for (i = 0; i < size; i++)
- buf[i] = sunxi_sid_read_byte(sid_data, pos + i);
-
- return i;
-}
-
-static struct bin_attribute sid_bin_attr = {
- .attr = { .name = "eeprom", .mode = S_IRUGO, },
- .read = sid_read,
-};
-
-static int sunxi_sid_remove(struct platform_device *pdev)
-{
- device_remove_bin_file(&pdev->dev, &sid_bin_attr);
- dev_dbg(&pdev->dev, "driver unloaded\n");
-
- return 0;
-}
-
-static const struct of_device_id sunxi_sid_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-sid", .data = (void *)16},
- { .compatible = "allwinner,sun7i-a20-sid", .data = (void *)512},
- {/* sentinel */},
-};
-MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
-
-static int sunxi_sid_probe(struct platform_device *pdev)
-{
- struct sunxi_sid_data *sid_data;
- struct resource *res;
- const struct of_device_id *of_dev_id;
- u8 *entropy;
- unsigned int i;
-
- sid_data = devm_kzalloc(&pdev->dev, sizeof(struct sunxi_sid_data),
- GFP_KERNEL);
- if (!sid_data)
- return -ENOMEM;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- sid_data->reg_base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(sid_data->reg_base))
- return PTR_ERR(sid_data->reg_base);
-
- of_dev_id = of_match_device(sunxi_sid_of_match, &pdev->dev);
- if (!of_dev_id)
- return -ENODEV;
- sid_data->keysize = (int)of_dev_id->data;
-
- platform_set_drvdata(pdev, sid_data);
-
- sid_bin_attr.size = sid_data->keysize;
- if (device_create_bin_file(&pdev->dev, &sid_bin_attr))
- return -ENODEV;
-
- entropy = kzalloc(sizeof(u8) * sid_data->keysize, GFP_KERNEL);
- for (i = 0; i < sid_data->keysize; i++)
- entropy[i] = sunxi_sid_read_byte(sid_data, i);
- add_device_randomness(entropy, sid_data->keysize);
- kfree(entropy);
-
- dev_dbg(&pdev->dev, "loaded\n");
-
- return 0;
-}
-
-static struct platform_driver sunxi_sid_driver = {
- .probe = sunxi_sid_probe,
- .remove = sunxi_sid_remove,
- .driver = {
- .name = DRV_NAME,
- .of_match_table = sunxi_sid_of_match,
- },
-};
-module_platform_driver(sunxi_sid_driver);
-
-MODULE_AUTHOR("Oliver Schinagl <oliver@schinagl.nl>");
-MODULE_DESCRIPTION("Allwinner sunxi security id driver");
-MODULE_LICENSE("GPL");
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index fa85805..8db2978 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -25,4 +25,15 @@ config QCOM_QFPROM
This driver can also be built as a module. If so, the module
will be called nvmem_qfprom.
+config NVMEM_SUNXI_SID
+ tristate "Allwinner SoCs SID support"
+ depends on ARCH_SUNXI
+ select REGMAP_MMIO
+ help
+ This is a driver for the 'security ID' available on various Allwinner
+ devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem_sunxi_sid.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index ff44fe9..4328b93 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -8,3 +8,5 @@ nvmem_core-y := core.o
# Devices
obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
nvmem_qfprom-y := qfprom.o
+obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
+nvmem_sunxi_sid-y := sunxi_sid.o
diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
new file mode 100644
index 0000000..14777dd
--- /dev/null
+++ b/drivers/nvmem/sunxi_sid.c
@@ -0,0 +1,171 @@
+/*
+ * Allwinner sunXi SoCs Security ID support.
+ *
+ * Copyright (c) 2013 Oliver Schinagl <oliver@schinagl.nl>
+ * Copyright (C) 2014 Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/random.h>
+
+
+static struct nvmem_config econfig = {
+ .name = "sunxi-sid",
+ .read_only = true,
+ .owner = THIS_MODULE,
+};
+
+struct sunxi_sid {
+ void __iomem *base;
+};
+
+/* We read the entire key, due to a 32 bit read alignment requirement. Since we
+ * want to return the requested byte, this results in somewhat slower code and
+ * uses 4 times more reads as needed but keeps code simpler. Since the SID is
+ * only very rarely probed, this is not really an issue.
+ */
+static u8 sunxi_sid_read_byte(const struct sunxi_sid *sid,
+ const unsigned int offset)
+{
+ u32 sid_key;
+
+ sid_key = ioread32be(sid->base + round_down(offset, 4));
+ sid_key >>= (offset % 4) * 8;
+
+ return sid_key; /* Only return the last byte */
+}
+
+static int sunxi_sid_read(void *context,
+ const void *reg, size_t reg_size,
+ void *val, size_t val_size)
+{
+ struct sunxi_sid *sid = context;
+ unsigned int offset = *(u32 *)reg;
+ u8 *buf = val;
+
+ while (val_size) {
+ *buf++ = sunxi_sid_read_byte(sid, offset);
+ val_size--;
+ offset++;
+ }
+
+ return 0;
+}
+
+static int sunxi_sid_write(void *context, const void *data, size_t count)
+{
+ /* Unimplemented, dummy to keep regmap core happy */
+ return 0;
+}
+
+static struct regmap_bus sunxi_sid_bus = {
+ .read = sunxi_sid_read,
+ .write = sunxi_sid_write,
+ .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+ .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+static bool sunxi_sid_writeable_reg(struct device *dev, unsigned int reg)
+{
+ return false;
+}
+
+static struct regmap_config sunxi_sid_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .reg_stride = 1,
+ .writeable_reg = sunxi_sid_writeable_reg,
+};
+
+static int sunxi_sid_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct nvmem_device *nvmem;
+ struct regmap *regmap;
+ struct sunxi_sid *sid;
+ int i, size;
+ char *randomness;
+
+ sid = devm_kzalloc(dev, sizeof(*sid), GFP_KERNEL);
+ if (!sid)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sid->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(sid->base))
+ return PTR_ERR(sid->base);
+
+ size = resource_size(res) - 1;
+ sunxi_sid_regmap_config.max_register = size;
+
+ regmap = devm_regmap_init(dev, &sunxi_sid_bus, sid,
+ &sunxi_sid_regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, "regmap init failed\n");
+ return PTR_ERR(regmap);
+ }
+
+ econfig.dev = dev;
+ nvmem = nvmem_register(&econfig);
+ if (IS_ERR(nvmem))
+ return PTR_ERR(nvmem);
+
+ randomness = kzalloc(sizeof(u8) * size, GFP_KERNEL);
+ for (i = 0; i < size; i++)
+ randomness[i] = sunxi_sid_read_byte(sid, i);
+
+ add_device_randomness(randomness, size);
+ kfree(randomness);
+
+ platform_set_drvdata(pdev, nvmem);
+
+ return 0;
+}
+
+static int sunxi_sid_remove(struct platform_device *pdev)
+{
+ struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+ return nvmem_unregister(nvmem);
+}
+
+static const struct of_device_id sunxi_sid_of_match[] = {
+ { .compatible = "allwinner,sun4i-a10-sid" },
+ { .compatible = "allwinner,sun7i-a20-sid" },
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
+
+static struct platform_driver sunxi_sid_driver = {
+ .probe = sunxi_sid_probe,
+ .remove = sunxi_sid_remove,
+ .driver = {
+ .name = "eeprom-sunxi-sid",
+ .of_match_table = sunxi_sid_of_match,
+ },
+};
+module_platform_driver(sunxi_sid_driver);
+
+MODULE_AUTHOR("Oliver Schinagl <oliver@schinagl.nl>");
+MODULE_DESCRIPTION("Allwinner sunxi security id driver");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH v9 9/9] nvmem: Add to MAINTAINERS for nvmem framework
From: Srinivas Kandagatla @ 2015-07-27 11:17 UTC (permalink / raw)
To: khilman, linux-arm-kernel, Greg Kroah-Hartman
Cc: Rob Herring, Mark Brown, s.hauer, linux-api, linux-kernel,
devicetree, linux-arm-msm, arnd, sboyd, pantelis.antoniou,
mporter, stefan.wahren, wxt, Srinivas Kandagatla
In-Reply-To: <1437995567-11203-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds MAINTAINERS to nvmem framework.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..90e0d94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7263,6 +7263,15 @@ S: Supported
F: drivers/block/nvme*
F: include/linux/nvme.h
+NVMEM FRAMEWORK
+M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
+M: Maxime Ripard <maxime.ripard@free-electrons.com>
+S: Maintained
+F: drivers/nvmem/
+F: Documentation/devicetree/bindings/nvmem/
+F: include/linux/nvmem-consumer.h
+F: include/linux/nvmem-provider.h
+
NXP-NCI NFC DRIVER
M: Clément Perrochaud <clement.perrochaud@effinnov.com>
R: Charles Gorand <charles.gorand@effinnov.com>
--
1.9.1
^ permalink raw reply related
* Next round: revised futex(2) man page for review
From: Michael Kerrisk (man-pages) @ 2015-07-27 12:07 UTC (permalink / raw)
To: Thomas Gleixner, Darren Hart, Torvald Riegel
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Carlos O'Donell,
Ingo Molnar, Jakub Jelinek, linux-man, lkml, Davidlohr Bueso,
Arnd Bergmann, Steven Rostedt, Peter Zijlstra, Linux API,
Roland McGrath, Anton Blanchard, Eric Dumazet, bill o gallmeister,
Jan Kiszka, Daniel Wagner, Rich Felker, Andy Lutomirski,
bert hubert, Rusty Russell, Heinrich Schuchardt
Hello all,
From a draft sent out in March, I got a few useful comments that
I've now incorporated into this draft. And I got some complaints
from people who did not want to read groff source. My point
was that there are a bunch of FIXMEs in the page source that I
wanted people to look at... Anyway, this time, I will take
a different tack, interspersing the FIXMEs in a rendered
version of the page. I'd greatly appreciate help with those FIXMEs.
The current page source can be found at in a branch at
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?h=draft_futex
===
As becomes quickly obvious upon reading it, the current futex(2)
man page is in a sorry state, lacking many important details, and
also the various additions that have been made to the interface
over the last years. I've been working on revising it, first
of all based on input I got in response to a request for help
last year (http://thread.gmane.org/gmane.linux.kernel/1703405),
especially taking Thomas Gleixner's input
(http://thread.gmane.org/gmane.linux.kernel/1703405/focus=2952)
into account. I also got some further offlist input from Darren
Hart, Torvald Riegel, and Davidlohr Bueso that has been
incorporated into the revised draft. Other than that, I got
some useful info out of Ulrich Drepper's paper (cited at the
end of the page) and one or two web pages (cited in the page
source).
The page has now increased in size by a factor of about 5, but
is far from complete. In particular, as I reworked the page,
there were many details that I was not 100% certain of, and I
have added FIXME markers to the page source. In addition,
Torvald added some text, and a few more FIXMEs. Some of
the FIXMEs are trivial, as in: I'd like confirmation that
I have correctly captured a technical detail. Others are more
substantial, probably requiring the addition of further text.
I appreciate that there are probably other things that can be
improved in the page. (Torvald and Darren have some ideas.)
However, before growing the page any further, I would like to
resolve as many of the FIXMEs (and any other problems that people
see) as possible in the existing text. I need help with that.
(And I know that dealing with that help, if I get it, will in
itself will be quite a task to deal with, which is why I have
been delaying it for many weeks now, as my time has been
rather limited recently.)
So, please take a look at the page below. At this point,
I would most especially appreciate help with the FIXMEs.
Cheers,
Michael
FUTEX(2) Linux Programmer's Manual FUTEX(2)
NAME
futex - fast user-space locking
SYNOPSIS
#include <linux/futex.h>
#include <sys/time.h>
int futex(int *uaddr, int futex_op, int val,
const struct timespec *timeout, /* or: uint32_t val2 */
int *uaddr2, int val3);
Note: There is no glibc wrapper for this system call; see NOTES.
DESCRIPTION
The futex() system call provides a method for waiting until a
certain condition becomes true. It is typically used as a block‐
ing construct in the context of shared-memory synchronization:
The program implements the majority of the synchronization in
user space, and uses one of the operations of the system call
when it is likely that it has to block for a longer time until
the condition becomes true. The program uses another operation
of the system call to wake anyone waiting for a particular condi‐
tion.
The condition is represented by the futex word, which is an
address in memory supplied to the futex() system call, and the
32-bit value at this memory location. (While the virtual
addresses for the same physical memory address in separate pro‐
cesses may be different, the same physical address may be shared
by the processes using mmap(2).)
When executing a futex operation that requests to block a thread,
the kernel will block only if the futex word has the value that
the calling thread supplied as expected value. The load from the
futex word, the comparison with the expected value, and the
actual blocking will happen atomically and totally ordered with
respect to concurrently executing futex operations on the same
futex word. Thus, the futex word is used to connect the synchro‐
nization in user space with the implementation of blocking by the
kernel; similar to an atomic compare-and-exchange operation that
potentially changes shared memory, blocking via a futex is an
atomic compare-and-block operation.
One example use of futexes is implementing locks. The state of
the lock (i.e., acquired or not acquired) can be represented as
an atomically accessed flag in shared memory. In the uncontended
case, a thread can access or modify the lock state with atomic
instructions, for example atomically changing it from not
acquired to acquired using an atomic compare-and-exchange
instruction. A thread maybe unable acquire a lock because it is
already acquired by another thread. It then may pass the lock's
flag as futex word and the value representing the acquired state
as the expected value to a futex() wait operation. The call to
futex() will block if and only if the lock is still acquired.
When releasing the lock, a thread has to first reset the lock
state to not acquired and then execute a futex operation that
wakes threads blocked on the lock flag used as futex word (this
can be be further optimized to avoid unnecessary wake-ups). See
futex(7) for more detail on how to use futexes.
Besides the basic wait and wake-up futex functionality, there are
further futex operations aimed at supporting more complex use
cases. Also note that no explicit initialization or destruction
are necessary to use futexes; the kernel maintains a futex (i.e.,
the kernel-internal implementation artifact) only while opera‐
tions such as FUTEX_WAIT, described below, are being performed on
a particular futex word.
Arguments
The uaddr argument points to the futex word. On all platforms,
futexes are four-byte integers that must be aligned on a four-
byte boundary. The operation to perform on the futex is speci‐
fied in the futex_op argument; val is a value whose meaning and
purpose depends on futex_op.
The remaining arguments (timeout, uaddr2, and val3) are required
only for certain of the futex operations described below. Where
one of these arguments is not required, it is ignored.
For several blocking operations, the timeout argument is a
pointer to a timespec structure that specifies a timeout for the
operation. However, notwithstanding the prototype shown above,
for some operations, the least significant four bytes are used as
an integer whose meaning is determined by the operation. For
these operations, the kernel casts the timeout value first to
unsigned long, then to uint32_t, and in the remainder of this
page, this argument is referred to as val2 when interpreted in
this fashion.
Where it is required, the uaddr2 argument is a pointer to a sec‐
ond futex word that is employed by the operation. The interpre‐
tation of the final integer argument, val3, depends on the opera‐
tion.
Futex operations
The futex_op argument consists of two parts: a command that spec‐
ifies the operation to be performed, bit-wise ORed with zero or
or more options that modify the behaviour of the operation. The
options that may be included in futex_op are as follows:
FUTEX_PRIVATE_FLAG (since Linux 2.6.22)
This option bit can be employed with all futex operations.
It tells the kernel that the futex is process-private and
not shared with another process (i.e., it is being used
for synchronization only between threads of the same
process). This allows the kernel to make some additional
performance optimizations.
As a convenience, <linux/futex.h> defines a set of con‐
stants with the suffix _PRIVATE that are equivalents of
all of the operations listed below, but with the
FUTEX_PRIVATE_FLAG ORed into the constant value. Thus,
there are FUTEX_WAIT_PRIVATE, FUTEX_WAKE_PRIVATE, and so
on.
FUTEX_CLOCK_REALTIME (since Linux 2.6.28)
This option bit can be employed only with the
FUTEX_WAIT_BITSET and FUTEX_WAIT_REQUEUE_PI operations.
If this option is set, the kernel treats timeout as an
absolute time based on CLOCK_REALTIME.
.\" FIXME XXX I added CLOCK_MONOTONIC below. Okay?
If this option is not set, the kernel treats timeout as
relative time, measured against the CLOCK_MONOTONIC clock.
The operation specified in futex_op is one of the following:
FUTEX_WAIT (since Linux 2.6.0)
This operation tests that the value at the futex word
pointed to by the address uaddr still contains the
expected value val, and if so, then sleeps awaiting
FUTEX_WAKE on the futex word. The load of the value of
the futex word is an atomic memory access (i.e., using
atomic machine instructions of the respective architec‐
ture). This load, the comparison with the expected value,
and starting to sleep are performed atomically and totally
ordered with respect to other futex operations on the same
futex word. If the thread starts to sleep, it is consid‐
ered a waiter on this futex word. If the futex value does
not match val, then the call fails immediately with the
error EAGAIN.
The purpose of the comparison with the expected value is
to prevent lost wake-ups: If another thread changed the
value of the futex word after the calling thread decided
to block based on the prior value, and if the other thread
executed a FUTEX_WAKE operation (or similar wake-up) after
the value change and before this FUTEX_WAIT operation,
then the latter will observe the value change and will not
start to sleep.
If the timeout argument is non-NULL, its contents specify
a relative timeout for the wait, measured according to the
.\" FIXME XXX I added CLOCK_MONOTONIC below. Okay?
CLOCK_MONOTONIC clock. (This interval will be rounded up
to the system clock granularity, and kernel scheduling
delays mean that the blocking interval may overrun by a
small amount.) If timeout is NULL, the call blocks indef‐
initely.
The arguments uaddr2 and val3 are ignored.
FUTEX_WAKE (since Linux 2.6.0)
This operation wakes at most val of the waiters that are
waiting (e.g., inside FUTEX_WAIT) on the futex word at the
address uaddr. Most commonly, val is specified as either
1 (wake up a single waiter) or INT_MAX (wake up all wait‐
ers). No guarantee is provided about which waiters are
awoken (e.g., a waiter with a higher scheduling priority
is not guaranteed to be awoken in preference to a waiter
with a lower priority).
The arguments timeout, uaddr2, and val3 are ignored.
FUTEX_FD (from Linux 2.6.0 up to and including Linux 2.6.25)
This operation creates a file descriptor that is associ‐
ated with the futex at uaddr. The caller must close the
returned file descriptor after use. When another process
or thread performs a FUTEX_WAKE on the futex word, the
file descriptor indicates as being readable with
select(2), poll(2), and epoll(7)
The file descriptor can be used to obtain asynchronous
notifications: if val is nonzero, then when another
process or thread executes a FUTEX_WAKE, the caller will
receive the signal number that was passed in val.
The arguments timeout, uaddr2 and val3 are ignored.
.\" FIXME(Torvald) We never define "upped". Maybe just remove the
.\" following sentence?
To prevent race conditions, the caller should test if the
futex has been upped after FUTEX_FD returns.
Because it was inherently racy, FUTEX_FD has been removed
from Linux 2.6.26 onward.
FUTEX_REQUEUE (since Linux 2.6.0)
.\" FIXME(Torvald) Is there some indication that FUTEX_REQUEUE is broken
.\" in general, or is this comment implicitly speaking about the
.\" condvar (?) use case? If the latter we might want to weaken the
.\" advice below a little.
.\" [Anyone else have input on this?]
Avoid using this operation. It is broken for its intended
purpose. Use FUTEX_CMP_REQUEUE instead.
This operation performs the same task as
FUTEX_CMP_REQUEUE, except that no check is made using the
value in val3. (The argument val3 is ignored.)
FUTEX_CMP_REQUEUE (since Linux 2.6.7)
This operation first checks whether the location uaddr
still contains the value val3. If not, the operation
fails with the error EAGAIN. Otherwise, the operation
wakes up a maximum of val waiters that are waiting on the
futex at uaddr. If there are more than val waiters, then
the remaining waiters are removed from the wait queue of
the source futex at uaddr and added to the wait queue of
the target futex at uaddr2. The val2 argument specifies
an upper limit on the number of waiters that are requeued
to the futex at uaddr2.
.\" FIXME(Torvald) Is the following correct? Or is just the decision
.\" which threads to wake or requeue part of the atomic operation?
The load from uaddr is an atomic memory access (i.e.,
using atomic machine instructions of the respective archi‐
tecture). This load, the comparison with val3, and the
requeueing of any waiters are performed atomically and
totally ordered with respect to other operations on the
same futex word.
This operation was added as a replacement for the earlier
FUTEX_REQUEUE. The difference is that the check of the
value at uaddr can be used to ensure that requeueing hap‐
pens only under certain conditions. Both operations can
be used to avoid a "thundering herd" effect when
FUTEX_WAKE is used and all of the waiters that are woken
need to acquire another futex.
.\" FIXME Please review the following new paragraph to see if it is
.\" accurate.
Typical values to specify for val are 0 or or 1. (Speci‐
fying INT_MAX is not useful, because it would make the
FUTEX_CMP_REQUEUE operation equivalent to FUTEX_WAKE.)
The limit value specified via val2 is typically either 1
or INT_MAX. (Specifying the argument as 0 is not useful,
because it would make the FUTEX_CMP_REQUEUE operation
equivalent to FUTEX_WAIT.)
.\" FIXME Here, it would be helpful to have an example of how
.\" FUTEX_CMP_REQUEUE might be used, at the same time illustrating
.\" why FUTEX_WAKE is unsuitable for the same use case.
FUTEX_WAKE_OP (since Linux 2.6.14)
.\" FIXME I added a lengthy piece of text on FUTEX_WAKE_OP text,
.\" and I'd be happy if someone checked it.
.\"
.\" FIXME(Torvald) The glibc condvar implementation is currently being
.\" revised (e.g., to not use an internal lock anymore).
.\" It is probably more future-proof to remove this paragraph.
.\" [Torvald, do you have an update here?]
.\"
This operation was added to support some user-space use
cases where more than one futex must be handled at the
same time. The most notable example is the implementation
of pthread_cond_signal(3), which requires operations on
two futexes, the one used to implement the mutex and the
one used in the implementation of the wait queue associ‐
ated with the condition variable. FUTEX_WAKE_OP allows
such cases to be implemented without leading to high rates
of contention and context switching.
The FUTEX_WAIT_OP operation is equivalent to executing the
following code atomically and totally ordered with respect
to other futex operations on any of the two supplied futex
words:
int oldval = *(int *) uaddr2;
*(int *) uaddr2 = oldval op oparg;
futex(uaddr, FUTEX_WAKE, val, 0, 0, 0);
if (oldval cmp cmparg)
futex(uaddr2, FUTEX_WAKE, val2, 0, 0, 0);
In other words, FUTEX_WAIT_OP does the following:
* saves the original value of the futex word at uaddr2
and performs an operation to modify the value of the
futex at uaddr2; this is an atomic read-modify-write
memory access (i.e., using atomic machine instructions
of the respective architecture)
* wakes up a maximum of val waiters on the futex for the
futex word at uaddr; and
* dependent on the results of a test of the original
value of the futex word at uaddr2, wakes up a maximum
of val2 waiters on the futex for the futex word at
uaddr2.
The operation and comparison that are to be performed are
encoded in the bits of the argument val3. Pictorially,
the encoding is:
+---+---+-----------+-----------+
|op |cmp| oparg | cmparg |
+---+---+-----------+-----------+
4 4 12 12 <== # of bits
Expressed in code, the encoding is:
#define FUTEX_OP(op, oparg, cmp, cmparg) \
(((op & 0xf) << 28) | \
((cmp & 0xf) << 24) | \
((oparg & 0xfff) << 12) | \
(cmparg & 0xfff))
In the above, op and cmp are each one of the codes listed
below. The oparg and cmparg components are literal
numeric values, except as noted below.
The op component has one of the following values:
FUTEX_OP_SET 0 /* uaddr2 = oparg; */
FUTEX_OP_ADD 1 /* uaddr2 += oparg; */
FUTEX_OP_OR 2 /* uaddr2 |= oparg; */
FUTEX_OP_ANDN 3 /* uaddr2 &= ~oparg; */
FUTEX_OP_XOR 4 /* uaddr2 ^= oparg; */
In addition, bit-wise ORing the following value into op
causes (1 << oparg) to be used as the operand:
FUTEX_OP_ARG_SHIFT 8 /* Use (1 << oparg) as operand */
The cmp field is one of the following:
FUTEX_OP_CMP_EQ 0 /* if (oldval == cmparg) wake */
FUTEX_OP_CMP_NE 1 /* if (oldval != cmparg) wake */
FUTEX_OP_CMP_LT 2 /* if (oldval < cmparg) wake */
FUTEX_OP_CMP_LE 3 /* if (oldval <= cmparg) wake */
FUTEX_OP_CMP_GT 4 /* if (oldval > cmparg) wake */
FUTEX_OP_CMP_GE 5 /* if (oldval >= cmparg) wake */
The return value of FUTEX_WAKE_OP is the sum of the number
of waiters woken on the futex uaddr plus the number of
waiters woken on the futex uaddr2.
FUTEX_WAIT_BITSET (since Linux 2.6.25)
This operation is like FUTEX_WAIT except that val3 is used
to provide a 32-bit bitset to the kernel. This bitset is
stored in the kernel-internal state of the waiter. See
the description of FUTEX_WAKE_BITSET for further details.
The FUTEX_WAIT_BITSET operation also interprets the time‐
out argument differently from FUTEX_WAIT. See the discus‐
sion of FUTEX_CLOCK_REALTIME, above.
The uaddr2 argument is ignored.
FUTEX_WAKE_BITSET (since Linux 2.6.25)
This operation is the same as FUTEX_WAKE except that the
val3 argument is used to provide a 32-bit bitset to the
kernel. This bitset is used to select which waiters
should be woken up. The selection is done by a bit-wise
AND of the "wake" bitset (i.e., the value in val3) and the
bitset which is stored in the kernel-internal state of the
waiter (the "wait" bitset that is set using
FUTEX_WAIT_BITSET). All of the waiters for which the
result of the AND is nonzero are woken up; the remaining
waiters are left sleeping.
.\" FIXME XXX Is this next paragraph that I added okay?
The effect of FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET is
to allow selective wake-ups among multiple waiters that
are blocked on the same futex. Note, however, that using
this bitset multiplexing feature on a futex is less effi‐
cient than simply using multiple futexes, because employ‐
ing bitset multiplexing requires the kernel to check all
waiters on a futex, including those that are not inter‐
ested in being woken up (i.e., they do not have the rele‐
vant bit set in their "wait" bitset).
The uaddr2 and timeout arguments are ignored.
The FUTEX_WAIT and FUTEX_WAKE operations correspond to
FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET operations where
the bitsets are all ones.
Priority-inheritance futexes
Linux supports priority-inheritance (PI) futexes in order to han‐
dle priority-inversion problems that can be encountered with nor‐
mal futex locks. Priority inversion is the problem that occurs
when a high-priority task is blocked waiting to acquire a lock
held by a low-priority task, while tasks at an intermediate pri‐
ority continuously preempt the low-priority task from the CPU.
Consequently, the low-priority task makes no progress toward
releasing the lock, and the high-priority task remains blocked.
Priority inheritance is a mechanism for dealing with the prior‐
ity-inversion problem. With this mechanism, when a high-priority
task becomes blocked by a lock held by a low-priority task, the
latter's priority is temporarily raised to that of the former, so
that it is not preempted by any intermediate level tasks, and can
thus make progress toward releasing the lock. To be effective,
priority inheritance must be transitive, meaning that if a high-
priority task blocks on a lock held by a lower-priority task that
is itself blocked by lock held by another intermediate-priority
task (and so on, for chains of arbitrary length), then both of
those task (or more generally, all of the tasks in a lock chain)
have their priorities raised to be the same as the high-priority
task.
.\" FIXME XXX The following is my attempt at a definition of PI futexes,
.\" based on mail discussions with Darren Hart. Does it seem okay?
From a user-space perspective, what makes a futex PI-aware is a
policy agreement between user space and the kernel about the
value of the futex word (described in a moment), coupled with the
use of the PI futex operations described below (in particular,
FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, and FUTEX_CMP_REQUEUE_PI).
.\" FIXME XXX ===== Start of adapted Hart/Guniguntala text =====
.\" The following text is drawn from the Hart/Guniguntala paper
.\" (listed in SEE ALSO), but I have reworded some pieces
.\" significantly. Please check it.
The PI futex operations described below differ from the other
futex operations in that they impose policy on the use of the
value of the futex word:
* If the lock is not acquired, the futex word's value shall be
0.
* If the lock is acquired, the futex word's value shall be the
thread ID (TID; see gettid(2)) of the owning thread.
* If the lock is owned and there are threads contending for the
lock, then the FUTEX_WAITERS bit shall be set in the futex
word's value; in other words, this value is:
FUTEX_WAITERS | TID
Note that a PI futex word never just has the value FUTEX_WAITERS,
which is a permissible state for non-PI futexes.
With this policy in place, a user-space application can acquire a
not-acquired lock or release a lock that no other threads try to
acquire using atomic instructions executed in user space (e.g., a
compare-and-swap operation such as cmpxchg on the x86 architec‐
ture). Acquiring a lock simply consists of using compare-and-
swap to atomically set the futex word's value to the caller's TID
if its previous value was 0. Releasing a lock requires using
compare-and-swap to set the futex word's value to 0 if the previ‐
ous value was the expected TID.
If a futex is already acquired (i.e., has a nonzero value), wait‐
ers must employ the FUTEX_LOCK_PI operation to acquire the lock.
If other threads are waiting for the lock, then the FUTEX_WAITERS
bit is set in the futex value; in this case, the lock owner must
employ the FUTEX_UNLOCK_PI operation to release the lock.
In the cases where callers are forced into the kernel (i.e.,
required to perform a futex() call), they then deal directly with
a so-called RT-mutex, a kernel locking mechanism which implements
the required priority-inheritance semantics. After the RT-mutex
is acquired, the futex value is updated accordingly, before the
calling thread returns to user space.
.\" FIXME ===== End of adapted Hart/Guniguntala text =====
.\" FIXME We need some explanation in the following paragraph of *why*
.\" it is important to note that "the kernel will update the
.\" futex word's value prior
It is important to note to returning to user space" . Can someone
explain? that the kernel will update the futex word's value
prior to returning to user space. Unlike the other futex opera‐
tions described above, the PI futex operations are designed for
the implementation of very specific IPC mechanisms.
.\"
.\" FIXME XXX In discussing errors for FUTEX_CMP_REQUEUE_PI, Darren Hart
.\" made the observation that "EINVAL is returned if the non-pi
.\" to pi or op pairing semantics are violated."
.\" Probably there needs to be a general statement about this
.\" requirement, probably located at about this point in the page.
.\" Darren (or someone else), care to take a shot at this?
.\"
.\" FIXME Somewhere on this page (I guess under the discussion of PI
.\" futexes) we need a discussion of the FUTEX_OWNER_DIED bit.
.\" Can someone propose a text?
PI futexes are operated on by specifying one of the following
values in futex_op:
FUTEX_LOCK_PI (since Linux 2.6.18)
.\" FIXME I did some significant rewording of tglx's text to create
.\" the text below.
.\" Please check the following paragraph, in case I injected
.\" errors.
This operation is used after after an attempt to acquire
the lock via an atomic user-space instruction failed
because the futex word has a nonzero value—specifically,
because it contained the namespace-specific TID of the
lock owner.
.\" FIXME In the preceding line, what does "namespace-specific" mean?
.\" (I kept those words from tglx.)
.\" That is, what kind of namespace are we talking about?
.\" (I suppose we are talking PID namespaces here, but I want to
.\" be sure.)
The operation checks the value of the futex word at the
address uaddr. If the value is 0, then the kernel tries
to atomically set the futex value to the caller's TID.
.\" FIXME What would be the cause(s) of failure referred to
.\" in the following sentence?
If
that fails, or the futex word's value is nonzero, the ker‐
nel atomically sets the FUTEX_WAITERS bit, which signals
the futex owner that it cannot unlock the futex in user
space atomically by setting the futex value to 0. After
that, the kernel tries to find the thread which is associ‐
ated with the owner TID, creates or reuses kernel state on
behalf of the owner and attaches the waiter to it.
.\" FIXME Could I get a bit more detail on the previous lines?
.\" What is "creates or reuses kernel state" about?
.\" (I think this needs to be clearer in the page)
.\" FIXME In the next line, what type of "priority" are we talking about?
.\" Realtime priorities for SCHED_FIFO and SCHED_RR?
.\" Or something else?
The
enqueueing of the waiter is in descending priority order
if more than one waiter exists.
.\" FIXME In the next sentence, what type of "priority" are we talking about?
.\" Realtime priorities for SCHED_FIFO and SCHED_RR?
.\" Or something else?
.\" FIXME What does "bandwidth" refer to in the next sentence?
The owner inherits either
the priority or the bandwidth of the waiter.
.\" FIXME In the preceding sentence, what determines whether the
.\" owner inherits the priority versus the bandwidth?
.\" FIXME Could I get some help translating the next sentence into
.\" something that user-space developers (and I) can understand?
.\" In particular, what are "nested locks" in this context?
This inheri‐
tance follows the lock chain in the case of nested locking
and performs deadlock detection.
.\" FIXME tglx said "The timeout argument is handled as described in
.\" FUTEX_WAIT." However, it appears to me that this is not right.
.\" Is the following formulation correct?
The timeout argument provides a timeout for the lock
attempt. It is interpreted as an absolute time, measured
against the CLOCK_REALTIME clock. If timeout is NULL, the
operation will block indefinitely.
The uaddr2, val, and val3 arguments are ignored.
FUTEX_TRYLOCK_PI (since Linux 2.6.18)
.\" FIXME I think it would be helpful here to say a few more words about
.\" the difference(s) between FUTEX_LOCK_PI and FUTEX_TRYLOCK_PI.
.\" Can someone propose something?
This operation tries to acquire the futex at uaddr. It
deals with the situation where the TID value at uaddr is
0, but the FUTEX_WAITERS bit is set. User space cannot
handle this condition in a race-free manner
.\" FIXME How does the situation in the previous sentence come about?
.\" Probably it would be helpful to say something about that in
.\" the man page.
.\" FIXME And *how* does FUTEX_TRYLOCK_PI deal with this situation?
The uaddr2, val, timeout, and val3 arguments are ignored.
FUTEX_UNLOCK_PI (since Linux 2.6.18)
This operation wakes the top priority waiter that is wait‐
ing in FUTEX_LOCK_PI on the futex address provided by the
uaddr argument.
This is called when the user space value at uaddr cannot
be changed atomically from a TID (of the owner) to 0.
The uaddr2, val, timeout, and val3 arguments are ignored.
FUTEX_CMP_REQUEUE_PI (since Linux 2.6.31)
This operation is a PI-aware variant of FUTEX_CMP_REQUEUE.
It requeues waiters that are blocked via
FUTEX_WAIT_REQUEUE_PI on uaddr from a non-PI source futex
(uaddr) to a PI target futex (uaddr2).
As with FUTEX_CMP_REQUEUE, this operation wakes up a maxi‐
mum of val waiters that are waiting on the futex at uaddr.
However, for FUTEX_CMP_REQUEUE_PI, val is required to be 1
(since the main point is to avoid a thundering herd). The
remaining waiters are removed from the wait queue of the
source futex at uaddr and added to the wait queue of the
target futex at uaddr2.
The val2 and val3 arguments serve the same purposes as for
FUTEX_CMP_REQUEUE.
.\" FIXME The page at http://locklessinc.com/articles/futex_cheat_sheet/
.\" notes that "priority-inheritance Futex to priority-inheritance
.\" Futex requeues are currently unsupported". Do we need to say
.\" something in the man page about that?
FUTEX_WAIT_REQUEUE_PI (since Linux 2.6.31)
.\" FIXME I find the next sentence (from tglx) pretty hard to grok.
.\" Could someone explain it a bit more?
Wait operation to wait on a non-PI futex at uaddr and
potentially be requeued onto a PI futex at uaddr2. The
wait operation on uaddr is the same as FUTEX_WAIT.
.\" FIXME I'm not quite clear on the meaning of the following sentence.
.\" Is this trying to say that while blocked in a
.\" FUTEX_WAIT_REQUEUE_PI, it could happen that another
.\" task does a FUTEX_WAKE on uaddr that simply causes
.\" a normal wake, with the result that the FUTEX_WAIT_REQUEUE_PI
.\" does not complete? What happens then to the FUTEX_WAIT_REQUEUE_PI
.\" opertion? Does it remain blocked, or does it unblock
.\" In which case, what does user space see?
The
waiter can be removed from the wait on uaddr via
FUTEX_WAKE without requeueing on uaddr2.
.\" FIXME Please check the following. tglx said "The timeout argument
.\" is handled as described in FUTEX_WAIT.", but the truth is
.\" as below, AFAICS
If timeout is not NULL, it specifies a timeout for the
wait operation; this timeout is interpreted as outlined
above in the description of the FUTEX_CLOCK_REALTIME
option. If timeout is NULL, the operation can block
indefinitely.
The val3 argument is ignored.
.\" FIXME Re the preceding sentence... Actually 'val3' is internally set to
.\" FUTEX_BITSET_MATCH_ANY before calling futex_wait_requeue_pi().
.\" I'm not sure we need to say anything about this though.
.\" Comments?
The FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI were
added to support a fairly specific use case: support for
priority-inheritance-aware POSIX threads condition vari‐
ables. The idea is that these operations should always be
paired, in order to ensure that user space and the kernel
remain in sync. Thus, in the FUTEX_WAIT_REQUEUE_PI opera‐
tion, the user-space application pre-specifies the target
of the requeue that takes place in the
FUTEX_CMP_REQUEUE_PI operation.
RETURN VALUE
In the event of an error (and assuming that futex() was invoked
via syscall(2)), all operations return -1 and set errno to indi‐
cate the cause of the error. The return value on success depends
on the operation, as described in the following list:
FUTEX_WAIT
Returns 0 if the caller was woken up. Note that a wake-up
can also be caused by common futex usage patterns in unre‐
lated code that happened to have previously used the futex
word's memory location (e.g., typical futex-based imple‐
mentations of Pthreads mutexes can cause this under some
conditions). Therefore, callers should always conserva‐
tively assume that a return value of 0 can mean a spurious
wake-up, and use the futex word's value (i.e., the user
space synchronization scheme)
to decide whether to continue to block or not.
FUTEX_WAKE
Returns the number of waiters that were woken up.
FUTEX_FD
Returns the new file descriptor associated with the futex.
FUTEX_REQUEUE
Returns the number of waiters that were woken up.
FUTEX_CMP_REQUEUE
Returns the total number of waiters that were woken up or
requeued to the futex for the futex word at uaddr2. If
this value is greater than val, then difference is the
number of waiters requeued to the futex for the futex word
at uaddr2.
FUTEX_WAKE_OP
Returns the total number of waiters that were woken up.
This is the sum of the woken waiters on the two futexes
for the futex words at uaddr and uaddr2.
FUTEX_WAIT_BITSET
Returns 0 if the caller was woken up. See FUTEX_WAIT for
how to interpret this correctly in practice.
FUTEX_WAKE_BITSET
Returns the number of waiters that were woken up.
FUTEX_LOCK_PI
Returns 0 if the futex was successfully locked.
FUTEX_TRYLOCK_PI
Returns 0 if the futex was successfully locked.
FUTEX_UNLOCK_PI
Returns 0 if the futex was successfully unlocked.
FUTEX_CMP_REQUEUE_PI
Returns the total number of waiters that were woken up or
requeued to the futex for the futex word at uaddr2. If
this value is greater than val, then difference is the
number of waiters requeued to the futex for the futex word
at uaddr2.
FUTEX_WAIT_REQUEUE_PI
Returns 0 if the caller was successfully requeued to the
futex for the futex word at uaddr2.
ERRORS
EACCES No read access to the memory of a futex word.
EAGAIN (FUTEX_WAIT, FUTEX_WAIT_BITSET, FUTEX_WAIT_REQUEUE_PI) The
value pointed to by uaddr was not equal to the expected
value val at the time of the call.
Note: on Linux, the symbolic names EAGAIN and EWOULDBLOCK
(both of which appear in different parts of the kernel
futex code) have the same value.
EAGAIN (FUTEX_CMP_REQUEUE, FUTEX_CMP_REQUEUE_PI) The value
pointed to by uaddr is not equal to the expected value
val3. (This probably indicates a race; use the safe
FUTEX_WAKE now.)
.\" FIXME: Is the preceding sentence "(This probably...") correct?
.\" [I would prefer to remove this sentence. --triegel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
EAGAIN (FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI)
The futex owner thread ID of uaddr (for
FUTEX_CMP_REQUEUE_PI: uaddr2) is about to exit, but has
not yet handled the internal state cleanup. Try again.
.\" FIXME XXX Should there be an EAGAIN case for FUTEX_TRYLOCK_PI?
.\" It seems so, looking at the handling of the rt_mutex_trylock()
.\" call in futex_lock_pi()
.\" (Davidlohr also thinks so.)
EDEADLK
(FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI)
The futex word at uaddr is already locked by the caller.
EDEADLK
.\" FIXME I reworded tglx's text somewhat; is the following okay?
(FUTEX_CMP_REQUEUE_PI) While requeueing a waiter to the PI
futex for the futex word at uaddr2, the kernel detected a
deadlock.
.\" FIXME XXX I see that kernel/locking/rtmutex.c uses EDEADLK in some
.\" places, and EDEADLOCK in others. On almost all architectures
.\" these constants are synonymous. Is there a reason that both
.\" names are used?
EFAULT A required pointer argument (i.e., uaddr, uaddr2, or time‐
out) did not point to a valid user-space address.
EINTR A FUTEX_WAIT or FUTEX_WAIT_BITSET operation was inter‐
rupted by a signal (see signal(7)). In kernels before
Linux 2.6.22, this error could also be returned for on a
spurious wakeup; since Linux 2.6.22, this no longer hap‐
pens.
EINVAL The operation in futex_op is one of those that employs a
timeout, but the supplied timeout argument was invalid
(tv_sec was less than zero, or tv_nsec was not less than
1,000,000,000).
EINVAL The operation specified in futex_op employs one or both of
the pointers uaddr and uaddr2, but one of these does not
point to a valid object—that is, the address is not four-
byte-aligned.
EINVAL (FUTEX_WAIT_BITSET, FUTEX_WAKE_BITSET) The bitset supplied
in val3 is zero.
EINVAL (FUTEX_CMP_REQUEUE_PI) uaddr equals uaddr2 (i.e., an
attempt was made to requeue to the same futex).
EINVAL (FUTEX_FD) The signal number supplied in val is invalid.
EINVAL (FUTEX_WAKE, FUTEX_WAKE_OP, FUTEX_WAKE_BITSET,
FUTEX_REQUEUE, FUTEX_CMP_REQUEUE) The kernel detected an
inconsistency between the user-space state at uaddr and
the kernel state—that is, it detected a waiter which waits
in FUTEX_LOCK_PI on uaddr.
EINVAL (FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_UNLOCK_PI) The
kernel detected an inconsistency between the user-space
state at uaddr and the kernel state. This indicates
either state corruption or that the kernel found a waiter
on uaddr which is waiting via FUTEX_WAIT or
FUTEX_WAIT_BITSET.
.\" FIXME Above, tglx did not mention the "state corruption" case for
.\" FUTEX_UNLOCK_PI, but I have added it, since I'm estimating
.\" that it also applied for FUTEX_UNLOCK_PI.
.\" So, does that case also apply for FUTEX_UNLOCK_PI?
EINVAL (FUTEX_CMP_REQUEUE_PI) The kernel detected an inconsis‐
tency between the user-space state at uaddr2 and the ker‐
nel state; that is, the kernel detected a waiter which
waits via FUTEX_WAIT on uaddr2.
.\" FIXME In the preceding sentence, tglx did not mention FUTEX_WAIT_BITSET,
.\" but should that not also be included here?
EINVAL (FUTEX_CMP_REQUEUE_PI) The kernel detected an inconsis‐
tency between the user-space state at uaddr and the kernel
state; that is, the kernel detected a waiter which waits
via FUTEX_WAIT or FUTEX_WAIT_BITESET on uaddr.
EINVAL (FUTEX_CMP_REQUEUE_PI) The kernel detected an inconsis‐
tency between the user-space state at uaddr and the kernel
state; that is, the kernel detected a waiter which waits
on uaddr via FUTEX_LOCK_PI (instead of
FUTEX_WAIT_REQUEUE_PI).
.\" FIXME XXX The following is a reworded version of Darren Hart's text.
.\" Please check that I did not introduce any errors.
EINVAL (FUTEX_CMP_REQUEUE_PI) An attempt was made to requeue a
waiter to a futex other than that specified by the match‐
ing FUTEX_WAIT_REQUEUE_PI call for that waiter.
EINVAL (FUTEX_CMP_REQUEUE_PI) The val argument is not 1.
EINVAL Invalid argument.
ENOMEM (FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI)
The kernel could not allocate memory to hold state infor‐
mation.
ENFILE (FUTEX_FD) The system limit on the total number of open
files has been reached.
ENOSYS Invalid operation specified in futex_op.
ENOSYS The FUTEX_CLOCK_REALTIME option was specified in futex_op,
but the accompanying operation was neither FUTEX_WAIT_BIT‐
SET nor FUTEX_WAIT_REQUEUE_PI.
ENOSYS (FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_UNLOCK_PI,
FUTEX_CMP_REQUEUE_PI, FUTEX_WAIT_REQUEUE_PI) A run-time
check determined that the operation is not available. The
PI futex operations are not implemented on all architec‐
tures and are not supported on some CPU variants.
EPERM (FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI)
The caller is not allowed to attach itself to the futex at
uaddr (for FUTEX_CMP_REQUEUE_PI: the futex at uaddr2).
(This may be caused by a state corruption in user space.)
EPERM (FUTEX_UNLOCK_PI) The caller does not own the lock repre‐
sented by the futex word.
ESRCH (FUTEX_LOCK_PI, FUTEX_TRYLOCK_PI, FUTEX_CMP_REQUEUE_PI)
.\" FIXME I reworded the following sentence a bit differently from
.\" tglx's formulation. Is it okay?
The thread ID in the futex word at uaddr does not exist.
ESRCH (FUTEX_CMP_REQUEUE_PI)
.\" FIXME I reworded the following sentence a bit differently from
.\" tglx's formulation. Is it okay?
The thread ID in the futex word at
uaddr2 does not exist.
ETIMEDOUT
The operation in futex_op employed the timeout specified
in timeout, and the timeout expired before the operation
completed.
VERSIONS
Futexes were first made available in a stable kernel release with
Linux 2.6.0.
Initial futex support was merged in Linux 2.5.7 but with differ‐
ent semantics from what was described above. A four-argument
system call with the semantics described in this page was intro‐
duced in Linux 2.5.40. In Linux 2.5.70, one argument was added.
In Linux 2.6.7, a sixth argument was added—messy, especially on
the s390 architecture.
CONFORMING TO
This system call is Linux-specific.
NOTES
Glibc does not provide a wrapper for this system call; call it
using syscall(2).
Various higher-level programming abstractions are implemented via
futexes, including POSIX threads mutexes and condition variables,
as well as POSIX semaphores.
EXAMPLE
.\" FIXME Is it worth having an example program?
.\" FIXME Anything obviously broken in the example program?
The program below demonstrates use of futexes in a program where
parent and child use a pair of futexes located inside a shared
anonymous mapping to synchronize access to a shared resource: the
terminal. The two processes each write nloops (a command-line
argument that defaults to 5 if omitted) messages to the terminal
and employ a synchronization protocol that ensures that they
alternate in writing messages. Upon running this program we see
output such as the following:
$ ./futex_demo
Parent (18534) 0
Child (18535) 0
Parent (18534) 1
Child (18535) 1
Parent (18534) 2
Child (18535) 2
Parent (18534) 3
Child (18535) 3
Parent (18534) 4
Child (18535) 4
Program source
/* futex_demo.c
Usage: futex_demo [nloops]
(Default: 5)
Demonstrate the use of futexes in a program where parent and child
use a pair of futexes located inside a shared anonymous mapping to
synchronize access to a shared resource: the terminal. The two
processes each write 'num-loops' messages to the terminal and employ
a synchronization protocol that ensures that they alternate in
writing messages.
*/
#define _GNU_SOURCE
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <linux/futex.h>
#include <sys/time.h>
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
} while (0)
static int *futex1, *futex2, *iaddr;
static int
futex(int *uaddr, int futex_op, int val,
const struct timespec *timeout, int *uaddr2, int val3)
{
return syscall(SYS_futex, uaddr, futex_op, val,
timeout, uaddr, val3);
}
/* Acquire the futex pointed to by 'futexp': wait for its value to
become 1, and then set the value to 0. */
static void
fwait(int *futexp)
{
int s;
/* __sync_bool_compare_and_swap(ptr, oldval, newval) is a gcc
built-in function. It atomically performs the equivalent of:
if (*ptr == oldval)
*ptr = newval;
It returns true if the test yielded true and *ptr was updated.
The alternative here would be to employ the equivalent atomic
machine-language instructions. For further information, see
the GCC Manual. */
while (1) {
/* Is the futex available? */
if (__sync_bool_compare_and_swap(futexp, 1, 0))
break; /* Yes */
/* Futex is not available; wait */
s = futex(futexp, FUTEX_WAIT, 0, NULL, NULL, 0);
if (s == -1 && errno != EAGAIN)
errExit("futex-FUTEX_WAIT");
}
}
/* Release the futex pointed to by 'futexp': if the futex currently
has the value 0, set its value to 1 and the wake any futex waiters,
so that if the peer is blocked in fpost(), it can proceed. */
static void
fpost(int *futexp)
{
int s;
/* __sync_bool_compare_and_swap() was described in comments above */
if (__sync_bool_compare_and_swap(futexp, 0, 1)) {
s = futex(futexp, FUTEX_WAKE, 1, NULL, NULL, 0);
if (s == -1)
errExit("futex-FUTEX_WAKE");
}
}
int
main(int argc, char *argv[])
{
pid_t childPid;
int j, nloops;
setbuf(stdout, NULL);
nloops = (argc > 1) ? atoi(argv[1]) : 5;
/* Create a shared anonymous mapping that will hold the futexes.
Since the futexes are being shared between processes, we
subsequently use the "shared" futex operations (i.e., not the
ones suffixed "_PRIVATE") */
iaddr = mmap(NULL, sizeof(int) * 2, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_SHARED, -1, 0);
if (iaddr == MAP_FAILED)
errExit("mmap");
futex1 = &iaddr[0];
futex2 = &iaddr[1];
*futex1 = 0; /* State: unavailable */
*futex2 = 1; /* State: available */
/* Create a child process that inherits the shared anonymous
mapping */
childPid = fork();
if (childPid == -1)
errExit("fork");
if (childPid == 0) { /* Child */
for (j = 0; j < nloops; j++) {
fwait(futex1);
printf("Child (%ld) %d\n", (long) getpid(), j);
fpost(futex2);
}
exit(EXIT_SUCCESS);
}
/* Parent falls through to here */
for (j = 0; j < nloops; j++) {
fwait(futex2);
printf("Parent (%ld) %d\n", (long) getpid(), j);
fpost(futex1);
}
wait(NULL);
exit(EXIT_SUCCESS);
}
SEE ALSO
get_robust_list(2), restart_syscall(2), futex(7)
The following kernel source files:
* Documentation/pi-futex.txt
* Documentation/futex-requeue-pi.txt
* Documentation/locking/rt-mutex.txt
* Documentation/locking/rt-mutex-design.txt
* Documentation/robust-futex-ABI.txt
Franke, H., Russell, R., and Kirwood, M., 2002. Fuss, Futexes
and Furwocks: Fast Userlevel Locking in Linux (from proceedings
of the Ottawa Linux Symposium 2002),
⟨http://kernel.org/doc/ols/2002/ols2002-pages-479-495.pdf⟩
Hart, D., 2009. A futex overview and update,
⟨http://lwn.net/Articles/360699/⟩
Hart, D. and Guniguntala, D., 2009. Requeue-PI: Making Glibc
Condvars PI-Aware (from proceedings of the 2009 Real-Time Linux
Workshop),
⟨http://lwn.net/images/conf/rtlws11/papers/proc/p10.pdf⟩
Drepper, U., 2011. Futexes Are Tricky,
⟨http://www.akkadia.org/drepper/futex.pdf⟩
Futex example library, futex-*.tar.bz2 at
⟨ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/⟩
.\" FIXME Are there any other resources that should be listed
.\" in the SEE ALSO section?
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
From: Eric B Munson @ 2015-07-27 13:35 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, Shuah Khan, Michal Hocko, Michael Kerrisk,
Jonathan Corbet, Ralf Baechle, linux-alpha, linux-kernel,
linux-mips, linux-parisc, linuxppc-dev, sparclinux, linux-xtensa,
linux-mm, linux-arch, linux-api
In-Reply-To: <55B5F4FF.9070604@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]
On Mon, 27 Jul 2015, Vlastimil Babka wrote:
> On 07/24/2015 11:28 PM, Eric B Munson wrote:
>
> ...
>
> >Changes from V4:
> >Drop all architectures for new sys call entries except x86[_64] and MIPS
> >Drop munlock2 and munlockall2
> >Make VM_LOCKONFAULT a modifier to VM_LOCKED only to simplify book keeping
> >Adjust tests to match
>
> Hi, thanks for considering my suggestions. Well, I do hope there
> were correct as API's are hard and I'm no API expert. But since
> API's are also impossible to change after merging, I'm sorry but
> I'll keep pestering for one last thing. Thanks again for persisting,
> I do believe it's for the good thing!
>
> The thing is that I still don't like that one has to call
> mlock2(MLOCK_LOCKED) to get the equivalent of the old mlock(). Why
> is that flag needed? We have two modes of locking now, and v5 no
> longer treats them separately in vma flags. But having two flags
> gives us four possible combinations, so two of them would serve
> nothing but to confuse the programmer IMHO. What will mlock2()
> without flags do? What will mlock2(MLOCK_LOCKED | MLOCK_ONFAULT) do?
> (Note I haven't studied the code yet, as having agreed on the API
> should come first. But I did suggest documenting these things more
> thoroughly too...)
> OK I checked now and both cases above seem to return EINVAL.
>
> So about the only point I see in MLOCK_LOCKED flag is parity with
> MAP_LOCKED for mmap(). But as Kirill said (and me before as well)
> MAP_LOCKED is broken anyway so we shouldn't twist the rest just of
> the API to keep the poor thing happier in its misery.
>
> Also note that AFAICS you don't have MCL_LOCKED for mlockall() so
> there's no full parity anyway. But please don't fix that by adding
> MCL_LOCKED :)
>
> Thanks!
I have an MLOCK_LOCKED flag because I prefer an interface to be
explicit. The caller of mlock2() will be required to fill in the flags
argument regardless. I can drop the MLOCK_LOCKED flag with 0 being the
value for LOCKED, but I thought it easier to make clear what was going
on at any call to mlock2(). If user space defines a MLOCK_LOCKED that
happens to be 0, I suppose that would be okay.
We do actually have an MCL_LOCKED, we just call it MCL_CURRENT. Would
you prefer that I match the name in mlock2() (add MLOCK_CURRENT
instead)?
Finally, on the question of MAP_LOCKONFAULT, do you just dislike
MAP_LOCKED and do not want to see it extended, or is this a NAK on the
set if that patch is included. I ask because I have to spin a V6 to get
the MLOCK flag declarations right, but I would prefer not to do a V7+.
If this is a NAK with, I can drop that patch and rework the tests to
cover without the mmap flag. Otherwise I want to keep it, I have an
internal user that would like to see it added.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
From: Eric B Munson @ 2015-07-27 13:41 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Andrew Morton, Michal Hocko, Vlastimil Babka, Paul Gortmaker,
Chris Metcalf, Guenter Roeck, linux-alpha, linux-kernel,
linux-mips, linux-parisc, linuxppc-dev, sparclinux, linux-xtensa,
linux-mm, linux-arch, linux-api
In-Reply-To: <20150727073129.GE11657@node.dhcp.inet.fi>
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
On Mon, 27 Jul 2015, Kirill A. Shutemov wrote:
> On Fri, Jul 24, 2015 at 05:28:43PM -0400, Eric B Munson wrote:
> > The cost of faulting in all memory to be locked can be very high when
> > working with large mappings. If only portions of the mapping will be
> > used this can incur a high penalty for locking.
> >
> > Now that we have the new VMA flag for the locked but not present state,
> > expose it as an mmap option like MAP_LOCKED -> VM_LOCKED.
>
> As I mentioned before, I don't think this interface is justified.
>
> MAP_LOCKED has known issues[1]. The MAP_LOCKED problem is not necessary
> affects MAP_LOCKONFAULT, but still.
>
> Let's not add new interface unless it's demonstrably useful.
>
> [1] http://lkml.kernel.org/g/20150114095019.GC4706@dhcp22.suse.cz
I understand and should have been more explicit. This patch is still
included becuase I have an internal user that wants to see it added.
The problem discussed in the thread you point out does not affect
MAP_LOCKONFAULT because we do not attempt to populate the region with
MAP_LOCKONFAULT.
As I told Vlastimil, if this is a hard NAK with the patch I can work
with that. Otherwise I prefer it stays.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] mm/compaction: enable mobile-page migration
From: Vlastimil Babka @ 2015-07-27 13:55 UTC (permalink / raw)
To: Gioh Kim, jlayton, bfields, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: dri-devel, akpm, Gioh Kim
In-Reply-To: <1436776519-17337-3-git-send-email-gioh.kim@lge.com>
On 07/13/2015 10:35 AM, Gioh Kim wrote:
> From: Gioh Kim <gurugio@hanmail.net>
>
> Add framework to register callback functions and check page mobility.
> There are some modes for page isolation so that isolate interface
> has arguments of page address and isolation mode while putback
> interface has only page address as argument.
Note that unlike what subject suggest, this doesn't really enable
mobile-page migration inside compaction, since that only happens with
patch 3. This might theoretically affect some cherry-pick backports that
don't care about balloon pages. I can imagine that can easily happen in
the world of mobile devices?
It would thus be somewhat cleaner if this patch was complete in that sense.
> Signed-off-by: Gioh Kim <gioh.kim@lge.com>
> Acked-by: Rafael Aquini <aquini@redhat.com>
> ---
> fs/proc/page.c | 3 ++
> include/linux/compaction.h | 80 ++++++++++++++++++++++++++++++++++
> include/linux/fs.h | 2 +
> include/linux/page-flags.h | 19 ++++++++
> include/uapi/linux/kernel-page-flags.h | 1 +
> 5 files changed, 105 insertions(+)
>
> diff --git a/fs/proc/page.c b/fs/proc/page.c
> index 7eee2d8..a4f5a00 100644
> --- a/fs/proc/page.c
> +++ b/fs/proc/page.c
> @@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
> if (PageBalloon(page))
> u |= 1 << KPF_BALLOON;
>
> + if (PageMobile(page))
> + u |= 1 << KPF_MOBILE;
PageMovable() would probably be as good a name and correspond to
MIGRATE_MOVABLE somewhat, unlike a completely new term. Whatever driver
starts to using this should probably change allocation flags to allocate
MIGRATE_MOVABLE, so that it works fine with what fragmentation avoidance
expects. Guess I should have said that earlier, but can you still
reconsider?
> +
> u |= kpf_copy_bit(k, KPF_LOCKED, PG_locked);
>
> u |= kpf_copy_bit(k, KPF_SLAB, PG_slab);
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index aa8f61c..f693072 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -1,6 +1,9 @@
> #ifndef _LINUX_COMPACTION_H
> #define _LINUX_COMPACTION_H
>
> +#include <linux/page-flags.h>
> +#include <linux/pagemap.h>
> +
> /* Return values for compact_zone() and try_to_compact_pages() */
> /* compaction didn't start as it was deferred due to past failures */
> #define COMPACT_DEFERRED 0
> @@ -51,6 +54,70 @@ extern void compaction_defer_reset(struct zone *zone, int order,
> bool alloc_success);
> extern bool compaction_restarting(struct zone *zone, int order);
>
> +static inline bool mobile_page(struct page *page)
> +{
> + return page->mapping && (PageMobile(page) || PageBalloon(page));
> +}
I would put this definition to linux/page-flags.h and rename it to
page_mobile (or better page_movable()), which is more common ordering.
> +
> +static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
Does this have to be in compaction.h? The only user is compaction.c so
probably move it there, and if there ever is another module using this
in the future, we can move it to a more appropriate place and declare it
in e.g. mm/internal.h.
> +{
> + bool ret = false;
> +
> + /*
> + * Avoid burning cycles with pages that are yet under __free_pages(),
> + * or just got freed under us.
> + *
> + * In case we 'win' a race for a mobile page being freed under us and
> + * raise its refcount preventing __free_pages() from doing its job
> + * the put_page() at the end of this block will take care of
> + * release this page, thus avoiding a nasty leakage.
> + */
> + if (unlikely(!get_page_unless_zero(page)))
> + goto out;
> +
> + /*
> + * As mobile pages are not isolated from LRU lists, concurrent
> + * compaction threads can race against page migration functions
> + * as well as race against the releasing a page.
> + *
> + * In order to avoid having an already isolated mobile page
> + * being (wrongly) re-isolated while it is under migration,
> + * or to avoid attempting to isolate pages being released,
> + * lets be sure we have the page lock
> + * before proceeding with the mobile page isolation steps.
> + */
> + if (unlikely(!trylock_page(page)))
> + goto out_putpage;
> +
> + if (!(mobile_page(page) && page->mapping->a_ops->isolatepage))
> + goto out_not_isolated;
> + ret = page->mapping->a_ops->isolatepage(page, mode);
> + if (!ret)
> + goto out_not_isolated;
> + unlock_page(page);
> + return ret;
> +
> +out_not_isolated:
> + unlock_page(page);
> +out_putpage:
> + put_page(page);
> +out:
> + return ret;
> +}
> +
> +static inline void putback_mobilepage(struct page *page)
Likewise, this could go to migrate.c. Or maybe together with
isolate_mobilepage() if you don't want to split them.
> +{
> + /*
> + * 'lock_page()' stabilizes the page and prevents races against
> + * concurrent isolation threads attempting to re-isolate it.
> + */
> + lock_page(page);
> + if (page->mapping && page->mapping->a_ops->putbackpage)
> + page->mapping->a_ops->putbackpage(page);
> + unlock_page(page);
> + /* drop the extra ref count taken for mobile page isolation */
> + put_page(page);
> +}
> #else
> static inline unsigned long try_to_compact_pages(gfp_t gfp_mask,
> unsigned int order, int alloc_flags,
> @@ -83,6 +150,19 @@ static inline bool compaction_deferred(struct zone *zone, int order)
> return true;
> }
>
> +static inline bool mobile_page(struct page *page)
> +{
> + return false;
> +}
> +
> +static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
> +{
> + return false;
> +}
> +
> +static inline void putback_mobilepage(struct page *page)
> +{
> +}
> #endif /* CONFIG_COMPACTION */
>
> #if defined(CONFIG_COMPACTION) && defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index a0653e5..2cc4b24 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -396,6 +396,8 @@ struct address_space_operations {
> */
> int (*migratepage) (struct address_space *,
> struct page *, struct page *, enum migrate_mode);
> + bool (*isolatepage) (struct page *, isolate_mode_t);
> + void (*putbackpage) (struct page *);
> int (*launder_page) (struct page *);
> int (*is_partially_uptodate) (struct page *, unsigned long,
> unsigned long);
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index f34e040..abef145 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -582,6 +582,25 @@ static inline void __ClearPageBalloon(struct page *page)
> atomic_set(&page->_mapcount, -1);
> }
>
> +#define PAGE_MOBILE_MAPCOUNT_VALUE (-255)
> +
> +static inline int PageMobile(struct page *page)
> +{
> + return atomic_read(&page->_mapcount) == PAGE_MOBILE_MAPCOUNT_VALUE;
> +}
> +
> +static inline void __SetPageMobile(struct page *page)
> +{
> + VM_BUG_ON_PAGE(atomic_read(&page->_mapcount) != -1, page);
> + atomic_set(&page->_mapcount, PAGE_MOBILE_MAPCOUNT_VALUE);
> +}
> +
> +static inline void __ClearPageMobile(struct page *page)
> +{
> + VM_BUG_ON_PAGE(!PageMobile(page), page);
> + atomic_set(&page->_mapcount, -1);
> +}
> +
> /*
> * If network-based swap is enabled, sl*b must keep track of whether pages
> * were allocated from pfmemalloc reserves.
> diff --git a/include/uapi/linux/kernel-page-flags.h b/include/uapi/linux/kernel-page-flags.h
> index a6c4962..d50d9e8 100644
> --- a/include/uapi/linux/kernel-page-flags.h
> +++ b/include/uapi/linux/kernel-page-flags.h
> @@ -33,6 +33,7 @@
> #define KPF_THP 22
> #define KPF_BALLOON 23
> #define KPF_ZERO_PAGE 24
> +#define KPF_MOBILE 25
>
>
> #endif /* _UAPILINUX_KERNEL_PAGE_FLAGS_H */
>
^ permalink raw reply
* Re: [PATCH 4/4] mm: remove direct calling of migration
From: Vlastimil Babka @ 2015-07-27 13:58 UTC (permalink / raw)
To: Gioh Kim, jlayton, bfields, iamjoonsoo.kim, viro, mst, koct9i,
minchan, aquini, linux-fsdevel, virtualization, linux-kernel,
linux-api, linux-mm
Cc: dri-devel, akpm, Gioh Kim
In-Reply-To: <1436776519-17337-5-git-send-email-gioh.kim@lge.com>
On 07/13/2015 10:35 AM, Gioh Kim wrote:
> From: Gioh Kim <gurugio@hanmail.net>
>
> Migration is completely generalized so that migrating mobile page
> is processed with lru-pages in move_to_new_page.
>
> Signed-off-by: Gioh Kim <gioh.kim@lge.com>
> Acked-by: Rafael Aquini <aquini@redhat.com>
Why not just fold this to Patch 3? You already modify this hunk there,
and prior to patch 3, the hunk was balloon-pages specific. You made it
look generic only to remove it, which is unneeded code churn and I don't
think it adds anything wrt e.g. bisectability.
> ---
> mm/migrate.c | 15 ---------------
> 1 file changed, 15 deletions(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 53f0081d..e6644ac 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -844,21 +844,6 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
> }
> }
>
> - if (unlikely(mobile_page(page))) {
> - /*
> - * A mobile page does not need any special attention from
> - * physical to virtual reverse mapping procedures.
> - * Skip any attempt to unmap PTEs or to remap swap cache,
> - * in order to avoid burning cycles at rmap level, and perform
> - * the page migration right away (proteced by page lock).
> - */
> - lock_page(newpage);
> - rc = page->mapping->a_ops->migratepage(page->mapping,
> - newpage, page, mode);
> - unlock_page(newpage);
> - goto out_unlock;
> - }
> -
> /*
> * Corner case handling:
> * 1. When a new swap-cache page is read into, it is added to the LRU
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox