| Age | Commit message (Collapse) | Author |
|---|
|
hid-picolcd and hid-wiimote do not allow any of hidinput, hiddev or hidraw
to claim the device but still want to remain on the bus. Hence, if a
driver uses the raw_event callback but no other listener claimed the
device, we still leave it on the bus as the driver handles everything by
itself. It thus becomes its own listener.
Under some circumstances (eg., hidinput_connect() fails and raw_event set)
a device may be left on the bus even though it requires external
listeners. But then if hidinput_connect() fails there are bigger issues
than a device that is left unhandled. So we can safely use this heuristic
to avoid adding another flag for special devices like hid-picolcd and
hid-wiimote.
This also removes the ugly hack from hid-picolcd as this is no longer
required.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This SoC has two PWM channels
Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Roland Stigge <stigge@antcom.de>
|
|
Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Roland Stigge <stigge@antcom.de>
|
|
LPC32xx SoC has a 128 bits unique id that can be used as a system
serial number, if none has been provided by atags or dt.
Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Roland Stigge <stigge@antcom.de>
|
|
Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Roland Stigge <stigge@antcom.de>
|
|
The commit which added the janz-ican3 driver and commit
3ccd4c61 "can: Unify droping of invalid tx skbs and netdev stats" were
committed into mainline Linux during the same merge window.
Therefore, the addition of this code to the janz-ican3 driver was
forgotten. This patch adds the expected code.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
The code which used this variable was removed during review, before the
driver was added to mainline Linux. It is now dead code, and can be
removed.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This patch adds support for a second clock to the flexcan driver. On
modern freescale ARM cores like the imx53 and imx6q two clocks ("ipg"
and "per") must be enabled in order to access the CAN core.
In the original driver, the clock was requested without specifying the
connection id, further all mainline ARM archs with flexcan support
(imx28, imx25, imx35) register their flexcan clock without a
connection id, too.
This patch first renames the existing clk variable to clk_ipg and
converts it to devm for easier error handling. The connection id "ipg"
is added to the devm_clk_get() call. Then a second clock "per" is
requested. As all archs don't specify a connection id, both clk_get
return the same clock. This ensures compatibility to existing flexcan
support and adds support for imx53 at the same time.
After this patch hits mainline, the archs may give their existing
flexcan clock the "ipg" connection id and implement a dummy "per"
clock.
This patch has been tested on imx28 (unmodified clk tree) and on imx53
with a seperate "ipg" and "per" clock.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: Hui Wang <jason77.wang@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
This patch marks the bittiming_const pointer as in the struct can_pric as
"const". This allows us to mark the struct can_bittiming_const in the CAN
drivers as "const", too.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
As we take the struct_mutex lock to access the command-stream, there is
a possibility that we may need to wait for a GPU hang and so should make
the lock both interruptible and error-checking.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50069
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When we enable/disable the CPU backlight registers we can't forget to
enable/disable the PCH backlight registers. Since we're using the CPU
registers we should also unset the override bit.
Fixes a regression on the following commit:
drm/i915: properly enable the blc controller on the right pipe
The commit just deleted the code that sets the PCH registers, so it
was relying on the values set by the BIOS. I told my BIOS to boot on
the DVI monitor instead of the LVDS panel, so I noticed the bug.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
If we drop the breadcrumb request after a batch due to a signal for
example we aim to fix it up at the next opportunity. In this case we
emit a second batchbuffer with no waits upon the first and so no
opportunity to insert the missing request, so we need to emit the
missing flush for coherency. (Note that that invalidating the render
cache is the same as flushing it, so there should have been no
observable corruption.)
Note that beside simply adding the missing flush, avoiding potential
render corruption, this will also fix at least parts of the problem
introduced by some funny interaction of these two commits:
commit de2b998552c1534e87bfbc51ec5734b02bc89020
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jul 4 22:52:50 2012 +0200
drm/i915: don't return a spurious -EIO from intel_ring_begin
which allowed intel_ring_begin to return -ERESTARTSYS and
commit cc889e0f6ce6a63c62db17d702ecfed86d58083f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 13 20:45:19 2012 +0200
drm/i915: disable flushing_list/gpu_write_list
which essentially disabled the flushing list.
The issue happens when we submit a batch & emit it, but get
interrupted (thanks to the first patch) while trying to emit the
flush. On the next batch we still assume that the full gpu domain
handling is in effect and hence compute the invalidate&flushing
domains. But thanks to the 2nd patch we totally ignore these and only
invalidate all gpu domains, presuming that any required flushes have
been issued already. Which is wrong and eventually results in us
updating the new write_domain values with the computed
pending_write_domain values, which leaves an object with write_domain
== 0 on the gpu_write_list.
As soon as we try to unbind that object, things blow up.
Fix this by emitting the missing flush according to the new
ring->gpu_caches_dirty flag.
Note that this does _not_ fix all the current cases where we end up
with an object on the flushing_list that can't be flushed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52040
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add bug explanation to commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Or going from tiled to untiled may break.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
While debugging Haswell link train failures I observed that we never
try the maximum voltage configuration more than once consecutively. We
start the training, the monitor keeps telling us to increase the
voltage, then when we reach the maximum we just go back to the start
(because of the "memset" above "voltage_tries = 0"). When we reach
this point, we keep alternating between the maximum and the minimum
voltages until we give up.
The DP spec suggests that we should try the same voltage 5 times
before giving up. This patch makes us try the maximum voltage at
least 5 times before going back to the minimum voltages.
This patch does not fix any particular bug I'm aware of.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We have way too much lying hardware to rely on a simple "does someone
answer on the ddc i2c address?" check. And now it's unused, so just
kill it.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Somehow detect_ddc manages to fall through all checks when we think
that something responds on the ddc i2c address, but the edid read
failed. Fix this up by explicitly checking for this case.
This fixes a regression on newer chips because since
commit aaa377302b2994fcc2c66741b47da33feb489dca
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jun 16 15:30:32 2012 +0200
drm/i915/crt: Do not rely upon the HPD presence pin
we use ddc detection also on hotplug capable platforms. And one of
these reads all 0s for any i2c transaction if nothing is connected to
the vga port.
v2: Implement Chris Wilson's review:
- simplify logic, default to "nothing detected"
- kill stale comment
- BUG_ON(!crt->type != ANALOG)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51900
Tested-by: Yang Guang <guang.a.yang@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
I so totally suck.
This can cause a black screen if (for whatever reason) the bios
hasn't set this bit itself.
This regression has been introduced in
commit 7cf4160148136deb31ee5f2802857dd935a38529
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 5 10:07:09 2012 +0200
drm/i915: clear up backlight #define confusion on gen4+
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Having had to dive into the bspec to understand what each stage of the
workaround meant, and how that the ring broadcasting IDLE corresponded
with the GT powering down the ring (i.e. rc6) add comments to aide
the next reader.
And since the register "is used to control all aspects of PSMI and power
saving functions" that makes it quite interesting to inspect with
regards to RC6 hangs, so add it to the error-state.
v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for
the ring to wake up.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It never quite worked despite the numerous workarounds, yet I still see
people trying to use this hardware and filing bug reports. As we no
longer even try to implement the workarounds, since 6a233c78878
(drm/i915/ringbuffer: kill snb blt workaround), simply disable the ring.
v2: Add a message to inform the user about the limited capabilities of
their pre-production hardware.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This initializes power wells within the modeset_init_hw routine.
Testing has shown that this works for both driver load time and for
suspend-resume code paths.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
There is little point waking up every 10ms to service an interrupt which
we then promptly ignore. So only program the the PMIER to enable
interrupts for those events which we do handle, not all of them!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
There were some fields missed. Daniel pointed this out in review, and I
know I fixed it, but something happened somehow and some time.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
*sigh* the docs had it spelled wrong, corrected it, and then proceeded
to re-do the original error. The original code preserved this history,
and this patch attempts to keep in sync with the current docs.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
TI LP8788 PMU has 4 BUCKS and 22 LDOs.
The voltage of BUCK1 and BUCK2 can be controlled by external gpios.
And some LDOs also can be enabled by external gpios.
The regmap interface is used for regulator operations.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This function does not exist, remove the extern function declaration.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The dma_map and dma_unmap should have same parameter
passed otherwise we get the below warn.
ks8851 spi1.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000009f22]
[ 2.066925] Modules linked in:
[ 2.070312]
[ 2.071929] [<c001c250>] (unwind_backtrace+0x0/0x130) from [<c0043d84>] (warn_slowpath_common+0x4c/0x64)
[ 2.081909] [<c0043d84>] (warn_slowpath_common+0x4c/0x64) from [<c0043e30>] (warn_slowpath_fmt+0x30/0x40)
[ 2.091949] [<c0043e30>] (warn_slowpath_fmt+0x30/0x40) from [<c0293824>] (check_unmap+0x6d0/0x7b0)
[ 2.101348] [<c0293824>] (check_unmap+0x6d0/0x7b0) from [<c02939cc>] (debug_dma_unmap_page+0x64/0x70)
[ 2.111053] [<c02939cc>] (debug_dma_unmap_page+0x64/0x70) from [<c03519a4>] (omap2_mcspi_txrx_dma+0x2d8/0x4fc)
[ 2.121582] [<c03519a4>] (omap2_mcspi_txrx_dma+0x2d8/0x4fc) from [<c03524d8>] (omap2_mcspi_work.clone.4+0xf0/0x290)
[ 2.132537] [<c03524d8>] (omap2_mcspi_work.clone.4+0xf0/0x290) from [<c0352900>] (omap2_mcspi_transfer_one_message+0x288/0x438)
[ 2.144592] [<c0352900>] (omap2_mcspi_transfer_one_message+0x288/0x438) from [<c03503bc>] (spi_pump_messages+0x100/0x160)
[ 2.156127] [<c03503bc>] (spi_pump_messages+0x100/0x160) from [<c006635c>] (kthread_worker_fn+0xac/0x180)
[ 2.166168] [<c006635c>] (kthread_worker_fn+0xac/0x180) from [<c0066578>] (kthread+0x90/0x9c)
[ 2.175140] [<c0066578>] (kthread+0x90/0x9c) from [<c00157fc>] (kernel_thread_exit+0x0/0x8)
[ 2.183898] ---[ end trace d1830ce6e44292f2 ]---
Fix the warn by changing the unmap parameter.
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This patch adds support for the I2C-SPI bridge which can be found on the Analog
Devices AD-FMCOMMS1-EBZ board.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The policy might have been changed since last call of target().
Thus, using cpufreq_frequency_table_target(), which depends on
policy to find the corresponding index from a frequency, may return
inconsistent index for freqs.old. Thus, old_index should be
calculated not based on the current policy.
We have been observing such issue when scaling_min/max_freq were
updated and sometimes cuased system lockups deu to incorrectly
configured voltages.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
This patch (as1597) fixes some of the error paths in usbhid's suspend
routine. The driver was not careful to restart everything that might
have been stopped, in cases where a suspend failed.
For example, once the HID_SUSPENDED flag is set, an output report
submission would not restart the corresponding URB queue. If a
suspend fails, it's therefore necessary to check whether the queues
need to be restarted.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch (as1596) improves the queue-restart logic in usbhid by
checking to see if the device is suspended or a reset is about to
occur. There's no point submitting an URB if either of those is
true.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch (as1595) improves the usbhid driver by using the
HID_SUSPENDED bitflag to indicate that the device is suspended rather
than using HID_REPORTED_IDLE, which the patch removes.
Since HID_SUSPENDED was not being used for anything, and since the
name "HID_REPORTED_IDLE" doesn't convey much meaning, the end result
is easier to read and understand.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch (as1594) simplifies the usbhid driver by inlining a couple
of routines. As a result of an earlier patch, irq_out_pump_restart()
and ctrl_pump_restart() are each used in only one place. Since they
don't really do what their names say, and since they each involve only
about two lines of actual code, there's no reason to keep them as
separate functions.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch (as1593) fixes some logic errors in the usbhid driver
relating to runtime PM. The driver does not balance its calls to
usb_autopm_get_interface_async() and usb_autopm_put_interface_async().
For example, when the control queue is restarted the driver does a
_get. But the resume won't happen immediately, so the driver leaves
the queue stopped. When the resume does occur, the queue is restarted
and a second _get occurs, with no balancing _put.
The patch fixes the problem by rearranging the logic for restarting
the queues. All the _get/_put calls and bitflag settings in
__usbhid_submit_report() are moved into the queue-restart routines. A
balancing _put call is added for the case where the queue is still
suspended. A call to irq_out_pump_restart(), which doesn't take all
the right actions for restarting the irq-OUT queue, is replaced by a
call to usbhid_restart_out_queue(), which does. Similarly for
ctrl_pump_restart().
Finally, new code is added to prevent an autosuspend from happening
every time an URB is cancelled, and the comments explaining what
happens when an URB needs to be cancelled are expanded and clarified.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This patch (as1592) fixes an obscure problem in the usbhid driver.
Under some circumstances, a control or interrupt-OUT URB can be
submitted twice. This will happen if the first submission fails; the
queue pointers aren't updated, so the next time the queue is restarted
the same URB will be submitted again.
The problem is that raw_report gets deallocated during the first
submission. The second submission will then dereference and try to
free an already-freed region of memory. The patch fixes the problem
by setting raw_report to NULL when it is deallocated and checking for
NULL before dereferencing it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The current virtual timer interface is inherently per-cpu and hard to
use. The sole user of the interface is appldata which uses it to execute
a function after a specific amount of cputime has been used over all cpus.
Rework the virtual timer interface to hook into the cputime accounting.
This makes the interface independent from the CPU timer interrupts, and
makes the virtual timers global as opposed to per-cpu.
Overall the code is greatly simplified. The downside is that the accuracy
is not as good as the original implementation, but it is still good enough
for appldata.
Reviewed-by: Jan Glauber <jang@linux.vnet.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Remove the file name from the comment at top of many files. In most
cases the file name was wrong anyway, so it's rather pointless.
Also unify the IBM copyright statement. We did have a lot of sightly
different statements and wanted to change them one after another
whenever a file gets touched. However that never happened. Instead
people start to take the old/"wrong" statements to use as a template
for new files.
So unify all of them in one go.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
|
|
If lgr has not been initialized, the lgr_info_log() function currently
crashes because 'lgr_page' is not allocated. To fix this 'lgr_page'
is allocated statically now.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
It is very common for the end of the file to be unaligned on
stripe size. But since we know it's beyond file's end then
the XOR should be preformed with all zeros.
Old code used to just read zeros out of the OSD devices, which is a great
waist. But what scares me more about this situation is that, we now have
pages attached to the file's mapping that are beyond i_size. I don't
like the kind of bugs this calls for.
Fix both birds, by returning a global zero_page, if offset is beyond
i_size.
TODO:
Change the API to ->__r4w_get_page() so a NULL can be
returned without being considered as error, since XOR API
treats NULL entries as zero_pages.
[Bug since 3.2. Should apply the same way to all Kernels since]
CC: Stable Tree <stable@kernel.org>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
|
|
[Bug since 3.2 Kernel]
CC: Stable Tree <stable@kernel.org>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
|
|
The read-4-write pages are locked in address ascending order.
But where unlocked in a way easiest for coding. Fix that,
locks should be released in opposite order of locking, .i.e
descending address order.
I have not hit this dead-lock. It was found by inspecting the
dbug print-outs. I suspect there is an higher lock at caller that
protects us, but fix it regardless.
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
|
|
Do to OOM situations the ore might fail to allocate all resources
needed for IO of the full request. If some progress was possible
it would proceed with a partial/short request, for the sake of
forward progress.
Since this crashes NFS-core and exofs is just fine without it just
remove this contraption, and fail.
TODO:
Support real forward progress with some reserved allocations
of resources, such as mem pools and/or bio_sets
[Bug since 3.2 Kernel]
CC: Stable Tree <stable@kernel.org>
CC: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
|
|
In RAID_5/6 We used to not permit an IO that it's end
byte is not stripe_size aligned and spans more than one stripe.
.i.e the caller must check if after submission the actual
transferred bytes is shorter, and would need to resubmit
a new IO with the remainder.
Exofs supports this, and NFS was supposed to support this
as well with it's short write mechanism. But late testing has
exposed a CRASH when this is used with none-RPC layout-drivers.
The change at NFS is deep and risky, in it's place the fix
at ORE to lift the limitation is actually clean and simple.
So here it is below.
The principal here is that in the case of unaligned IO on
both ends, beginning and end, we will send two read requests
one like old code, before the calculation of the first stripe,
and also a new site, before the calculation of the last stripe.
If any "boundary" is aligned or the complete IO is within a single
stripe. we do a single read like before.
The code is clean and simple by splitting the old _read_4_write
into 3 even parts:
1._read_4_write_first_stripe
2. _read_4_write_last_stripe
3. _read_4_write_execute
And calling 1+3 at the same place as before. 2+3 before last
stripe, and in the case of all in a single stripe then 1+2+3
is preformed additively.
Why did I not think of it before. Well I had a strike of
genius because I have stared at this code for 2 years, and did
not find this simple solution, til today. Not that I did not try.
This solution is much better for NFS than the previous supposedly
solution because the short write was dealt with out-of-band after
IO_done, which would cause for a seeky IO pattern where as in here
we execute in order. At both solutions we do 2 separate reads, only
here we do it within a single IO request. (And actually combine two
writes into a single submission)
NFS/exofs code need not change since the ORE API communicates the new
shorter length on return, what will happen is that this case would not
occur anymore.
hurray!!
[Stable this is an NFS bug since 3.2 Kernel should apply cleanly]
CC: Stable Tree <stable@kernel.org>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
|
|
Also add a model/fixup string "lenovo-dock", so that other Thinkpad
users will be able to test this fixup easily, to see if it enables
dock I/O for them as well.
Cc: stable@kernel.org
BugLink: https://bugs.launchpad.net/bugs/1026953
Tested-by: John McCarron <john.mccarron@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Obsoleted since commit 7c5763b8453a94871d356f20df30f350f8631e8b ("drivers:
misc: Remove MISC_DEVICES config option")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Correct spelling typo in cpufreq driver.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Correcting spelling typo in mach-omap2
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
