| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts Linux 4.1-rc1 commit 0618764cb25f6fa9fb31152995de42a8a0496475.
The problem which that commit attempts to fix actually lies in the
Freescale CAAM crypto driver not dm-crypt.
dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto
driver should internally backlog requests which arrive when the queue is
full and process them later. Until the crypto hw's queue becomes full,
the driver returns -EINPROGRESS. When the crypto hw's queue if full,
the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
expected to backlog the request and process it when the hardware has
queue space. At the point when the driver takes the request from the
backlog and starts processing it, it calls the completion function with
a status of -EINPROGRESS. The completion function is called (for a
second time, in the case of backlogged requests) with a status/err of 0
when a request is done.
Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request()
and crypto_get_backlog() helpers to implement this behaviour correctly,
while others implement this behaviour without these helpers (ccp, for
example).
dm-crypt (before the patch that needs reverting) uses this API
correctly. It queues up as many requests as the hw queues will allow
(i.e. as long as it gets back -EINPROGRESS from the request function).
Then, when it sees at least one backlogged request (gets -EBUSY), it
waits till that backlogged request is handled (completion gets called
with -EINPROGRESS), and then continues. The references to
af_alg_wait_for_completion() and af_alg_complete() in that commit's
commit message are irrelevant because those functions only handle one
request at a time, unlink dm-crypt.
The problem is that the Freescale CAAM driver, which that commit
describes as having being tested with, fails to implement the
backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware
queue is full, it simply returns -EBUSY without backlogging the request.
What the observed deadlock was is not described in the commit message
but it is obviously the wait_for_completion() in crypto_convert() where
dm-crypto would wait for the completion being called with -EINPROGRESS
in the case of backlogged requests. This completion will never be
completed due to the bug in the CAAM driver.
Commit 0618764cb25 incorrectly made dm-crypt wait for every request,
even when the driver/hardware queues are not full, which means that
dm-crypt will never see -EBUSY. This means that that commit will cause
a performance regression on all crypto drivers which implement the API
correctly.
Revert it. Correct backlog handling should be implemented in the CAAM
driver instead.
Cc'ing stable purely because commit 0618764cb25 did. If for some reason
a stable@ kernel did pick up commit 0618764cb25 it should get reverted.
Signed-off-by: Rabin Vincent <[email protected]>
Reviewed-by: Horia Geanta <[email protected]>
Cc: [email protected]
Signed-off-by: Mike Snitzer <[email protected]>
|
|
Pull crypto fixes from Herbert Xu:
"This fixes a build problem with bcm63xx and yet another fix to the
memzero_explicit function to ensure that the memset is not elided"
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
hwrng: bcm63xx - Fix driver compilation
lib: make memzero_explicit more robust against dead store elimination
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"Three driver fixes:
- fix for omap4, fixing a regression due to a subsystem API that got
removed for 4.1 (commit efde234674d9);
- fix for one of the formats supported by Marvel ccic driver;
- fix rcar_vin driver that, when stopping abnormally, the driver
can't return from wait_for_completion"
* tag 'media/v4.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] v4l: omap4iss: Replace outdated OMAP4 control pad API with syscon
[media] media: soc_camera: rcar_vin: Fix wait_for_completion
[media] marvell-ccic: fix Y'CbCr ordering
|
|
Since parse_perf_probe_point() deals with a user passed argument, we
should not assume it to be a valid string.
Without this patch, if pass '' to perf probe, a segfault raises:
$ perf probe -a ''
Segmentation fault
This patch checks argument of parse_perf_probe_point() before
string processing.
After this patch:
$ perf probe -a ''
usage: perf probe [<options>] 'PROBEDEF' ['PROBEDEF' ...]
or: perf probe [<options>] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
...
Signed-off-by: Wang Nan <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Tested-by: Arnaldo Carvalho de Melo <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Zefan Li <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
I spotted two (difficult to hit) bugs while reviewing this.
1) There is a double free bug because we unregister "map_kset" in
add_sysfs_runtime_map_entry() and also efi_runtime_map_init().
2) If we fail to allocate "entry" then we should return
ERR_PTR(-ENOMEM) instead of NULL.
Signed-off-by: Dan Carpenter <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Guangyu Sun <[email protected]>
Cc: <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
|
|
Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
as a BTO option, both versions used dual channel LVDS even though
the smaller one would have fit into a single channel.
Notes:
Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
channel LVDS (this lead to it being hardcoded in intel_lvds.c by
Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc):
https://bugzilla.kernel.org/show_bug.cgi?id=42842
If i915.lvds_channel_mode=2 is missing even though the machine needs
it, every other vertical line is white and consequently, only the left
half of the screen is visible (verified by myself on a MacBookPro9,1).
Forum posting concerning a MacBookPro6,2 with 1440x900, author is
using i915.lvds_channel_mode=2 on the kernel command line, proving
that the machine uses dual channels:
https://bbs.archlinux.org/viewtopic.php?id=185770
Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
MacBook Pro "A1286" models, and that model number encompasses the
MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
driven with dual channel LVDS:
http://www.ebay.com/itm/-/400690878560
http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf
Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
with i915 graphics and dual channel LVDS, so that list should be
complete. And the 8,2 is already in intel_lvds.c.
Possible motivation to use dual channel LVDS even on the 1440x900
models: Reduce the number of different parts, i.e. use identical logic
boards and display cabling on both versions and the only differing
component is the panel.
Signed-off-by: Lukas Wunner <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Cc: [email protected]
[Jani: included notes in the commit message for posterity]
Signed-off-by: Jani Nikula <[email protected]>
|
|
Single channel LVDS maxes out at 112 MHz, anything above must be dual
channel. This avoids the need to specify i915.lvds_channel_mode=2 on
all 17" MacBook Pro models with i915 graphics since they had 1920x1200
(193 MHz), plus those 15" pre-retina models which had a resolution
of 1680x1050 (119 MHz) as a BTO option.
Source for 112 MHz limit of single channel LVDS is section 2.3 of:
https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf
v2: Avoid hardcoding 17" models by assuming dual channel LVDS if the
resolution necessitates it, suggested by Jani Nikula.
v3: Fix typo, thanks Joonas Lahtinen.
v4: Split commit in two, suggested by Ville Syrjälä.
Signed-off-by: Lukas Wunner <[email protected]>
Tested-by: Lukas Wunner <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Cc: [email protected]
[Jani: included spec reference into the commit message]
Signed-off-by: Jani Nikula <[email protected]>
|
|
bug: https://bugzilla.kernel.org/show_bug.cgi?id=97701
Reported-by: Mikael Pettersson <[email protected]>
Tested-by: Mikael Pettersson <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
The qib driver uses a mmap() special case for when PAT is
not used, this behaviour used to be determined with a
module parameter but since we have been asked to just
remove that module parameter this checks for the WC cookie,
if not set we can assume PAT was used. If its set we do
what we used to do for the mmap for when MTRR was enabled.
The removal of the module parameter is OK given that Andy
notes that even if users of module parameter are still around
it will not prevent loading of the module on recent kernels.
Cc: Doug Ledford <[email protected]>
Cc: Toshi Kani <[email protected]>
Cc: Rickard Strandqvist <[email protected]>
Cc: Mike Marciniszyn <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Sean Hefty <[email protected]>
Cc: Hal Rosenstock <[email protected]>
Cc: Dennis Dalessandro <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Stefan Bader <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Roger Pau Monné <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani <[email protected]>
Cc: Suresh Siddha <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Juergen Gross <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Antonino Daplas <[email protected]>
Cc: Jean-Christophe Plagniol-Villard <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Mike Marciniszyn <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: Sean Hefty <[email protected]>
Cc: Hal Rosenstock <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Luis R. Rodriguez <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
While unmapping an ODP writable page, the dirty bit of the page is set. In
order to do so, the head of the compound page is found.
Currently, the compound head is found even on non-writable pages, where it is
never used, leading to unnecessary cpu barrier that impacts performance.
This patch moves the search for the compound head to be done only when needed.
Signed-off-by: Guy Shapiro <[email protected]>
Acked-by: Shachar Raindel <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
Currently, while mapping or unmapping pages for ODP, the umem mutex is locked
and unlocked once for each page. Such lock/unlock operation take few tens to
hundreds of nsecs. This makes a significant impact when mapping or unmapping few
MBs of memory.
To avoid this, the mutex should be locked only once per operation, and not per
page.
Signed-off-by: Guy Shapiro <[email protected]>
Acked-by: Shachar Raindel <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
Get the actual (non-mapped) ip/tcp address of the connecting peer from
the port mapper
Also setup the passive side endpoint to correctly display the actual
and mapped addresses for the new connection.
Signed-off-by: Steve Wise <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
Get the actual (non-mapped) ip/tcp address of the connecting peer from
the port mapper and report the address info to the user space application
at the time of connection establishment
Signed-off-by: Tatyana Nikolova <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
connecting peer to its clients
Add functionality to enable the port mapper on the passive side to provide to its
clients the actual (non-mapped) ip/tcp address information of the connecting peer
1) Adding remote_info_cb() to process the address info of the connecting peer
The address info is provided by the user space port mapper service when
the connection is initiated by the peer
2) Adding a hash list to store the remote address info
3) Adding functionality to add/remove the remote address info
After the info has been provided to the port mapper client,
it is removed from the hash list
Signed-off-by: Tatyana Nikolova <[email protected]>
Reviewed-by: Steve Wise <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
Currently the iw_cxgb4 implementation requires the qp and cq qid densities
to match as well as the qp and cq id ranges. So fail a device open if
the device configuration doesn't meet the requirements.
The reason for these restictions has to do with the fact that IQ qid X
has a UGTS register in the same bar2 page as EQ qid X. Thus both qids
need to be allocated to the same user process for security reasons.
The logic that does this (the qpid allocator in iw_cxgb4/resource.c)
handles this but requires the above restrictions.
Signed-off-by: Steve Wise <[email protected]>
Signed-off-by: Hariprasad Shenai <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
For T5, we must not use the kdb/kgts registers, in order avoid db drops
under extreme loads.
Signed-off-by: Steve Wise <[email protected]>
Signed-off-by: Hariprasad Shenai <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
- get_dma_mr() was using ~0UL which is should be ~0ULL. This causes the
DMA MR to get setup incorrectly in hardware.
- wr_log_show() needed a 64b divide function div64_u64() instead of
doing
division directly.
- fixed warnings about recasting a pointer to a u64
Signed-off-by: Steve Wise <[email protected]>
Signed-off-by: Hariprasad Shenai <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
Cleanup macros and register defines for consistency
Signed-off-by: Hariprasad Shenai <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to
canonize the address family to IPv4, but does not properly process
the listening sockaddr to get the listening port, and does not properly
set the address family of the canonized sockaddr.
Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")
Cc: <[email protected]>
Reported-By: Yotam Kenneth <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Tested-by: Haggai Eran <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
|
|
Add ALC3266 for Dell platform.
Signed-off-by: Kailang Yang <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
A spinlock is regarded as contended when there is at least one waiter.
Currently, the code that checks whether there are any waiters rely on
tail value being greater than head. However, this is not true if tail
reaches the max value and wraps back to zero, so arch_spin_is_contended()
incorrectly returns 0 (not contended) when tail is smaller than head.
The original code (before regression) handled this case by casting the
(tail - head) to an unsigned value. This change simply restores that
behavior.
Fixes: d6abfdb20223 ("x86/spinlocks/paravirt: Fix memory corruption on unlock")
Signed-off-by: Tahsin Erdogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
The page_follow_link_light returns NULL and its error pointer was remained
in nd->path.
Reported-by: Dan Carpenter <[email protected]>
Reviewed-by: Chao Yu <[email protected]>
Signed-off-by: Jaegeuk Kim <[email protected]>
|
|
This reports performance regression by Yuanhan Liu.
The basic idea was to reduce one-point mutex, but it turns out this causes
another contention like context swithes.
https://lkml.org/lkml/2015/4/21/11
Until finishing the analysis on this issue, I'd like to revert this for a while.
This reverts commit 78373b7319abdf15050af5b1632c4c8b8b398f33.
|
|
Normally if driver is busy to dispatch a request the logic is like below:
block layer: driver:
__blk_mq_run_hw_queue
a. blk_mq_stop_hw_queue
b. rq add to ctx->dispatch
later:
1. blk_mq_start_hw_queue
2. __blk_mq_run_hw_queue
But it's possible step 1-2 runs between a and b. And since rq isn't in
ctx->dispatch yet, step 2 will not run rq. The rq might get lost if
there are no subsequent requests kick in.
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
When a FUA request enters its DATA stage of flush pipeline, the
request is added to mq requeue list, the request will then be added to
ctx->rq_list. blk_mq_attempt_merge() might merge the request with a bio.
Later when the request is finished the flush pipeline, the
request->__data_len is 0. Then I only saw the bio gets endio called, the
original request never finish.
Adding REQ_FLUSH_SEQ into REQ_NOMERGE_FLAGS looks an easy fix.
stable: 3.15+
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
Hardware doesn't seem to work correctly, just block userspace in this case.
v2: add missing defines
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320
Signed-off-by: Christian König <[email protected]>
CC: [email protected]
Signed-off-by: Alex Deucher <[email protected]>
|
|
The L3 Error handling on OMAP5 for the most part is very similar
to that of OMAP4, and had leveraged common data structures and
register layout definitions so far. Upon closer inspection, there
are a few minor differences causing an incorrect decoding and
reporting of the master NIU upon an error:
1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies
11 bits on OMAP5 as against 8 bits on OMAP4, with the master
NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR
field.
2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3
input sources on OMAP5. The common DEBUGSS source is at a
different input on each SoC.
Fix the above issues by using a OMAP5-specific compatible property
and using SoC-specific data where there are differences.
Signed-off-by: Suman Anna <[email protected]>
Acked-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x44800000, so correct offset is 0x800000. DRA7 TRM rev X(fewb 2015)
has updates for this information.
With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: Illia Smyrnov <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Fix a typo in DRA7 dtsi where 12 bytes are needed for register
description of ABB efuse registers, however only 8 bytes are provided
to map. For some weird reason, this does not generate abort at offset
0x8, probably due to default maps already provided in io.c for the bus
register ranges.
Reported-by: Matt Gessner <[email protected]>
Reported-by: Suman Anna <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
BeagleBoard-X15 pre-production change includes switching the GPIO fan
gpio over from 1 to 2 to allow for a potential fix at a later point in
time for USB client VBUS detection using PMIC VBUS detect capability.
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
BeagleBoard-X15 pre-production change includes switching over to UART
pins that now allow for UART download capability. All original boards
should either have been returned for modifications or already modified
for the required change and maintaining compatibility for older boards
are no longer needed.
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The new AM437x SK Beta boards have removed the
large capacitors on the gpio-matrix column lines
which means we can reduce col-scan-delay-us to 5us
without loosing functionality.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
AM437x Starter Kit uses a NewHaven Display module with
a 4.3" display and EDT FT5306 touchscreen
On that module's new revision, NewHave decided to change
the pinout on the 6 pin flat-pcb touchscreen connector so
that instead of having WAKE pin, we now have RESETn.
The new display module is available on AM437x SK Beta and
all new revisions while the older revision is only available
on AM437x SK Alpha which, unfortunately, can't be supported
anymore in mainline without a revert of this patch.
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
With commit bc078316d86c ("ARM: dts: DRA7: Add node for RTC"), we now
have AM57xx RTC register itself as alias 0 even before DS1307 or TPS
rtc drivers are loaded up. However, since neither TPS, nor AM57xx RTC
are capable of being backedup by battery, we would like to maintain
the "primary" rtc as mcp79410 rtc device.
This also generates the following warnings in the bootlog highlighting
the issue:
[ 5.895445] rtc-ds1307 2-006f: /aliases ID 0 not available
...
[ 6.476285] palmas-rtc 48070000.i2c:tps659038@58:tps659038_rtc: /aliases ID 1 not available
So, add proper aliases to ensure that RTC order is always consistent
to userspace immaterial of probe order.
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
The interrupt polarity provided in devicetree is used to configure
the interrupt controller(ARM GIC), however, it seems that we have an
inverter at the GIC boundary inside AM57xx which inverts the signal
input from sys_irq external interrupt source.
Further, as per GIC distributor TRM,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438d/BGBHIACJ.html#BABJFCFB
ARM GIC distributor does not support IRQ trigger type
IRQ_TYPE_LEVEL_LOW, and only rising or level high signals.
However, for some reason, the current configuration(which gets ignored
by GIC driver) functions on some platforms, however, on few platforms
results in infinite interrupts hogging the system down.
Switch over to rising edge for GIC configuration which is also aligned
with trigger point from the RTC chip and the internal inversion.
Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Add missing #iommu-cells property to the isp and iva iommu nodes. This
fixes the binding (property is required according to the generic iommu
binding) and removes the following kernel warning triggered once the
iommu nodes are referenced:
[ 0.647521] /ocp/isp@480bc000: could not get #iommu-cells for /ocp/mmu@480bd400
Signed-off-by: Sebastian Reichel <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes: c08a54c0ebeb ("ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB")
Reported-by: Nishant Menon <[email protected]>
Signed-off-by: Roger Quadros <[email protected]>
Acked-by-by: Nishanth Menon <[email protected]
Tested-by: Nishanth Menon <[email protected]
Reviewed-by: Felipe Balbi <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
N900 audio recording needs that codec provides bias voltage for integrated
digital microphone and headset microphone depending which one is used.
Digital microphone uses 2 V bias and it comes from the codec A part. Codec
B part drives the headset microphone bias and that is set to 2.5 V.
Cc: [email protected] # v3.16+
Signed-off-by: Pavel Machek <[email protected]>
[Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit
e2e8bfdf6157 ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")]
Signed-off-by: Jarkko Nikula <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Turns out this is because of erratum i531 "Extra Power Consumed
When Repeated Start Operation Mode Is Enabled on I2C Interface
Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth
Menon <[email protected]>.
Let's fix the issue by adding i2c_cfg_clear_mask for the bits
to clear when initializing the I2C4 adapter so we can clear
SREN bit that drives the I2C4 lines low otherwise when there
is no traffic.
Fixes: 3b8c4ebb7630 ("ARM: OMAP3: Fix idle mode signaling for
Cc: [email protected] # v3.16+
sys_clkreq and sys_off_mode")
Cc: Kevin Hilman <[email protected]>
Cc: Tero Kristo <[email protected]>
Reviewed-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
|
|
set_dai_fmt_both() callback is called from snd_soc_runtime_set_dai_fmt()
which is called from snd_soc_register_card(), but at this time codec
is not powered on yet. Replace direct i2c write with regcache write.
Fixes: 5f0acedddf533c (ASoC: rx1950_uda1380: Use static DAI format setup)
Fixes: 5cc10b9b77c234 (ASoC: h1940_uda1380: Use static DAI format setup)
Signed-off-by: Vasily Khoruzhick <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
|
|
Commit eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device
enumeration) changed the way how ACPI devices are enumerated and when
they are added to the PNP bus.
However, it broke the sound card support on (at least) a vintage
IBM ThinkPad 600E: with said commit applied, two of the necessary
"CSC01xx" devices are not added to the PNP bus and hence can not be
found during the initialization of the "snd-cs4236" module. As a
consequence, loading "snd-cs4236" causes null pointer exceptions.
The attached patch fixes the problem end re-enables sound on the
IBM ThinkPad 600E.
Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Witold Szczeponik <[email protected]>
Cc: 3.16+ <[email protected]> # 3.16+
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
cppcheck detected an uninitialized variable:
[drivers/pinctrl/mediatek/pinctrl-mtk-common.c:897]:
(error) Uninitialized variable: unmask
unmask should be initialized to zero to ensure unmasking
only occurs if a previous mask occurred. The current situation
is that the unmask variable could contain any random garbage
causing random unexpected unmasking.
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
The first paragraph in Documentation/acpi/gpio-properties.txt is
ambiguous, so make it more clear.
Reported-by: Antonio Ospite <[email protected]>
Acked-by: Antonio Ospite <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Delete more one break for ALC286/ALC288.
Signed-off-by: Kailang Yang <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
- s/clk_didsable_unprepare/clk_disable_unprepare
- s/prov/priv
- s/error/ret (bcm63xx_rng_probe)
Fixes: 6229c16060fe ("hwrng: bcm63xx - make use of devm_hwrng_register")
Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In commit 0b053c951829 ("lib: memzero_explicit: use barrier instead
of OPTIMIZER_HIDE_VAR"), we made memzero_explicit() more robust in
case LTO would decide to inline memzero_explicit() and eventually
find out it could be elimiated as dead store.
While using barrier() works well for the case of gcc, recent efforts
from LLVMLinux people suggest to use llvm as an alternative to gcc,
and there, Stephan found in a simple stand-alone user space example
that llvm could nevertheless optimize and thus elimitate the memset().
A similar issue has been observed in the referenced llvm bug report,
which is regarded as not-a-bug.
Based on some experiments, icc is a bit special on its own, while it
doesn't seem to eliminate the memset(), it could do so with an own
implementation, and then result in similar findings as with llvm.
The fix in this patch now works for all three compilers (also tested
with more aggressive optimization levels). Arguably, in the current
kernel tree it's more of a theoretical issue, but imho, it's better
to be pedantic about it.
It's clearly visible with gcc/llvm though, with the below code: if we
would have used barrier() only here, llvm would have omitted clearing,
not so with barrier_data() variant:
static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
barrier_data(s);
}
int main(void)
{
char buff[20];
memzero_explicit(buff, sizeof(buff));
return 0;
}
$ gcc -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000400400 <+0>: lea -0x28(%rsp),%rax
0x0000000000400405 <+5>: movq $0x0,-0x28(%rsp)
0x000000000040040e <+14>: movq $0x0,-0x20(%rsp)
0x0000000000400417 <+23>: movl $0x0,-0x18(%rsp)
0x000000000040041f <+31>: xor %eax,%eax
0x0000000000400421 <+33>: retq
End of assembler dump.
$ clang -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004004f0 <+0>: xorps %xmm0,%xmm0
0x00000000004004f3 <+3>: movaps %xmm0,-0x18(%rsp)
0x00000000004004f8 <+8>: movl $0x0,-0x8(%rsp)
0x0000000000400500 <+16>: lea -0x18(%rsp),%rax
0x0000000000400505 <+21>: xor %eax,%eax
0x0000000000400507 <+23>: retq
End of assembler dump.
As gcc, clang, but also icc defines __GNUC__, it's sufficient to define
this in compiler-gcc.h only to be picked up. For a fallback or otherwise
unsupported compiler, we define it as a barrier. Similarly, for ecc which
does not support gcc inline asm.
Reference: https://llvm.org/bugs/show_bug.cgi?id=15495
Reported-by: Stephan Mueller <[email protected]>
Tested-by: Stephan Mueller <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Cc: Stephan Mueller <[email protected]>
Cc: Hannes Frederic Sowa <[email protected]>
Cc: mancha security <[email protected]>
Cc: Mark Charlebois <[email protected]>
Cc: Behan Webster <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:
WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 fixes from Ted Ts'o:
"Some miscellaneous bug fixes and some final on-disk and ABI changes
for ext4 encryption which provide better security and performance"
* tag 'for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: fix growing of tiny filesystems
ext4: move check under lock scope to close a race.
ext4: fix data corruption caused by unwritten and delayed extents
ext4 crypto: remove duplicated encryption mode definitions
ext4 crypto: do not select from EXT4_FS_ENCRYPTION
ext4 crypto: add padding to filenames before encrypting
ext4 crypto: simplify and speed up filename encryption
|