__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pte_alloc_one{_kernel}, pmd_alloc_one allocate PTE_ORDER resp.
PMD_ORDER but both are not larger than 1. This means that this flag has
never been actually useful here because it has always been used only for
PAGE_ALLOC_COSTLY requests.
Link: http://lkml.kernel.org/r/1464599699-30131-8-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: John Crispin <blogic@openwrt.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
pte_alloc_one_kernel uses __get_order_pte but this is obviously always
zero because BITS_FOR_PTE is not larger than 9 yet the page size is
always larger than 4K. This means that this flag has never been
actually useful here because it has always been used only for
PAGE_ALLOC_COSTLY requests.
Link: http://lkml.kernel.org/r/1464599699-30131-7-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
{pte,pmd,pud}_alloc_one{_kernel}, late_pgtable_alloc use PGALLOC_GFP for
__get_free_page (aka order-0).
pgd_alloc is slightly more complex because it allocates from pgd_cache
if PGD_SIZE != PAGE_SIZE and PGD_SIZE depends on the configuration
(CONFIG_ARM64_VA_BITS, PAGE_SHIFT and CONFIG_PGTABLE_LEVELS).
As per
config PGTABLE_LEVELS
int
default 2 if ARM64_16K_PAGES && ARM64_VA_BITS_36
default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42
default 3 if ARM64_64K_PAGES && ARM64_VA_BITS_48
default 3 if ARM64_4K_PAGES && ARM64_VA_BITS_39
default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47
default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48
we should have the following options
CONFIG_ARM64_VA_BITS:48 CONFIG_PGTABLE_LEVELS:4 PAGE_SIZE:4k size:4096 pages:1
CONFIG_ARM64_VA_BITS:48 CONFIG_PGTABLE_LEVELS:4 PAGE_SIZE:16k size:16 pages:1
CONFIG_ARM64_VA_BITS:48 CONFIG_PGTABLE_LEVELS:3 PAGE_SIZE:64k size:512 pages:1
CONFIG_ARM64_VA_BITS:47 CONFIG_PGTABLE_LEVELS:3 PAGE_SIZE:16k size:16384 pages:1
CONFIG_ARM64_VA_BITS:42 CONFIG_PGTABLE_LEVELS:2 PAGE_SIZE:64k size:65536 pages:1
CONFIG_ARM64_VA_BITS:39 CONFIG_PGTABLE_LEVELS:3 PAGE_SIZE:4k size:4096 pages:1
CONFIG_ARM64_VA_BITS:36 CONFIG_PGTABLE_LEVELS:2 PAGE_SIZE:16k size:16384 pages:1
All of them fit into a single page (aka order-0). This means that this
flag has never been actually useful here because it has always been used
only for PAGE_ALLOC_COSTLY requests.
Link: http://lkml.kernel.org/r/1464599699-30131-6-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
efi_alloc_page_tables uses __GFP_REPEAT but it allocates an order-0
page. This means that this flag has never been actually useful here
because it has always been used only for PAGE_ALLOC_COSTLY requests.
Link: http://lkml.kernel.org/r/1464599699-30131-4-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.
PGALLOC_GFP uses __GFP_REPEAT but none of the allocation which uses this
flag is for more than order-0. This means that this flag has never been
actually useful here because it has always been used only for
PAGE_ALLOC_COSTLY requests.
Link: http://lkml.kernel.org/r/1464599699-30131-3-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the third version of the patchset previously sent [1]. I have
basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get
rid of superfluous gfp flags" which went through dm tree. I am sending
it now because it is tree wide and chances for conflicts are reduced
considerably when we want to target rc2. I plan to send the next step
and rename the flag and move to a better semantic later during this
release cycle so we will have a new semantic ready for 4.8 merge window
hopefully.
Motivation:
While working on something unrelated I've checked the current usage of
__GFP_REPEAT in the tree. It seems that a majority of the usage is and
always has been bogus because __GFP_REPEAT has always been about costly
high order allocations while we are using it for order-0 or very small
orders very often. It seems that a big pile of them is just a
copy&paste when a code has been adopted from one arch to another.
I think it makes some sense to get rid of them because they are just
making the semantic more unclear. Please note that GFP_REPEAT is
documented as
* __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
* _might_ fail. This depends upon the particular VM implementation.
while !costly requests have basically nofail semantic. So one could
reasonably expect that order-0 request with __GFP_REPEAT will not loop
for ever. This is not implemented right now though.
I would like to move on with __GFP_REPEAT and define a better semantic
for it.
$ git grep __GFP_REPEAT origin/master | wc -l
111
$ git grep __GFP_REPEAT | wc -l
36
So we are down to the third after this patch series. The remaining
places really seem to be relying on __GFP_REPEAT due to large allocation
requests. This still needs some double checking which I will do later
after all the simple ones are sorted out.
I am touching a lot of arch specific code here and I hope I got it right
but as a matter of fact I even didn't compile test for some archs as I
do not have cross compiler for them. Patches should be quite trivial to
review for stupid compile mistakes though. The tricky parts are usually
hidden by macro definitions and thats where I would appreciate help from
arch maintainers.
[1] http://lkml.kernel.org/r/1461849846-27209-1-git-send-email-mhocko@kernel.org
This patch (of 19):
__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations. Yet we
have the full kernel tree with its usage for apparently order-0
allocations. This is really confusing because __GFP_REPEAT is
explicitly documented to allow allocation failures which is a weaker
semantic than the current order-0 has (basically nofail).
Let's simply drop __GFP_REPEAT from those places. This would allow to
identify place which really need allocator to retry harder and formulate
a more specific semantic for what the flag is supposed to do actually.
Link: http://lkml.kernel.org/r/1464599699-30131-2-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen Liqin <liqin.linux@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: John Crispin <blogic@openwrt.org>
Cc: Lennox Wu <lennox.wu@gmail.com>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When fallocate is interrupted it will undo a range that extends one byte
past its range of allocated pages. This can corrupt an in-use page by
zeroing out its first byte. Instead, undo using the inclusive byte
range.
Fixes: 1635f6a741 ("tmpfs: undo fallocation on failure")
Link: http://lkml.kernel.org/r/1462713387-16724-1-git-send-email-anthony.romano@coreos.com
Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Brandon Philips <brandon@ifup.co>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The write at the end of the test to restore nr_hugepages to its previous
value is failing. This is because it is trying to write the number of
bytes in the char array as opposed to the number of bytes in the string.
Link: http://lkml.kernel.org/r/1465331205-3284-1-git-send-email-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Sri Jayaramappa <sjayaram@akamai.com>
Cc: Eric B Munson <emunson@akamai.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since commit 36324a990c ("oom: clear TIF_MEMDIE after oom_reaper
managed to unmap the address space") changed to use find_lock_task_mm()
for finding a mm_struct to reap, it is guaranteed that mm->mm_users > 0
because find_lock_task_mm() returns a task_struct with ->mm != NULL.
Therefore, we can safely use atomic_inc().
Link: http://lkml.kernel.org/r/1465024759-8074-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit e2fe14564d ("oom_reaper: close race with exiting task") reduced
frequency of needlessly selecting next OOM victim, but was calling
mmput_async() when atomic_inc_not_zero() failed.
Link: http://lkml.kernel.org/r/1464423365-5555-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The INIT_TASK() initializer was similarly confused about the stack vs
thread_info allocation that the allocators had, and that were fixed in
commit b235beea9e ("Clarify naming of thread info/stack allocators").
The task ->stack pointer only incidentally ends up having the same value
as the thread_info, and in fact that will change.
So fix the initial task struct initializer to point to 'init_stack'
instead of 'init_thread_info', and make sure the ia64 definition for
that exists.
This actually makes the ia64 tsk->stack pointer be sensible for the
initial task, but not for any other task. As mentioned in commit
b235beea9e, that whole pointer isn't actually used on ia64, since
task_stack_page() there just points to the (single) allocation.
All the other architectures seem to have copied the 'init_stack'
definition, even if it tended to be generally unusued.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The HOSTPC extension registers found in some EHCI implementations form
a variable-length array, with one element for each port. Therefore
the hostpc field in struct ehci_regs should be declared as a
zero-length array, not a single-element array.
This fixes a problem reported by UBSAN.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
*) Fix in sun4i-usb phy driver to properly handle the return value of
gpiod_to_irq
*) Fix a sparse warning in sun4i-usb phy driver
*) Fix bcm-ns-usb2 phy driver to check the correct variable
*) Fix spurious interrupts during VBUS change in rcar-gen3-usb2 phy
driver
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJXaoNJAAoJEA5ceFyATYLZNaMP/jvuMm85UWMTU/G21lULLv3D
XpTHWdVd0s21IyuR7eFiGpo8pA0AyluCmcB+ZzNZz1cXZWvS9fZNJgKwB/L0hYlZ
uvnbD5d7WdAS981izQ+ke6EeL5lZ+I0RYtP64yoSocVu50Fpmh3dqPkXJNjYttk/
ch/rX+hgYHB7Pm8mmhJ/kI1KjyrZVzCIUB0A7C5w+74x4uDNN4odXRUXpdy+ZLmd
ZAktvqAOpCnwQcK269Sm3AzhvPeelG8fyaeB7wHabq5duiUnZK+a8vpdV43548Gp
+nLZPlyhfPBKLZXLKPv1Sml9rjf452xTQi+zYfY62HLb0saSHWJ85eUWlydqbkg4
TtpIcfNQqNuaso8BTrqoMQ/Mnn7ryjPhqi7BonBhLrVbpCe05Nd5Qy0n4xNyjtLv
tx+kgWzYq5ROH+URKEqzKhp82lHXL/IX86w0UetvhUjlsk3QxvncE/Ta34cJct0Z
68sPGWL74MAP1MCvQdZKkZYafyvUVzsdBCV/asaIY5oEDD9MD8yaj4fCgAW9wKyR
M/oIJKyI95uajmdmvkyuzA3FGXZaM+21eaWIUGWSJolV/CIsg8QlFVd1C8yrHLvn
UJ/vCm1PC3EOkyHttCdDvMu57Ab3HHS36D0Uq7SOCUhDyY1WPmhyNUb2it02xN45
0Mpw9EYkstUILswvN/DG
=kUtK
-----END PGP SIGNATURE-----
Merge tag 'phy-for-4.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus
Kishon writes:
phy: for 4.7-rc5
*) Fix in sun4i-usb phy driver to properly handle the return value of
gpiod_to_irq
*) Fix a sparse warning in sun4i-usb phy driver
*) Fix bcm-ns-usb2 phy driver to check the correct variable
*) Fix spurious interrupts during VBUS change in rcar-gen3-usb2 phy
driver
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXaKhEAAoJEEhZKYFQ1nG7jWkH/1EzIv7rMrAtS6+GBqJO1ISD
F3LzTpYgjUOyz1MgnbSnqQjHivsxPoJLj7QK7sqcvsrKGoVAtnqBf80275N/gggf
CSjjYl+Bgw+F8oc7O/cUqTnj7oiNX6TLsIId2CEwcfxYxvkzSxwEQmB8CqMypASn
aBOKiBfCKdAI+N5gNRME+Y1Flmklrd/fTAuoNe9J3X6LlHRrKP1kjoE56rDyiwDx
VjdsP+PhTny/abnsNqA8k5776YHnsZwtl1vv4B+ndygNVjvSZ90czXsLow5LHAk4
r4TMqyX/g07nXGDTTOXRgq1wSoooebct245oZSuBCzOOIb8v/4bKgL/brkBHirg=
=TvYf
-----END PGP SIGNATURE-----
Merge tag 'usb-ci-v4.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus
Peter writes:
One fix for module support in OTG FSM
As the actual pointer value is the same for the thread stack allocation
and the thread_info, code that confused the two worked fine, but will
break when the thread info is moved away from the stack allocation. It
also looks very confusing.
For example, the kprobe code wanted to know the current top of stack.
To do that, it used this:
(unsigned long)current_thread_info() + THREAD_SIZE
which did indeed give the correct value. But it's not only a fairly
nonsensical expression, it's also rather complex, especially since we
actually have this:
static inline unsigned long current_top_of_stack(void)
which not only gives us the value we are interested in, but happens to
be how "current_thread_info()" is currently defined as:
(struct thread_info *)(current_top_of_stack() - THREAD_SIZE);
so using current_thread_info() to figure out the top of the stack really
is a very round-about thing to do.
The other cases are just simpler confusion about task_thread_info() vs
task_stack_page(), which currently return the same pointer - but if you
want the stack page, you really should be using the latter one.
And there was one entirely unused assignment of the current stack to a
thread_info pointer.
All cleaned up to make more sense today, and make it easier to move the
thread_info away from the stack in the future.
No semantic changes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for Greybus CPort flags that are sent to the bridge through
a new USB vendor request when enabling a CPort as part of connection
establishment.
Currently the Greybus control and high-priority connection flags are
recognised and forwarded to APBA.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add connection flag to indicate that a connection has high priority.
For the SVC and control connections this may be used by the host-device
driver as a hint to allocate dedicated DMA channels or to use polling to
avoid message congestion.
We also allow drivers to set this flag on their connections, even though
we currently have no use case for this (and the host-device driver is
again free to ignore it).
Note that this mechanism can be used to indicate also high-bandwidth
connections (e.g. wanting larger buffers or dedicated endpoints), but
that that should be done using a separate high-bandwidth flag rather
than overloading the high-priority flag.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Prevent drivers from specifying core flags (currently only
GB_CONNECTION_FLAG_CONTROL) when creating connections.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add a flag argument to the host-device cport_enable callback that can be
used to provide hints about the connection being created (e.g.
connection priority).
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add support for greybus RAW data format.
Greybus RAW data formats starts from 0x80.
Signed-off-by: Evgeniy Borisov <eborisov@mm-sol.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@linaro.org>
Reviewed-by: Gjorgji Rosikopulos <grosikopulos@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The return statement immediately after the BUG_ON of the gbcodec_write()
call is added by mistake. It's not causing any errors right now due to
that gbcodec_reg is currently not being used.
Testing Done:
- Audio playback on EVT2
Signed-off-by: David Lin <dtwlin@google.com>
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We know that it is a bad idea to explicitly enable IRQs when we don't
don't know if they were already off before we disabled, so switch to the
save _irqsave and _irqrestore functions.
Ultimately, we need to review places in the Greybus drivers where IRQs
are disabled and remove unnecessary instances. This is only an interim
step.
This code will never run from hard irq context, as it is already taking
mutex in the path.
Testing done: booted EVT2.0, ran suspend/resume test app with a period
of 20s for a few dozen cycles.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Jeffrey Carlyle <jcarlyle@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The greybus SVC core handles events from the SVC serially today. In some
cases the SVC operations may take too long, for example trying to
activate a dummy interface. If another interface receives a mode-switch
mailbox event in that time, the SVC core wouldn't be able to process it
in quickly enough and bootrom driver will print following error:
bootrom 1-3.3.1: Timed out waiting for Interface Mode Switch from the Module
This can be reproduced easily by attaching a 2x2 module along with any
other normal module like camera or speaker, and doing a unipro_reset
from userspace.
The logs suggest this time to be around 6-7 seconds in most of the
cases. Attaching multiple modules with dummy interfaces may make this
worst.
Lets increase the timeout from 5 to 10 seconds for now, also add a FIXME
for the same.
Testing Done: Tested on EVT 2.0 with camera and a 2x2 module.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Rename NEXT_REQ_TIMEOUT_J to NEXT_REQ_TIMEOUT_MS and store the timeout
in milliseconds instead of jiffies.
Suggested-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The timeout message is very generic today and there are several requests
we can be timing out waiting for.
Update bootrom driver to also track the next expected request and
enhance the error message based on that to confirm the request we timed
out waiting for.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The current printout on a TimeSync ping doesn't actually contain the word
greybus and uses the word ping-time in the print string, something that
appears nowhere in our official documentation on this feature. This patch
changes the format string to contain 'greybus' and 'frametime' to bring the
TimeSync printout more in-line with other greybus kernel log strings.
before:
timesync ping-time: ap=8632564 1-svc=8630712 greybus1=8633031 1-8.8=8633026
after:
greybus frametime: ap=8632564 1-svc=8630712 greybus1=8633031 1-8.8=8633026
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Remember to initialize the TimeSync ping fields to zero so that if a
timesync_get_last_event() returns an error - we display a FrameTime that is
obviously incorrect.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add support for the new Log class/protocol. This protocol allows modules
to send their internal logging messages to the AP in order to make
module debugging easier.
The protocol is, for now, composed a single module-initiated request.
This request contains a message and associated length. The message is
integrated in the kernel log with dev_dbg(). In order to be displayed
with 'dmesg', the following command needs to be entered first:
$ echo "file log.c +p" > /sys/kernel/debug/dynamic_debug/control
The major portion of this file was initially written by Greg KH.
Signed-off-by: Joel Porquet <porquet_joel@projectara.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We've had the thread info allocated together with the thread stack for
most architectures for a long time (since the thread_info was split off
from the task struct), but that is about to change.
But the patches that move the thread info to be off-stack (and a part of
the task struct instead) made it clear how confused the allocator and
freeing functions are.
Because the common case was that we share an allocation with the thread
stack and the thread_info, the two pointers were identical. That
identity then meant that we would have things like
ti = alloc_thread_info_node(tsk, node);
...
tsk->stack = ti;
which certainly _worked_ (since stack and thread_info have the same
value), but is rather confusing: why are we assigning a thread_info to
the stack? And if we move the thread_info away, the "confusing" code
just gets to be entirely bogus.
So remove all this confusion, and make it clear that we are doing the
stack allocation by renaming and clarifying the function names to be
about the stack. The fact that the thread_info then shares the
allocation is an implementation detail, and not really about the
allocation itself.
This is a pure renaming and type fix: we pass in the same pointer, it's
just that we clarify what the pointer means.
The ia64 code that actually only has one single allocation (for all of
task_struct, thread_info and kernel thread stack) now looks a bit odd,
but since "tsk->stack" is actually not even used there, that oddity
doesn't matter. It would be a separate thing to clean that up, I
intentionally left the ia64 changes as a pure brute-force renaming and
type change.
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* pm-devfreq-fixes:
PM / devfreq: Send the DEVFREQ_POSTCHANGE notification when target() is failed
PM / devfreq: fix initialization of current frequency in last status
PM / devfreq: exynos-nocp: Remove incorrect IS_ERR() check
PM / devfreq: remove double put_device
PM / devfreq: fix double call put_device
PM / devfreq: fix duplicated kfree on devfreq pointer
PM / devfreq: devm_kzalloc to have dev pointer more precisely
* pm-cpufreq-fixes:
cpufreq: pcc-cpufreq: Fix doorbell.access_width
For interrupt controllers successfully initialised early via device-tree,
mark these interrupt controllers as populated so we don't unnecessarily
create a device and populate any platform data later on in the boot
sequence when we populate all the various platform devices.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Fix a memory leak resulting from memory allocation in safe_name().
This patch fixes all call sites of safe_name().
Mathieu Malaterre reported the memory leak on boot:
On my PowerMac device-tree would generate a duplicate name:
[ 0.023043] device-tree: Duplicate name in PowerPC,G4@0, renamed to "l2-cache#1"
in this case a newly allocated name is generated by `safe_name`. However
in this case it is never deallocated.
The bug was found using kmemleak reported as:
unreferenced object 0xdf532e60 (size 32):
comm "swapper", pid 1, jiffies 4294892300 (age 1993.532s)
hex dump (first 32 bytes):
6c 32 2d 63 61 63 68 65 23 31 00 dd e4 dd 1e c2 l2-cache#1......
ec d4 ba ce 04 ec cc de 8e 85 e9 ca c4 ec cc 9e ................
backtrace:
[<c02d3350>] kvasprintf+0x64/0xc8
[<c02d3400>] kasprintf+0x4c/0x5c
[<c0453814>] safe_name.isra.1+0x80/0xc4
[<c04545d8>] __of_attach_node_sysfs+0x6c/0x11c
[<c075f21c>] of_core_init+0x8c/0xf8
[<c0729594>] kernel_init_freeable+0xd4/0x208
[<c00047e8>] kernel_init+0x24/0x11c
[<c00158ec>] ret_from_kernel_thread+0x5c/0x64
Link: https://bugzilla.kernel.org/show_bug.cgi?id=120331
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
Reported-by: mathieu.malaterre@gmail.com
Tested-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
The tip gcc includes an optimization mode that converts
64-bit divides into 128-bit multiplies using __multi3.
Export the symbol so that modules can find it. We just
export unconditionally without worrying about the gcc
version, since the symbol has been in libgcc forever and
the function is less than 300 bytes.
Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
Currently phys_to_pfn_t() is an exported symbol to allow nfit_test to
override it and indicate that nfit_test-pmem is not device-mapped. Now,
we want to enable nfit_test to operate without DMA_CMA and the pmem it
provides will no longer be physically contiguous, i.e. won't be capable
of supporting direct_access requests larger than a page. Make
pmem_direct_access() a weak symbol so that it can be replaced by the
tools/testing/nvdimm/ version, and move phys_to_pfn_t() to a static
inline now that it no longer needs to be overridden.
Acked-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
SMEM is now mapped write-combine and we can use memcpy to access the
name of the entires.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
The valid_entries index should not be incremented until after we have
acquired the pointer to the value, or we will read and write data one
item off.
Fixes: 50e9964141 ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point")
Cc: stable@vger.kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
We need the signal from wcnss_ctrl indicating that the firmware is up
and running before we can communicate with the other components of the
chip. So make these other components children of the wcnss_ctrl device,
so they can be probed in order.
The process seems to take between 1/2-5 seconds, so this is done in a
worker, instead of holding up the probe.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Add an implementation of the SCM interface that works on ARM64 SoCs. This
is used by things like determine if we have HDCP support or not on the
system.
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
This patch converts the Qualcomm SCM driver to use the streaming DMA APIs
for communication buffers. This is being done so that the
secure_flush_area call can be removed. Using the DMA APIs will also make
the SCM32 symmetric to the coming SCM64 code.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
This patch moves the qcom_scm_remap_error function to the include file
where can be used by both the 32 and 64 bit versions of the code.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This patch changes the cold_set_boot_addr function to use atomic SCM
calls. cold_set_boot_addr required adding qcom_scm_call_atomic2 to
support the two arguments going to the smc call. Using atomic removes
the need for memory allocation and instead places all arguments in
registers.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This patch converts the Qualcomm SCM firmware driver into a platform
driver. It also adds clock management for firmware calls which require
clocks to be enabled during the duration of their execution. Rate
setting of the core clock is also in place for higher performance.
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-soc@vger.kernel.org
Signed-off-by: Andy Gross <andy.gross@linaro.org>
POSIX allows files with trailing spaces or a trailing period but
SMB3 does not, so convert these using the normal Services For Mac
mapping as we do for other reserved characters such as
: < > | ? *
This is similar to what Macs do for the same problem over SMB3.
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <steve.french@primarydata.com>
Acked-by: Pavel Shilovsky <pshilovsky@samba.org>
Azure server blocks clients that open a socket and don't do anything on it.
In our reconnect scenarios, we can reconnect the tcp session and
detect the socket is available but we defer the negprot and SMB3 session
setup and tree connect reconnection until the next i/o is requested, but
this looks suspicous to some servers who expect SMB3 negprog and session
setup soon after a socket is created.
In the echo thread, reconnect SMB3 sessions and tree connections
that are disconnected. A later patch will replay persistent (and
resilient) handle opens.
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <steve.french@primarydata.com>
Acked-by: Pavel Shilovsky <pshilovsky@samba.org>
Use set_posix_acl, which includes proper permission checks, instead of
calling ->set_acl directly. Without this anyone may be able to grant
themselves permissions to a file by setting the ACL.
Lock the inode to make the new checks atomic with respect to set_acl.
(Also, nfsd was the only caller of set_acl not locking the inode, so I
suspect this may fix other races.)
This also simplifies the code, and ensures our ACLs are checked by
posix_acl_valid.
The permission checks and the inode locking were lost with commit
4ac7249e, which changed nfsd to use the set_acl inode operation directly
instead of going through xattr handlers.
Reported-by: David Sinquin <david@sinquin.eu>
[agreunba@redhat.com: use set_posix_acl]
Fixes: 4ac7249e
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
