Gioh Kim [Mon, 6 Jul 2015 06:14:41 +0000 (15:14 +0900)]
staging: ion: debugfs to shrink pool
This patch enables debugfs file /sys/kernel/debug/ion/heaps/system_shrink
to shrink pool and get pool size. This technically enables debugfs
shrinking for all heaps, not just the system heap although the system heap
is the only one with a shrinker right now. It is already implemented
but not complete. This patch completes and enables it.
Reading the file returns pool size
in page unit and writing the number of pages shrinks pool.
It flushes all pages to write zero at the file.
Signed-off-by: Gioh Kim <gioh.kim@lge.com> Reviewed-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gioh Kim [Mon, 6 Jul 2015 06:14:40 +0000 (15:14 +0900)]
staging: ion: shrink page-pool by page unit
This patch shrink page-pool by page unit.
The system shrinker calls ion_heap_shrink_count() to get nr_to_scan,
and pass it to ion_heap_shrink_scan().
The problem is the return value of ion_heap_shrink_count() is the number
of pages but ion_system_heap_shrink(), which is called by
ion_heap_shrink_scan(), gets the number of chunk.
The main root of this is that ion_page_pool_shrink() returns page count
via ion_page_pool_total() if it have to check pool size. But it frees
chunks of pages if it have to free pools.
This patch first fix ion_page_pool_shrink() to count only pages,
not chunks. And then ion_system_heap_shrink() to work on pages.
Signed-off-by: Gioh Kim <gioh.kim@lge.com> Reviewed-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vaishali Thakkar [Fri, 26 Jun 2015 04:07:25 +0000 (09:37 +0530)]
Staging: rtl8192e: Replace memset with eth_zero_addr
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
Note that the 6 in the third argument of memset appears to represent
an ethernet address size (ETH_ALEN).
The Coccinelle semantic patch that makes this change is as follows:
Jakub Sitnicki [Fri, 10 Jul 2015 16:52:21 +0000 (18:52 +0200)]
staging: rtl8188eu: fold rtl8188e_read_chip_version() into rtl8188e_SetHalODMVar()
Both rtl8188e_read_chip_version() and ReadChipVersion8188E() are used
only in one place. Make ReadChipVersion8188E() a void function and
eliminate its wrapper - rtl8188e_read_chip_version().
Signed-off-by: Jakub Sitnicki <jsitnicki@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: rtl8188eu: core: Fixed 80 character length warning
When the checkpatch.pl script was run, it showed lines with length
more than 80 characters in rtw_ap.c file. Fixed line number 382 by
breaking it up into two lines within 80 characters.
linux/ieee80211.h already defines constants for capability bits.
Include it where needed, resolve discrepancies in naming, and remove the
duplicated definitions.
Also, make use of WLAN_CAPABILITY_IS_STA_BSS() macro to check if neither
ESS nor IBSS capability bits are set.
Signed-off-by: Jakub Sitnicki <jsitnicki@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We were only using the kernel commandline to set the mode if this driver
is builtin, but when it is built as a module we were not having any way
to set the mode. Start using commandline even if it is built as a
module.
We were checking smtc_regbaseaddress and that too at a place where it
can never be NULL. Real check should be on sfb->lfb immediately after
we do ioremap.
Antonio Borneo [Tue, 23 Jun 2015 14:52:39 +0000 (22:52 +0800)]
staging: mt29f_spinand: Remove redundant spi driver bus initialization
In ancient times it was necessary to manually initialize the bus
field of an spi_driver to spi_bus_type. These days this is done in
spi_register_driver(), so we can drop the manual assignment.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: devel@driverdev.osuosl.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert a Microsoft compiler specific directive "#pragma pack(1)" to a
GCC equivalent __packed. Also, by doing this we save
ourselves from trouble if any other struct definitions are added after
the #pragma because it will be applied to all of the definitions
following it.
Vaishali Thakkar [Fri, 26 Jun 2015 04:24:00 +0000 (09:54 +0530)]
Staging: rtl8192u: Replace memset with eth_zero_addr
Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.
Note that the 6 in the third argument of memset appears to represent
an ethernet address size (ETH_ALEN).
The Coccinelle semantic patch that makes this change is as follows:
Henri Chain [Tue, 14 Jul 2015 12:59:39 +0000 (14:59 +0200)]
Staging: fbtft: Add support for the Ultrachip UC1611 LCD controller
This is a driver chip for 240x160 4-bit greyscale LCDs.
It is capable of 4-wire (8 bit) or 3-wire (9 bit) SPI that have both been
tested. (It also has a 6800 or 8080-style parallel interface, but I have
not included support for it.)
Signed-off-by: Henri Chain <henri.chain@eleves.ec-nantes.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: fbtft: Add reset to fbtft_init_display_dt()
When an init sequence is present in the Device Tree,
fbtft_init_display_dt() is used to initialize the display.
Add missing reset function call and activation of
chip select for parallel bus.
Tim Sell [Tue, 14 Jul 2015 18:43:30 +0000 (14:43 -0400)]
staging: unisys: fix random hangs with network stress in visornic
We learned that it was possible for the core networking code to call
visornic_xmit() within ISR context, resulting in the need for us to
use spin_lock_irqsave() / spin_lock_irqrestore() to lock accesses to our
virtual device channels.
Without the correct locking added in this patch, random hangs would occur
on typical kernels while stressing the netork. When using a kernel with
CONFIG_DEBUG_SPINLOCK=y, a stackdump would occur at the time of the hang
reporting:
BUG: spinlock recursion on CPU#0, vnic_incoming/<pid>
(see below for more details)
We considered the possibility of adding a protocol between a visordriver
and visorbus where the visordriver could specify which type of locking it
required for its virtual device channels (essentially indicating whether
or not it was possible for the channel to be accessed in ISR context), but
decided this extra complexity was NOT needed, and that channel queues
should always be accessed with the most-stringent locking. So that is
what is implemented in this commit.
Below is an example stackdump illustrating the spinlock recursion that is
fixed by this commit. Note that we are first in virtnic_rx() writing to
the device channel when an APIC timer interrupt occurs. Within the core
networking code, net_rx_action() calls process_backlog(), which eventually
lands up back up in virtnic_xmit() in the code attempting to also write to
the device channel.
Tim Sell [Mon, 13 Jul 2015 18:51:24 +0000 (14:51 -0400)]
staging: unisys: fix random memory corruption in visorchannel_write()
visorchannel_write() and it's user visorbus_write_channel() are
exported, so all visorbus function drivers (i.e., drivers that call
visorbus_register_visor_driver()) are potentially affected by the bug.
Because of pointer-arithmetic rules, the address being written to in the
affected code was actually at byte offset:
sizeof(struct channel_header) * offset
instead of just <offset> bytes as intended.
The bug could cause some very difficult-to-diagnose symptoms. The
particular problem that led me on this chase was a kernel fault that
would occur during 'insmod visornic' after a previous 'rmmod visornic',
where we would fault during netdev_register_kobject() within
pm_runtime_set_memalloc_noio() while traversing a device list, which
occurred because dev->parent for the visorbus device had become
corrupted.
Fixes: 0abb60c1c ('staging: unisys: visorchannel_write(): Handle...') Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Acked-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
But code in devdata_release() was treating devdata as a pointer that needed
to be kfree()d! This was causing all sorts of weird behavior after doing
an rmmod of visornic, both because free_netdev() was actually freeing the
memory used for devdata, and because devdata wasn't pointing to
dynamically-allocated memory in the first place.
The kfree(devdata) and the kref that tracked devdata's usage have been
appropriately deleted.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 9 Jul 2015 17:27:49 +0000 (13:27 -0400)]
staging: unisys: visornic: don't destroy global workqueues until devs destroyed
visornic_cleanup() was previously incorrectly destroying its global
workqueues prior to cleaning up the devices which used them. This patch
corrects the order of these operations.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 9 Jul 2015 17:27:48 +0000 (13:27 -0400)]
staging: unisys: visornic: correctly clean up device on removal
visornic_remove() is called to logically detach the visornic driver from a
visorbus-supplied device, which can happen either just prior to a
visorbus-supplied device disappearing, or as a result of an rmmod of
visornic. Prior to this patch, logic was missing to properly clean up for
this removal, which was fixed via the following changes:
* A going_away flag is now used to interlock between device destruction and
workqueue operations, protected by priv_lock. I.e., setting
going_away=true under lock guarantees that no new work items can get
queued to the work queues. going_away=true also short-circuits other
operations to enable device destruction to proceed.
* Missing clean-up operations for the workqueues, netdev, debugfs entries,
and the worker thread were added.
* Memory referenced from the visornic private devdata struct is now freed
as part of devdata destruction.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 9 Jul 2015 17:27:47 +0000 (13:27 -0400)]
staging: unisys: visornic: correct obvious double-allocation of workqueues
Looks like an errant patch fitting caused us to redundantly allocate the
workqueues at both the beginning and end of visornic_init(). This was
corrected by removing the allocations at the beginning.
Refer to Documentation/dynamic-debug-howto.txt for more details.
In addition to the new debug and error messages, a message like the
following will be logged every time a visornic device is probed, which
will enable you to map back-and-forth between visorbus device names
(e.g., "vbus2:dev0") and netdev names (e.g., "eth0"):
Tim Sell [Thu, 9 Jul 2015 17:27:45 +0000 (13:27 -0400)]
staging: unisys: neglect to NULL rcvbuf pointer
Neglect to NULL rcvbuf pointer array could result in faults later
This problem would exhibit itself as a fault when when attempting to stop
any visornic device (i.e., in visornic_disable_with_timeout() or
visornic_serverdown_complete()) that had never been started (i.e., for
which init_rcv_bufs() had never been called). Because the array of rcvbuf
was never cleared to NULLs, we would mistakenly attempt to call kfree_skb()
on garbage memory.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 9 Jul 2015 17:27:44 +0000 (13:27 -0400)]
staging: unisys: prevent faults in visornic_pause
Prevent faults in visornic_pause, visornic_resume(), and visornic_remove()
Prior to this patch, any call to visornic_pause(), visornic_resume(), or
visornic_remove() would fault, due to dev_set_drvdata() never having been
called to stash our struct visornic_devdata * into the device's drvdata.
I.e., all calls to dev_get_drvdata() were returning NULL, meaning a fault
was soon to follow.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 9 Jul 2015 17:27:43 +0000 (13:27 -0400)]
staging: unisys: visornic: correct visornic_pause
Correct visornic_pause() to indicate completion asynchronously rather
than in-line
Previously, visornic_pause() (called to stop the device due to IOVM service
partition recovery) was calling the passed complete_func() in-line, rather
than delaying the calling until after the device had actually been stopped.
The behavior has been corrected so that the calling of the complete_func()
is now delayed until after the stopping of the device has been completed in
visornic_serverdown_complete(), which runs asynchronously via the workqueue
visornic_serverdown_workqueue.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prevent faults processing messages for devices that no driver has yet
registered to handle.
Previously, code of the form:
drv = to_visor_driver(dev->device.driver);
if (!drv)
goto away;
was not having the desired intent, because to_visor_driver() was
essentially returning garbage if its argument was NULL. The only existing
case of this is in initiate_chipset_device_pause_resume(), which is called
during IOVM service partition recovery. We were thus faulting when IOVM
service partition recovery was initiated on a bus that had at least one
device for which no function driver had registered
(visorbus_register_visor_driver).
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Sell [Thu, 9 Jul 2015 17:27:41 +0000 (13:27 -0400)]
staging: unisys: respond to msgs post device_create
Fix problem that prevents us from responding to any device message after
device_create.
By neglecting to NULL out pending_msg_hdr after the device_create response,
we were effectively preventing any subsequent messages to the device from
working, because device_epilog() will correctly bail out early if it sees
that pending_msg_hdr is still set non-NULL, as that is an indicator to mean
that an unanswered message is still outstanding.
This problem was discovered as part of testing IOVM service partition
recovery, because device_epilog() was in fact bailing out when it was
called from my_device_changestate(), which of course prevented us from
transitioning the device to the paused state. However, the incorrect
behavior would occur for ANY subsequent command directed at the device,
not just for changestate.
Signed-off-by: Tim Sell <Timothy.Sell@unisys.com> Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anatoly Stepanov [Sun, 28 Jun 2015 23:44:04 +0000 (02:44 +0300)]
staging: sm750fb: add required spaces around C operators
Add spaces according to checkpatch.pl messages:
"ERROR: spaces required around that '=' (ctx:VxV)"
"ERROR: need consistent spacing around '-' (ctx:WxV)"
"ERROR: spaces required around that '?' (ctx:VxE)"
"ERROR: need consistent spacing around '&' (ctx:VxW)"
projects / karo-tx-linux.git / log