No other SPI controller has this field, and SPI clients should be setting
this up in their own drivers. So drop it from the Blackfin controller to
keep people from using it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
If kmemdup() in hidraw_report_event() fails, we are not propagating
this fact properly.
Let hidraw_report_event() and hid_report_raw_event() return an error
value to the caller.
Reported-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently, if we request for frequency greater than maximum possible, spi driver
returns error.
For example, if the spi block src frequency is 333/4 MHz, i.e. 83.33.. MHz,
maximum frequency programmable would be src/2. Which would come around 41.6...
It is difficult to pass frequency in these figures. We normally try to program
in round figures, like 42 MHz and it should get programmed to <=
requested_frequency, i.e. 41.6...
For this to happen, we must not return error even if requested freq is higher
than max possible. But should program it to max possible.
Reported-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
We were not properly advertising the MODE bits supported by this driver, fix
that.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
We do not need to use a flag to indicate if the master driver is stopping
it is sufficient to perform spi master unregistering in the platform
driver's remove function.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This patch converts the bcm63xx SPI driver to use the SPI infrastructure
pump message queue. Since we were previously sleeping in the SPI
driver's transfer() function (which is not allowed) this is now fixed as well.
To complete that conversion a certain number of changes have been made:
- the transfer len is split into multiple hardware transfers in case its
size is bigger than the hardware FIFO size
- the FIFO refill is no longer done in the interrupt context, which was a
bad idea leading to quick interrupt handler re-entrancy
Tested-by: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
A new enum indicating the dma channel direction was introduced by:
commit 49920bc669
dmaengine: add new enum dma_transfer_direction
The following commit changed spi-ep93xx to use the new enum:
commit a485df4b44
spi, serial: move to dma_transfer_direction
In doing so a sparse warning was introduced:
warning: mixing different enum types
int enum dma_data_direction versus
int enum dma_transfer_direction
This is produced because the 'dir' passed in ep93xx_spi_dma_prepare
is an enum dma_data_direction and is being used to set the
dma_slave_config 'direction' which is now an enum dma_transfer_direction.
Fix this by converting spi-ep93xx to use the new enum type in all
places.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
calculate_effective_freq() was still not optimized and there were cases when it
returned without error and with values of cpsr and scr as zero.
Also, the variable named found is not used well.
This patch targets to optimize and correct this routine. Tested for SPEAr.
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Tested-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
usb: fixes for v3.4-rc cycle
A few more fixes for v3.4-rc cycle.
It includes a couple of fixes to the ordering of the methods in udc-core.c.
Without these two patches, we will have issues when either unregistering a
gadget driver (triggered with dummy_hcd only) or issuing a device-initiated
disconnect through sysfs.
There's also a fix on dummy_hcd to not call ->pullup() from udc_stop() because
udc-core.c already handles that.
A fix to MUSB as promised, to kill the compile warnings regarding deprecated
interfaces. We are essentially dropping the __deprecated flag because it
doesn't look like we will ever be able to live without it when we consider the
amount of silicon issues we find on different MUSB instantiations.
A couple of other fixes are also available, one adding the missing transceiver
events to gpio_vbus and another adding a missing unregister call to MUSB's
davinci glue layer.
Since the last fixes to this driver ensure now the queue termination is
done correctly, we can finally disable the queue after a transfer
without problems. The gain is that it will only be reenabled after the
next transfer is fully set up. Before, the queue was running all the
time and if the setup of the next message was interrupted by another
thread, an incomplete buffer could have been sent, padded with zeroes.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Everytime a HID device is opened, a new hiddev_list is allocated with
kzalloc. This requires 64KB of physically contiguous memory, which could
easily push a heavily loaded system over the edge.
Allocating the same amount of memory with vmalloc shouldn't be nearly as
demanding, so let's do that instead. The memory isn't used for DMA and
doesn't look particularly performance sensitive, so this should be safe.
Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch consolidates the case logic for checking whether a device supports
WoL into a single place. Previously ethtool and probe used similar logic that
was copied and maintained separately. This patch encapsulates the core logic
into a function so that a user only has to update one place.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
During igb_reset(), we initiate a hardware reset which will clear our
flow control settings. For auto-negotiation, we re-negotiate them when
linking up again, but we need to force them off properly for the forced
speed case.
Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Previously, a workaround was added to address a hardware bug in the
PCIm2PCI arbiter where a write by the driver of the Transmit/Receive
Descriptor Tail register could happen concurrently with a write of any
MAC CSR register by the Manageability Engine (ME) which could cause the
Tail register to have an incorrect value. The arbiter is supposed to
prevent the concurrent writes but there is a bug that can cause the Host
(driver) access to be acknowledged later than it should.
After further investigation, it was discovered that a driver write access
of any MAC CSR register after being idle for some time can be lost when
ME is accessing a MAC CSR register. When this happens, no further target
access is claimed by the MAC which could hang the system.
The workaround to check bit 24 in the FWSM register (set only when ME is
accessing a MAC CSR register) and delay for a limited amount of time until
it is cleared is now done for all driver writes of MAC CSR registers on
82579 with ME enabled. In the rare case when the driver is writing the
Tail register and ME is accessing any MAC CSR register for a duration
longer than the maximum delay, write the register and verify it has the
correct value before continuing, otherwise reset the device.
This patch also moves some pre-existing macros from the hardware-specific
header file to the more appropriate generic driver header file.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
In K1 mode (a MAC/PHY interconnect power mode), the 82579 device shuts down
the Phase Lock Loop (PLL) of the interconnect to save power. When the PLL
starts working, the 82579 device may start to transfer the packet through
the interconnect before it is fully functional causing packet drops. This
workaround disables shutting down the PLL in K1 mode for 1G link speed.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
80003ES2LAN has an errata such that far-end loopback may be activated by
bit errors producing a reserved symbol. In order to disable far-end
loopback quickly enough, disable it immediately following a reset.
Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Direct keys usage may not start from KP_DKIN0, add a msk option
to configure the specifics for platforms that can skip some keys.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
KPDK_DK only indicates the pin level of direct key.
So it is related to board, and low level may be active which
indicates that a key is pressed.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
When direcct_key_num is 0, the mask should be 0.
When direcct_key_num is 1, the mask should be 0b1.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
When the keypad is used as wake up source, the clock can not
be disabled. Or it can not detect key pressing.
If the keypad is used as wake up source, when resume back,
do not enable the clock and configure it again because the
register content is retained.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Some boards such as the Intel D2700MUD allow you to have over 4GB of RAM.
The GTT on the PVR based devices is 32bit however. Hugh Dickins points out
that we should therefore be setting the mapping gfp mask.
This is not the whole fix for the problem. Some further shmem patches will
be needed to deal with the corner cases.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This provides the needed callback hooks to add hotplug display support to
the GMA36x0 devices.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In particular clean up the errata handling and correct the crtc masks. We do
this a bit differently using our device abstraction for neatness.
This doesn't address the ACPI opregion and hotplug plumbing, nor the IRQ related
changes that will need. It touches on backlight init but the full backlight
support is not in this change set.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The problem in console mode is lack of linear memory. We can solve that by
dropping to 16bpp. The mode setting X server will allocate its own GEM
framebuffer in 32bpp and all will be well.
We could just do 16bpp anyway but that would be a regression on the lower
modes as many distributions don't yet ship the generic mode setting KMS
drivers.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Introduce a panel presence check for Cedartrail. Non netbook devices don't
necessarily have a panel attached.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull in various i915 bits that we will need to begin tackling the LVDS detect
and ACPI events. We try and drift towards the i915 version of the code with
the long term goal that at least some of it can one day be unified.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't want them uncached, combining will do nicely and fixes the performance
problem with the generic modesetting X server.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to pull more stuff from the VBT in order to configure the clocking
correctly in all cases. Add the relevant bits from the other CDV driver work.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This patch (as1548) fixes a recently-introduced incompatibility
between the UDC core and the dummy-hcd driver. Commit
8ae8090c82 (usb: gadget: udc-core: fix
asymmetric calls in remove_driver) moved the usb_gadget_udc_stop()
call in usb_gadget_remove_driver() below the usb_gadget_disconnect()
call.
As a result, usb_gadget_disconnect() gets called at a time when the
gadget driver believes it has been unbound but dummy-hcd believes
it has not. A nasty error ensues when dummy-hcd calls the gadget
driver's disconnect method a second time.
To fix the problem, this patch moves the gadget driver's unbind
notification after the usb_gadget_disconnect() call. Now nothing
happens between the two unbind notifications, so nothing goes wrong.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 6d258a4 (usb: gadget: udc-core: stop UDC on device-initiated
disconnect) introduced another case of asymmetric calls when issuing
a device-initiated disconnect. Fix it.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>
EDID vendor IDs are always 3 characters long (4 with the terminating
0). It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.
Signed-off-by: Ian Pilcher <arequipeno@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could. Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.
Bugzilla: https://bugzilla.redhat.com/812890
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From Daniel Vetter
- VGA load-detect fix. This bug seems to be as old as the load-detect code
(2.6.30), but needs stupid userspace (upowerd trying to detect
connectors on dpms-off outputs) to actually kill the machine. And
obviously a machine without VGA-hotplug, otherwise we don't do load
detect.
- 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.
- Fix SDVO regression for low-res (pixelclock < 100MHz) digital outputs,
introduce in 2.6.36.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: handle input/output sdvo timings separately in mode_set
drm/i915: fix integer overflow in i915_gem_do_execbuffer()
drm/i915: fix integer overflow in i915_gem_execbuffer2()
drm/i915: fixup load-detect on enabled, but not active pipe
From Inki Dae:
this patch set fixes gem allocation and mapping issue between user space and
physical memory region.
* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung:
drm/exynos: added missed vm area region mapping type.
drm/exynos: fixed exynos_drm_gem_map_pages bug.
drm/exynos: fixed duplicatd memory allocation bug.
On the htc mbox layer, it will assign each endpoint (AC) with a
different Tx-packet-drop threshold, so lower priority AC is more
likely to drop packets and the cookies become more available to higher
priority AC.
On the htc pipe layer, assign the tx packet drop threshold as well, it
will let AC to drop packets when cookies below the tx packet drop
threshold.
Signed-off-by: Kevin Fang <kevin.fang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
When a STA sends huge BK QoS data frame first and then sends BE/VI/VO
QoS data frame, the corresponding throughput becomes much lower than
that without sends BK QoS data frame before.
The root cause is that when station send BK stream, the tx credits of
BK stream don't return back to higher priority QoS stream such as BE,
VI, and VO stream. This patch will handle BK stream properly, when
there is higher priority QoS stream, it will seek tx credits from BK
stream properly.
Signed-off-by: Kevin Fang <kevin.fang@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
bss filter is configured to allow the frames from all the bss other
than the currenly connected one, this is done when a scan is requested
in connected state. There is no reason to filter out the currently
connected bss, configure the filter to allow all the bss. This would
fix the reporting of stale rssi of the current bss while scanning.
Reported-by: Naveen singh <navesing@qca.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
logical speed returned by link_status_query needs to be multiplied by 10.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
