Palmas register set is divided into different blocks (base and offset)
and hence different i2c addresses. The i2c address offsets are derived
from base address of block of registers.
Add inline APIs to access the Palma's registers which takes the base of
register block and register offset. The i2c address offset is derived
from the base address of register blocks.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Palma RTC is capable of generating alarm interrupt. Pass the alarm interrupt
as IRQ_RESOURCE for palmas-rtc sub device driver so that rtc driver can get
irq as platform_get_irq().
Also pass the irq domain in mfd_add_devices() to properly offset the irqs for
sub devices. This is needed when adding device through DT.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The SMI counter is popular -- so display it by default
rather than requiring an option. What the heck,
we've blown the 80 column budget on many systems already...
Note that the value displayed is the delta
during the measurement interval.
The absolute value of the counter can still be seen with
the generic 32-bit MSR option, ie. -m 0x34
Signed-off-by: Len Brown <len.brown@intel.com>
Here we disable HW promotion of C1 to C1E
and export both C1 and C1E and distinct C-states.
This allows a cpuidle governor to choose a lower latency
C-state than C1E when necessary to satisfy performance
and QOS constraints -- and still save power versus polling.
This also corrects the erroneous latency previously reported
for C1E -- it is 10usec, not 1usec.
Note that if you use "intel_idle.max_cstate=N",
then you must increment N by 1 to get the same behavior
after this change.
Signed-off-by: Len Brown <len.brown@intel.com>
Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.
Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out. Inspired by a patch
from Konstantin Khlebnikov. The callchain leading to this, cut&pasted
from Konstantin's original patch:
callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)
Note that the entire locking in the fb helper around panic/sysrq and
kdbg is ... non-existant. So we have a decent change of blowing up
everything. But since reworking this ties in with funny concepts like
the fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.
v2: Drop the -EBUSY return value I've copied, we don't need it since
the we'll take care of things ourselves anyway.
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
References: https://patchwork.kernel.org/patch/1878181/
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.
I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.
Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...
v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
Dave Airlie didn't want me to kill this one from the fb helper
interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
from the driver's ->fb_probe callback to setup the fbdev info
structure.
- Clarify what the ->fb_probe callback should all do - it needs to
setup both the fbdev info and allocate the drm framebuffer used as
backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
vfunc.
v3: Implement clarifications Laurent Pinchart suggested in his review.
v4: Fix another mispelling Laurent spotted.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to check whether we've allocated a new fb since we're not
always doing that. Also, we always need to register the fbdev and add
it to the panic notifier.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The idea behind calling down into the driver's ->fb_probe function on each
hotplug seems to be able to reallocate the backing storage (if e.g. a screen
with higher resolution gets added). But that requires quite a bit of work in the
fb helper itself, since currently we limit new screens to the currently
allocated fb. An no kms driver supports fbdev fb resizing.
So don't bother and start to simplify the code by calling drm_fb_helper_set_par
directly from the fbdev hotplug function, since that's the only thing left in
drm_fb_helper_single_fb_probe which does not concern itself with fb allocation
and initial setup. Follow-on patches will streamline the initial setup
code.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
screen).
- It unconditionally sets the fb, even if no mode will be set on a
given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
the desired fb size, but also should set the modeset->fb pointer.
Explain what's going on in the fixup code after the fb is allocated.
The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.
Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.
v2: Fix commit message spell fail spotted by Rob Clark.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
through the real interface vfuncs, forcing i915 to fake all the
->disable callbacks used by the crtc helper to avoid ugly Oopsen
v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_fbdev_cma_init does the inital fbcon setup by calling down into
drm_fb_helper_initial_config, so no need at all to restore the just
set up configuration right away ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not called by anyone, and really, shouldn't be. Drivers are supposed
either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
Originally this was done differently, but is now consolidated in the
helper functions and no longer done by drivers directly.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It doesn't even show up in any header files and only used iternally.
Originally it was (ab)used to restore the fbcon on lastclose, but that
died with
commit e8e7a2b8cc
Author: Dave Airlie <airlied@redhat.com>
Date: Thu Apr 21 22:18:32 2011 +0100
drm/i915: restore only the mode of this driver on lastclose (v2)
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's only used internally for the sysrq and panic handlers provided by
the drm fb helper implementation. Hence just inline it, kill the
export and remove the confusing kerneldoc. Driver's are supposed to
call drm_fb_helper_restore_fbdev_mode on lastclose.
Note that locking is totally fubar - the sysrq case doesn't take any
locks at all. The panic handler probably shouldn't take any locks
since it'll only make things worse. Otoh it's probably better to
switch things over to the atomic modeset callbacks (and disable the
panic handler for those drivers which don't implement it).
But that's both better done in separate patches.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... it's required. Fix up exynos and the cma helper, and add a
corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.
Note that tegra calls the fbdev cma helper restore function also from
it's driver-load callback. Which is a bit against current practice,
since usually the call is only from ->lastclose, and initial setup is
done by drm_fb_helper_initial_config.
Also add the relevant drm DocBook entry.
v2: Add promised WARN to restore_fbdev_mode.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch use delayed workqueue to check cable state after a certain
time. If extcon-max8997 driver check cable state during booting of
platform, this couldn't send the correct notification of cable state
to extcon consumer. Alwasys, this driver should check cable state
after the completion of platform initialization
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
This patch set default H/W line path according to platfomr data.
The MAX8997 MUIC device can possibly set UART/USB or UART_AUX
/USB_AUX to internal H/W line path of MUIC device. Namely, only
one H/W line is used for two operation.
For example,
if H/W line path of MAX8997 device set UART/USB, micro usb cable
is connected to AP(Application Processor) and if H/W line path
set UART_AUX/USB_AUX, micro usb cable is connected to CP(Coprocessor).
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
This patch make max8997_muic_get_cable_type() function to remove
duplicate code for checking ADC/Charger cable type because almost
internal function need to read adc/chg_type value of MUIC register.
Also, remove *_detach() function, extcon-max8997 driver treat
attach/detach operation of cable in max8997_*_handler() function.
Lastly, this patch move defined constant in header file(include/
linux/mfd/max8997.h, max8997-private.h) because defined constant
is only used in the 'extcon-max8997.c'.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
This patch set default of ADC Debounce Time(25ms) during probe step.
Also, can possible change ADC Debounce Time according to H/W situation
by using max8997_set_adc_debounce_time()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
This patch move defined constants to header file(max77693-private.h)
because of mask/unmask selectively interrupt of MUIC device according
to attribute of H/W board.
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
'max77693_extcon_cable' is used only in this file. Hence
make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
'break' after 'return' is never executed and hence can be deleted.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
'max8997_extcon_cable' is used only in this file. Hence make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.
Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This fixes CVE-2013-0228 / XSA-42
Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
in 32bit PV guest can use to crash the > guest with the panic like this:
-------------
general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
unloaded: scsi_wait_scan]
Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
EIP is at xen_iret+0x12/0x2b
EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
Stack:
00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
Call Trace:
Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
general protection fault: 0000 [#2]
---[ end trace ab0d29a492dcd330 ]---
Kernel panic - not syncing: Fatal exception
Pid: 1250, comm: r Tainted: G D ---------------
2.6.32-356.el6.i686 #1
Call Trace:
[<c08476df>] ? panic+0x6e/0x122
[<c084b63c>] ? oops_end+0xbc/0xd0
[<c084b260>] ? do_general_protection+0x0/0x210
[<c084a9b7>] ? error_code+0x73/
-------------
Petr says: "
I've analysed the bug and I think that xen_iret() cannot cope with
mangled DS, in this case zeroed out (null selector/descriptor) by either
xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
entry was invalidated by the reproducer. "
Jan took a look at the preliminary patch and came up a fix that solves
this problem:
"This code gets called after all registers other than those handled by
IRET got already restored, hence a null selector in %ds or a non-null
one that got loaded from a code or read-only data descriptor would
cause a kernel mode fault (with the potential of crashing the kernel
as a whole, if panic_on_oops is set)."
The way to fix this is to realize that the we can only relay on the
registers that IRET restores. The two that are guaranteed are the
%cs and %ss as they are always fixed GDT selectors. Also they are
inaccessible from user mode - so they cannot be altered. This is
the approach taken in this patch.
Another alternative option suggested by Jan would be to relay on
the subtle realization that using the %ebp or %esp relative references uses
the %ss segment. In which case we could switch from using %eax to %ebp and
would not need the %ss over-rides. That would also require one extra
instruction to compensate for the one place where the register is used
as scaled index. However Andrew pointed out that is too subtle and if
further work was to be done in this code-path it could escape folks attention
and lead to accidents.
Reviewed-by: Petr Matousek <pmatouse@redhat.com>
Reported-by: Petr Matousek <pmatouse@redhat.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Mostly mirrors the s390 logic, as unlike x86 we don't need the
SetPageReferenced() bits.
On sparc64 we also lack a user/privileged bit in the huge PMDs.
In order to make this work for THP and non-THP builds, some header
file adjustments were necessary. Namely, provide the PMD_HUGE_* bit
defines and the pmd_large() inline unconditionally rather than
protected by TRANSPARENT_HUGEPAGE.
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This got missed in the cleanups done for the S390 THP
support.
CC: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull networking fixes from David Miller:
"This is primarily to get those r8169 reverts sorted, but other fixes
have accumulated meanwhile.
1) Revert two r8169 changes to fix suspend/resume for some users,
from Francois Romieu.
2) PCI dma mapping errors in atl1c are not checked for and this cause
hard crashes for some users, from Xiong Huang.
3) In 3.8.x we merged the removal of the EXPERIMENTAL dependency for
'dlm' but the same patch for 'sctp' got lost somewhere, resulting
in the potential for build errors since there are cross
dependencies. From Kees Cook.
4) SCTP's ipv6 socket route validation makes boolean tests
incorrectly, fix from Daniel Borkmann.
5) mac80211 does sizeof(ptr) instead of (sizeof(ptr) * nelem), from
Cong Ding.
6) arp_rcv() can crash on shared non-linear packets, from Eric
Dumazet.
7) Avoid crashes in macvtap by setting ->gso_type consistently in
ixgbe, qlcnic, and bnx2x drivers. From Michael S Tsirkin and
Alexander Duyck.
8) Trinity fuzzer spots infinite loop in __skb_recv_datagram(), fix
from Eric Dumazet.
9) STP protocol frames should use high packet priority, otherwise an
overloaded bridge can get stuck. From Stephen Hemminger.
10) The HTB packet scheduler was converted some time ago to store
internal timestamps in nanoseconds, but we don't convert back into
psched ticks for the user during dumps. Fix from Jiri Pirko.
11) mwl8k channel table doesn't set the .band field properly,
resulting in NULL pointer derefs. Fix from Jonas Gorski.
12) mac80211 doesn't accumulate channels properly during a scan so we
can downgrade heavily to a much less desirable connection speed.
Fix from Johannes Berg.
13) PHY probe failure in stmmac can result in resource leaks and
double MDIO registery later, from Giuseppe CAVALLARO.
14) Correct ipv6 checksumming in ip6t_NPT netfilter module, also fix
address prefix mangling, from YOSHIFUJI Hideaki."
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits)
net, sctp: remove CONFIG_EXPERIMENTAL
net: sctp: sctp_v6_get_dst: fix boolean test in dst cache
batman-adv: Fix NULL pointer dereference in DAT hash collision avoidance
net/macb: fix race with RX interrupt while doing NAPI
atl1c: add error checking for pci_map_single functions
htb: fix values in opt dump
ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6
net: fix infinite loop in __skb_recv_datagram()
net: qmi_wwan: add Yota / Megafon M100-1 4g modem
mwl8k: fix band for supported channels
bridge: set priority of STP packets
mac80211: fix channel selection bug
arp: fix possible crash in arp_rcv()
bnx2x: set gso_type
qlcnic: set gso_type
ixgbe: fix gso type
stmmac: mdio register has to fail if the phy is not found
stmmac: fix macro used for debugging the xmit
Revert "r8169: enable internal ASPM and clock request settings".
Revert "r8169: enable ALDPS for power saving".
...
Pull x86 fixes from Peter Anvin:
"One (hopefully) last batch of x86 fixes. You asked for the patch by
patch justifications, so here they are:
x86, MCE: Retract most UAPI exports
This one unexports from userspace a bunch of definitions which should
never have been exported. We really don't want to create an
accidental legacy here.
x86, doc: Add a bootloader ID for OVMF
This is a documentation-only patch, just recording the official
assignment of a boot loader ID.
x86: Do not leak kernel page mapping locations
Security: avoid making it needlessly easy for user space to probe the
kernel memory layout.
x86/mm: Check if PUD is large when validating a kernel address
Prevent failures using /proc/kcore when using 1G pages.
x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server systems
Works around a BIOS problem causing boot failures on affected hardware."
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Check if PUD is large when validating a kernel address
x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server systems
x86, doc: Add a bootloader ID for OVMF
x86: Do not leak kernel page mapping locations
x86, MCE: Retract most UAPI exports
An empty parameter list (length == 0) is not an error, so succeed MODE
SELECT in this case. If the parameter list length is too small,
return the correct sense code of PARAMETER LIST LENGTH ERROR.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
SBC-3 (revision 35) says:
The PARAMETER LIST LENGTH field specifies the length in bytes of the
UNMAP parameter list that is available to be transferred from the
Data-Out Buffer. If the parameter list length is greater than zero
and less than 0008h (i.e., eight), then the device server shall
terminate the command with CHECK CONDITION status with the sense key
set to ILLEGAL REQUEST and the additional sense code set to
PARAMETER LIST LENGTH ERROR. A PARAMETER LIST LENGTH set to zero
specifies that no data shall be sent.
so our sense code for too-short descriptors was wrong, and we were
incorrectly failing commands that didn't transfer any descriptors.
While we're at it, also handle the UNMAP check:
If the ANCHOR bit is set to one, and the ANC_SUP bit in the Logical
Block Provisioning VPD page (see 6.6.4) is set to zero, then the
device server shall terminate the command with CHECK CONDITION
status with the sense key set to ILLEGAL REQUEST and the additional
sense code set to INVALID FIELD IN CDB.
(chris boot: Fix wrong cut+paste comment in transport_send_check_condition_and_sense)
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Fixes:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-next
head: bc80fbe46b
commit: 593fb1ae45 pps: Move timestamp read into PPS code proper
date: 78 minutes ago
config: make ARCH=sparc defconfig
All error/warnings:
In file included from drivers/tty/serial/suncore.c:20:0:
>> include/linux/sunserialcore.h:29:15: warning: 'struct device_node' declared inside parameter list [enabled by default]
>> include/linux/sunserialcore.h:29:15: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
>> include/linux/sunserialcore.h:31:18: warning: 'struct device_node' declared inside parameter list [enabled by default]
>> drivers/tty/serial/suncore.c:55:5: error: conflicting types for 'sunserial_console_match'
include/linux/sunserialcore.h:28:12: note: previous declaration of 'sunserial_console_match' was here
>> drivers/tty/serial/suncore.c:83:1: error: conflicting types for 'sunserial_console_match'
include/linux/sunserialcore.h:28:12: note: previous declaration of 'sunserial_console_match' was here
>> drivers/tty/serial/suncore.c:85:6: error: conflicting types for 'sunserial_console_termios'
include/linux/sunserialcore.h:30:13: note: previous declaration of 'sunserial_console_termios' was here
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: George Spelvin <linux@horizon.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change to my private email, change to my shiny new kernel.org repos,
and drop outdated entry from the former maintainer. Drop my PCA entry,
too, since it belongs to the I2C realm anyhow.
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
The "Technisat SkyStar USB plus" is a TT-connect S-2400 clone, which the
V4L-DVB drivers already support. However, some of these devices (like
mine) come with a different USB PID 0x3009 instead of 0x3006.
There have already been patches simply overwriting the USB PID in
dvb-usb-ids.h. Of course these patches were rejected because they would
have disabled the 0x3006 PID.
This new patch adds the 0x3009 PID to dvb-usb-ids.h, and adds references
to it within the ttusb2.c driver. PID 0x3006 devices will continue to work.
The only difference between the two hardware models seems to be the
EEPROM chip. In fact, Windows BDA driver names the 0x3009 device with a
"(8 kB EEPROM)" suffix. In spite of that, the 0x3009 device works
absolutely flawlessly using the existing ttusb2 driver.
Signed-off-by: Christoph Nuscheler <christoph.nuscheler@t-online.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We're supposed to return LOGICAL BLOCK ADDRESS OUT OF RANGE, not
INVALID FIELD IN CDB.
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The loop in rd_execute_rw() will never terminate if the
sg element has a zero size. Or it'll spill over into
outer space if the sg element is larger than the available
space.
So we need to add some safety catches here.
Cc: Nic Bellinger <nab@risingtidesystems.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Adjusting of data pointers in net/netfilter/nf_conntrack_frag6_*
sysctl table for other namespaces points to wrong netns_frags
structure and has reversed order of entries.
Problem introduced by commit c038a767cd in 3.7-rc1
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Seems to work just the same as older revisions.
Signed-off-by: Roland Scheidegger <rscheidegger_lists@hispeed.ch>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but an optional property allows linux specific support for rc
maps.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Smatch complains that "cmdbuf[cmdcount - length]" might go past the end
of the array. It's an easy warning to silence by moving the limit
check earlier.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Patch adds information about using v4l2-ctl utility to tune the si470x
radio and example how to use sox+alsa to redirect sound from radio sound
device to another sound device.
Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds virtio-scsi multi-queue support to tcm_vhost. In order to use
multi-queue, guest side multi-queue support is need. It can
be found here:
https://lkml.org/lkml/2012/12/18/166
Currently, only one thread is created by vhost core code for each
vhost_scsi instance. Even if there are multi-queues, all the handling of
guest kick (vhost_scsi_handle_kick) are processed in one thread. This is
not optimal. Luckily, most of the work is offloaded to the tcm_vhost
workqueue.
Some initial perf numbers:
1 queue, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 127K/127k IOPS
4 queues, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 181K/181k IOPS
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
In order to take advantages of Paolo's multi-queue virito-scsi, we need
multi-target support in tcm_vhost first. Otherwise all the requests go
to one queue and other queues are idle.
This patch makes:
1. All the targets under the wwpn is seen and can be used by guest.
2. No need to pass the tpgt number in struct vhost_scsi_target to
tcm_vhost.ko. Only wwpn is needed.
3. We can always pass max_target = 255 to guest now, since we abort the
request who's target id does not exist.
Changes in v2:
- Handle non-contiguous tpgt
Changes in v3:
- Simplfy lock in vhost_scsi_set_endpoint
- Return -EEXIST when does not match
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This prepares for the removal of vou_file.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
