Age | Commit message (Collapse) | Author |
|
commit 6b66d95895c149cbc04d4fac5a2f5477c543a8ae didn't handle SATA PMP
case in ata_acpi_bind_device and will cause a NULL ptr dereference when
user attached a SATA drive to the PMP port. Fix this by checking PMP
support.
This bug is reported by Dan van der Ster in the following bugzilla page:
https://bugzilla.kernel.org/show_bug.cgi?id=48211
Reported-by: Dan van der Ster <dan@vanderster.com>
Tested-by: Dan van der Ster <dan@vanderster.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Tested-by: Simon <tangouniform@sbcglobal.net>
|
|
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
Daniel writes:
Just a few small things to fix regressions, somehow all patches from Jani:
- Fix dpms confusion about which platforms support intermediate modes on
vga.
- Revert the "ignore vbt for eDP bpc" patch, it breaks machines. This will
annoy mbp retina owners again, but windows machines seem to _really_
depend upon this. We can try to quirk the mbp retinas again in 3.8 and
backport the patch.
- Fix connector leaks when the sdvo setup failed, resulted in an OOPS
later on when trying to probe that connector (with it's encoder kfree'd
already).
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: do not ignore eDP bpc settings from vbt
drm/i915/sdvo: clean up connectors on intel_sdvo_init() failures
drm/i915/crt: fix DPMS standby and suspend mode handling
|
|
into drm-fixes
Just a single radeon fix from Alex.
* 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix logic error in atombios_encoders.c
|
|
It is unnecessary to disable preemption explicitly while calling
copy_highpage(). Because copy_highpage() will do it again through
kmap_atomic/kunmap_atomic.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The TTM page can be allocated from high memory. In such case it is
wrong to use the page_address(page) as the virtual address for the high memory
page.
bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50241
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
copy_to_user() returns the number of bytes remaining to be copied, but
we want to return a negative error code here. I fixed a couple of these
last year, but I missed this one.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
Pill i2c fixes from Jean Delvare.
Well, "fixes".. The biggest patch here is actually Jan marking Wolfram
Sang as the main i2c subsystem maintainer, with Jan staying on as the PC
controller maintainer.
* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
i2c-mux-pinctrl: Fix probe error path
MAINTAINERS: i2c: 7 years, this is it
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A few fixes for teardown issues that will be rarely seen, plus a fix
for a silly bug in regulator_is_supported_voltage() which shows how
often the answer to the question should be false.
The supported voltage commit is very new as I just edited to add a Cc
to stable, the code itself has been in -next."
* tag 'regulator-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: fix voltage check in regulator_is_supported_voltage()
regulator: core: Avoid deadlock when regulator_register fails
Regulator: core: Unregister when gpio request fails.
|
|
The 3215 console always has the RAW3215_FIXED flag set, which causes
raw3215_shutdown() not to wait for outstanding I/O requests if an attached
tty gets closed.
The flag however can be simply removed, so we can guarantee that all requests
belonging to the tty have been processed when the tty is closed.
However the tasklet that belongs to the 3215 device may be scheduled even if
there is no tty attached anymore, since we have a race between console and tty
processing.
Thefore unconditional tty_wakekup() in raw3215_wakeup() can cause the following
NULL pointer dereference:
3.465368 Unable to handle kernel pointer dereference at virtual kernel address (null)
3.465448 Oops: 0004 #1 SMP
3.465454 Modules linked in:
3.465459 CPU: 1 Not tainted 3.6.0 #1
3.465462 Process swapper/1 (pid: 0, task: 000000003ffa4428, ksp: 000000003ffb7ce0)
3.465466 Krnl PSW : 0404100180000000 0000000000162f86 (__wake_up+0x46/0xb8)
3.465480 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
Krnl GPRS: fffffffffffffffe 0000000000000000 0000000000000160 0000000000000001
3.465492 0000000000000001 0000000000000004 0000000000000004 000000000096b490
3.465499 0000000000000001 0000000000000100 0000000000000001 0000000000000001
3.465506 070000003fc87d60 0000000000000160 000000003fc87d68 000000003fc87d00
3.465526 Krnl Code: 0000000000162f76: e3c0f0a80004 lg %r12,168(%r15)
0000000000162f7c: 58000370 l %r0,880
#0000000000162f80: c007ffffffff00 xilf %r0,4294967295
>0000000000162f86: ba102000 cs %r1,%r0,0(%r2)
0000000000162f8a: 1211 ltr %r1,%r1
0000000000162f8c: a774002f brc 7,162fea
0000000000162f90: b904002d lgr %r2,%r13
0000000000162f94: b904003a lgr %r3,%r10
3.465597 Call Trace:
3.465599 (<0400000000000000> 0x400000000000000)
3.465602 <000000000048c77e> raw3215_wakeup+0x2e/0x40
3.465607 <0000000000134d66> tasklet_action+0x96/0x168
3.465612 <000000000013423c> __do_softirq+0xd8/0x21c
3.465615 <0000000000134678> irq_exit+0xa8/0xac
3.465617 <000000000046c232> do_IRQ+0x182/0x248
3.465621 <00000000005c8296> io_return+0x0/0x8
3.465625 <00000000005c7cac> vtime_stop_cpu+0x4c/0xb8
3.465629 (<0000000000194e06> tick_nohz_idle_enter+0x4e/0x74)
3.465633 <0000000000104760> cpu_idle+0x170/0x184
3.465636 <00000000005b5182> smp_start_secondary+0xd6/0xe0
3.465641 <00000000005c86be> restart_int_handler+0x56/0x6c
3.465643 <0000000000000000> 0x0
3.465645 Last Breaking-Event-Address:
3.465647 <0000000000403136> tty_wakeup+0x46/0x98
3.465652
3.465654 Kernel panic - not syncing: Fatal exception in interrupt
01: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 00000000 0010F63C
The easiest solution is simply to check if tty is NULL in the tasklet.
If it is NULL nothing is to do (no tty attached), otherwise tty_wakeup()
can be called, since we hold a reference to the tty.
This is not nice... but it is a small patch and it works.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=50431
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
This patch fixes errors seen in identifying old Samsung SLC, due to the
following commits:
commit e2d3a35ee427aaba99b6c68a56609ce276c51270
mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID
commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
mtd: nand: add generic READ ID length calculation functions
Some Samsung NAND with "5-byte" ID really appear to have 6-byte IDs, with
wraparound like:
Samsung K9K8G08U0D
ec d3 51 95 58 ec ec d3
Samsung K9F1G08U0C
ec f1 00 95 40 ec ec f1
Samsung K9F2G08U0B
ec da 10 95 44 00 ec da
This bad wraparound makes it hard to reliably detect the difference
between Samsung SLC with 5-byte ID and Samsung SLC with 6-byte ID.
The fix is to, for now, only use the new Samsung table for MLC. We
cannot support the new SLC (K9FAG08U0M) until Samsung gives better ID
decode information.
Note that this applies in addition to the previous regression fix:
commit bc86cf7af2ebda88056538e8edff852ee627f76a
mtd: nand: fix Samsung SLC NAND identification regression
Together, these patches completely restore the previous detection
behavior so that we cannot see any more regressions in Samsung SLC NAND
(finger crossed). With luck, I can get a hold of a Samsung
representative and stop having to cross my fingers eventually.
Reported-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Tested-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
|
|
A combination of the following two commits caused a regression in 3.7-rc1
when identifying some Samsung NAND, so that some previously working NAND
were no longer detected properly:
commit e3b88bd604283ef83ae6e8f53622d5b1ffe9d43a
mtd: nand: add generic READ ID length calculation functions
commit e2d3a35ee427aaba99b6c68a56609ce276c51270
mtd: nand: detect Samsung K9GBG08U0A, K9GAG08U0F ID
Particularly, a regression was seen on Samsung K9F2G08U0B, with the
following full 8-byte READ ID string:
ec da 10 95 44 00 ec da
The basic problem is that Samsung manufactures both SLC and MLC NAND
that use a non-standard decoding table for deriving information from
their IDs. I have heuristically determined that all the chips that use
the new table have ID strings which wrap around after the 6th byte.
Unfortunately, I overlooked the fact that some older Samsung SLC (which
use a different decoding table) have "5 byte ID strings" which also wrap
around after the 6th byte.
This patch re-introduces a distinction between these old and new Samsung
NAND by checking that the 6th byte is non-zero, allowing both old and
new Samsung NAND to be detected properly.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Brian Norris <computersforpeace@gmail.com>
Reported-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
|
|
The main samsung pinctrl module references the specific exynos4210
pinctrl driver, which selects the main driver in Kconfig.
Making the main driver a silent "bool" option avoid this potential
build error if CONFIG_PINCTRL_SAMSUNG=y && CONFIG_PINCTRL_EXYNOS4=n:
drivers/built-in.o:(.rodata+0x4e4): undefined reference to `exynos4210_pin_ctrl'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
mdiobus_free"
This reverts commit aa731872f7d33dcb8b54dad0cfb82d4e4d195d7e.
As pointed out by Ben Hutchings, this change is not correct.
mdiobus_unregister() can't be called if the bus isn't registered yet,
however this change can result in situations which cause that to
happen.
Part of the confusion here revolves around the fact that the
callers of this module control registration/unregistration,
rather than the module itself.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The chip ready check added by the commit 3ac3546e [Always wait for
the chip to be ready] does not work when the register read/write
is word swapped. This check has been added before the WORD_SWAP
register is programmed, so we need to check for swapped register
value as well.
Bit 16 is marked as RESERVED in SMSC datasheet, Steve Glendinning
<steve@shawell.net> checked with SMSC and wrote:
The chip architects have concluded we should be reading PMT_CTRL
until we see any of bits 0, 8, 16 or 24 set. Then we should read
BYTE_TEST to check the byte order is correct (as we already do).
The rationale behind this is that some of the chip variants have
word order swapping features too, so the READY bit could actually
be in any of the 4 possible locations. The architects have confirmed
that if any of these 4 positions is set the chip is ready. The other
3 locations will either never be set or can only go high after READY
does (so also indicate the device is ready).
This change will check for the READY bit at the 16th position. We do
not check the other two cases (bit 8 and 24) since the driver does not
support byte-swapped register read/write.
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In commit 175c0dff, drivers uses tasklet_kill to avoid put disabled tasklet
on the tasklet vec. But some of the drivers uses tasklet_init & tasklet_disable
in the driver init code, then tasklet_enable when it is opened. This makes
tasklet_enable on a killed tasklet and make ksoftirqd crazy then. Normally,
drivers should use tasklet_init/tasklet_kill on device open/remove, and use
tasklet_disable/tasklet_enable on device suspend/resume.
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
'regulator/fix/supp-volt' into tmp
|
|
regulator_is_supported_voltage() should return true only if the voltage
of fixed/constant regulator is between min_uV and max_uV.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
|
|
The spi_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit bdb498c20040 "TTY: hvc_console, add tty install" took the port
refcounting out of hvc_open()/hvc_close(), but failed to remove the
kref_put() and tty_kref_put() calls in hvc_hangup() that were there to
remove the extra references that hvc_open() had taken.
The result was that doing a vhangup() when the current terminal was
a hvc_console, then closing the current terminal, would end up calling
destroy_hvc_struct() and making the port disappear entirely. This
meant that Fedora 17 systems would boot up but then not display the
login prompt on the console, and attempts to open /dev/hvc0 would
give a "No such device" error.
This fixes it by removing the extra kref_put() and tty_kref_put() calls.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The old ifdef CONFIG_BRCMFISCAN looks wrong to me and it makes more
sense when CONFIG_BRCMISCAN is used.
This patch was just compile tested by me, but not runtime tested.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Franky Lin <frankyl@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
|
|
if we allow compiler reorder our writes, we could
fall into a situation where dev->buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev->buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev->buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev->buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev->buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
(ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints).
This commit causes I2C timeouts to appear on several OMAP3430/3530-based
boards:
http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2
http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2
and appears to have been sent for merging before one of its prerequisites
was merged:
http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
When the firmware is in SNIFFER mode, it leaves
the FCS at the end of frame. Not telling mac80211
means it won't add the right flag to the radiotap
header and that confuses wireshark.
Since mac80211 doesn't have a per-packet flag, set
the HW flag dynamically. This works as the monitor
vif can only be present in the driver by itself.
This fixes a regression introduced by my
commit 578977264199de9815ace51ade87cec4894cf010
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri May 11 10:53:18 2012 +0200
iwlwifi: support explicit monitor interface
Cc: stable@vger.kernel.org [3.5+]
Reported-by: MARK PHILLIPS <mark.phillips@virgin.net>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When regulator_register fails and exits through the scrub path the
regulator_put function was called whilst holding the
regulator_list_mutex, causing deadlock.
This patch adds a private version of the regulator_put function which
can be safely called whilst holding the mutex, replacing the
aforementioned call.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The driver claims to support SMBus quick command but it was not the
case. This patch fixes this issue. Without it, i2cdetect finds imaginary
devices. And with some IP versions, trying to send 0 byte can cause
issue when writing data to an EEPROM.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
[wsa: improved the commit message]
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
|
|
Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
driver.
- We set the default maximum to 0xFFFF because there are several
devices out there that only support two-byte block counts even with
WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
LIMITS VPD.
- max_write_same_blocks can be overriden per-device basis in sysfs.
- The UNMAP discovery heuristics remain unchanged but the discard
limits are tweaked to match the "real" WRITE SAME commands.
- In the error handling logic we now distinguish between WRITE SAME
with and without UNMAP set.
The discovery process heuristics are:
- If the device reports a SCSI level of SPC-3 or greater we'll issue
READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
supported. If that's the case we will use it.
- If the device supports the block limits VPD and reports a MAXIMUM
WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).
- Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
0xFFFFFFFF or the block count exceeds 0xFFFF.
- no_write_same is set for ATA, FireWire and USB.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
Support requests with more than one bio payload for discards. The total
number of bytes to be discarded is stored in req->__data_len and used in
sd_done() to complete the I/O.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
The REPORT SUPPORTED OPERATION CODES command can be used to query
whether a given opcode is supported by a device. Add a helper function
that allows us to look up commands.
We only issue RSOC if the device reports compliance with SPC-3 or
later. But to err on the side of caution we disable the command for ATA,
FireWire and USB.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
In the event of a VXLAN device being linked to a device that has a
hard_header_len greater than that of standard ethernet we could end up with
the hard_header_len not being large enough for outgoing frames. In order to
prevent this we should update the length when a lowerdev is provided.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use eXtensible and not eXtensiable in the comment on top.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When allocating the memory for i2c busses, the code checked the wrong
variable and thus never detected if there was a memory error.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable@vger.kernel.org
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
Commit 6bd4a5d96c08dc2380f8053b1bd4f879f55cd3c9 changed the
ANDROID_ALARM_GET_TIME ioctls from IOW to IOR. While technically
correct, the _IOC_DIR bits are ignored by alarm_ioctl, so the
commit breaks a userspace ABI used by all existing Android devices
for a purely cosmetic reason. Revert it.
Cc: stable <stable@vger.kernel.org>
Cc: Dae S. Kim <dae@velatum.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This change fixes an issue I found where VXLAN frames were fragmented when
they were up to the VXLAN MTU size. I root caused the issue to the fact that
the headroom was 4 + 20 + 8 + 8. This math doesn't appear to be correct
because we are not inserting a VLAN header, but instead a 2nd Ethernet header.
As such the math for the overhead should be 20 + 8 + 8 + 14 to account for the
extra headers that are inserted for VXLAN.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
A number of Huawei 3G and LTE modems implement a CDC NCM function,
including the necessary functional descriptors, but using a non
standard interface layout and class/subclass/protocol codes.
These devices can be handled by this driver with only a minor
change to the probing logic, allowing a single combined control
and data interface. This works because the devices
- include a CDC Union descriptor labelling the combined
interface as both master and slave, and
- have an alternate setting #1 for the bulk endpoints on the
combined interface.
The 3G/LTE network connection is managed by vendor specific AT
commands on a serial function in the same composite device.
Handling the managment function is out of the scope of this
driver. It will be handled by an appropriate USB serial
driver.
Reported-and-Tested-by: Olof Ermis <olof.ermis@gmail.com>
Reported-and-Tested-by: Tommy Cheng <tommy7765@yahoo.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the set_mac_address() function of qeth is invoked, qeth deletes
the old mac address first on OSA. Only if deletion returns
successfully the new mac address is set on OSA. Deletion may return
with a return value "MAC not found on OSA". In this case qeth
should continue setting the new mac address.
When the OSA cable is pulled, OSA forgets any set mac address. If
the OSA network interface acts as a slave to a bonding master
interface, bonding can invoke the set_mac_address function for
failover purposes and depends on successful setting of the new mac
address even though the old mac address could no longer be deleted.
Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Return codes of IPA_CMD_QIPASSIST are not checked, especially the ones which
indicate that the command is not supported. As a result, the device driver
would not enable all available features on older card generations.
This patch adds proper checking and sets the bare minimum in the supported
functions flags to avoid follow-on errors.
Signed-off-by: Stefan Raspl <raspl@linux.vnet.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The device datasheet specifies the BUSY bit must be set when reading
or writing phy registers. This patch ensures we do that.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 73d4066055e0e2830533041f4b91df8e6e5976ff.
Martin Steigerwald reported that this change caused a hard lockup when
using USB if threadirqs are enabled. Thomas pointed out that this patch
is incorrect, and can cause problems. So revert it to get the
previously working functionality back.
Reported-by: Martin Steigerwald <Martin@lichtvoll.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chuansheng Liu <chuansheng.liu@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Dell 5800 appears to be a simple rebrand of the Novatel E362.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
memory leaks) had a small typo which made the driver use wrong
offsets when mapping serial port private data. This results in
in a GPF when the port is opened.
Reported-by: Richard <richjunk@pacbell.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
Device to Host (FIS 0x34) frame Initiator resets phy.
In the frame handler routine response (FIS 0x34) was copied into wrong
buffer and upper layer did not receive any answer which resulted in
timeout and reset.
This patch corrects this bug.
Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
There are laptops out there that need the eDP bpc from VBT. This is
effectively a revert of
commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Aug 10 11:10:20 2012 +0200
drm/i915: ignore eDP bpc settings from vbt
but putting the VBT check after the EDID check to see them both in dmesg if
this clamps more than the EDID. We have enough history with bpc clamping to
warrant the extra debug info.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47641
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56401
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Pull ux500 clk fixes from Mike Turquette:
"Missing clkdev entries are causing regressions on the U8500 platform.
This pull request contains those missing clkdev entries which are
needed to boot that platform."
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
clk: ux500: Register slimbus clock lookups for u8500
clk: ux500: Update rtc clock lookup for u8500
clk: ux500: Register msp clock lookups for u8500
clk: ux500: Register ssp clock lookups for u8500
clk: ux500: Register i2c clock lookups for u8500
|
|
Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call
left behind ghost connectors, attached (with a dangling pointer) to the
sdvo that has been cleaned up and freed. Properly destroy any connectors
attached to the encoder.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Tested-by: bjo@nord-west.org
[danvet: added a comment to explain why we need to clean up connectors
even when sdvo_output_setup fails.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
At the same time the prcc bit for the kclk is corrected to
bit 8 instead of 3.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|