This patch does two things. First it drops the unnecessary work of
searching for enabled VFs when we first bring up the adapter and instead
just uses pci_num_vf to determine how many VFs are enabled on the adapter.
The second thing it does is drop the use of vfdev from the vf_data_storage
structure. Instead we just search the entire system for a VF that has us
as it's PF, and then if that VF is assigned we indicate that the VFs are
assigned. This allows us to still check for assigned VFs even if the
vfinfo allocation has failed, or vfinfo has been freed.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This is meant to fix a bug in which we were not checking for pre-existing
VFs if we were not setting the max_vfs value at driver load. What happens
now is that we always call ixgbe_enable_sriov and this checks for
pre-existing VFs ore requested VFs prior to deciding on no SR-IOV.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The vhost work queue allows processing to be done in vhost worker thread
context, which uses the owner process mm. Access to the vring and guest
memory is typically only possible from vhost worker context so it is
useful to allow work to be queued directly by users.
Currently vhost_net only uses the poll wrappers which do not expose the
work queue functions. However, for tcm_vhost (vhost_scsi) it will be
necessary to queue custom work.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Zhi Yong Wu <wuzhy@cn.ibm.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
In order for other vhost devices to use the VHOST_FEATURES bits the
vhost-net specific bits need to be moved to their own VHOST_NET_FEATURES
constant.
(Asias: Update drivers/vhost/test.c to use VHOST_NET_FEATURES)
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Zhi Yong Wu <wuzhy@cn.ibm.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Asias He <asias@redhat.com>
Signed-off-by: Nicholas A. Bellinger <nab@risingtidesystems.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
From Kukjin Kim <kgene.kim@samsung.com>:
It is including new exynos_defconfig for DT configuration of exynos4
and exynos5 together. The old exynos4_defconfig will be used for non-DT
for a while and we will try to move on using exynos_defconfig for only DT.
* samsung/defconfig:
ARM: exynos_defconfig: enable more platforms in defconfig
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This enables the new EXYNOS5 platforms in the defconfig, and enables DT
support on EXYNOS4.
Other options enabled: USB host, EXT3/4, regulators and tps65090,
networking and a few of the common usb ethernet adapters as well as the
smsc911x controller used on some boards.
I enabled EFI_PARTITION, since it's used on some filesystem images I'm
using. I didn't see a need to keep Solaris and BSD partition format
still enabled.
Finally, framebuffer console, logo and fonts were enabled.
Note that enabling some of these options introduces build coverage
previously missing, thus introducing a few build errors and warnings
for which fixes have been sent out already.
Signed-off-by: Olof Johansson <olof@lixom.net>
[kgene.kim@samsung.com: restored exynos4_defconfig from original]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
From Kukjin Kim <kgene.kim@samsung.com>:
You may think that 'since this is including only samsung spi stuff,
so this should be sent to upstream via spi tree', yeah right. But in
this time, would be helpful to us if they could be sent via arm-soc,
samsung tree for avoiding useless conflicts. Because samsung-dt-spi
branch touches the same driver and it is already in arm-soc tree.
* 'next/devel-samsung-spi' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
spi/s3c64xx: Expand S3C64XX_SPI_{DE,}ACT macros at call sites
spi/s3c64xx: Convert to devm_request_and_ioremap()
spi/s3c64xx: Put the /CS GPIO into output mode
spi/s3c64xx: Fix handling of errors in gpio_request()
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Kukjin Kim <kgene.kim@samsung.com>:
It is including several changes for samsung boards.
* 'next/board-samsung-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Add leds status1 and status2 on Origen board
ARM: S3C64XX: Mark most Cragganmore initdata devinitdata
ARM: EXYNOS: Add missing .reserve field to SMDKC210
ARM: EXYNOS: Add DRM device to SMDK4X12 board
ARM: S3C64XX: Clean up after SPI driver platform data updates
ARM: SAMSUNG: no need to set the value for clk_xusbxti when it is 24Mhz
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The SYSTEM_SUSPEND_DISK system state is never used, so drop it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge emailed kgdb dmesg fixups patches from Anton Vorontsov:
"The dmesg command appears to be broken after the printk rework. The
old logic in the kdb code makes no sense in terms of current
printk/logging storage format, and KDB simply hangs forever upon
entering 'dmesg' command.
The first patch revives the command by switching to kmsg_dumper
iterator. As a side-effect, the code is now much more simpler.
A few changes were needed in the printk.c: we needed unlocked variant
of the kmsg_dumper iterator, but these can surely wait for 3.6.
It's probably too late even for the first patch to go to 3.5, but I'll
try to convince otherwise. :-) Here we go:
- The current code is broken for sure, and has no hope to work at
all. It is a regression
- The new code works for me, and probably works for everyone else;
- If it compiles (and I urge everyone to compile-test it on your
setup), it hardly can make things worse."
* Merge emailed patches from Anton Vorontsov: (4 commits)
kdb: Switch to nolock variants of kmsg_dump functions
printk: Implement some unlocked kmsg_dump functions
printk: Remove kdb_syslog_data
kdb: Revive dmesg command
The locked variants are prone to deadlocks (suppose we got to the
debugger w/ the logbuf lock held), so let's switch to nolock variants.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If used from KDB, the locked variants are prone to deadlocks (suppose we
got to the debugger w/ the logbuf lock held).
So, we have to implement a few routines that grab no logbuf lock.
Yet we don't need these functions in modules, so we don't export them.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The function is no longer needed, so remove it.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The kgdb dmesg command is broken after the printk rework. The old logic
in kdb code makes no sense in terms of current printk/logging storage
format, and KDB simply hangs forever.
This patch revives the command by switching to kmsg_dumper iterator.
The code is now much more simpler and shorter.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
From Al Viro:
BTW, speaking of struct file treatment related to sockets -
there's this piece of code in iscsi:
/*
* The SCTP stack needs struct socket->file.
*/
if ((np->np_network_transport == ISCSI_SCTP_TCP) ||
(np->np_network_transport == ISCSI_SCTP_UDP)) {
if (!new_sock->file) {
new_sock->file = kzalloc(
sizeof(struct file), GFP_KERNEL);
For one thing, as far as I can see it'not true - sctp does *not* depend on
socket->file being non-NULL; it does, in one place, check socket->file->f_flags
for O_NONBLOCK, but there it treats NULL socket->file as "flag not set".
Which is the case here anyway - the fake struct file created in
__iscsi_target_login_thread() (and in iscsi_target_setup_login_socket(), with
the same excuse) do *not* get that flag set.
Moreover, it's a bloody serious violation of a bunch of asserts in VFS;
all struct file instances should come from filp_cachep, via get_empty_filp()
(or alloc_file(), which is a wrapper for it). FWIW, I'm very tempted to
do this and be done with the entire mess:
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Grover <agrover@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The effect of the existing code is that we continue blindly when we
should warn about an invalid allocation unit.
Reported-by: dcb314@hotmail.com
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=44061
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
If we are using a regulator the SD Host Controller and the
regulator should agree about the voltages supported. Use
the common subset that is supported.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
max_current_caps can return 0 if not available from the sd controller.
If no regulator is present or the regulator specifies a current
less then 200ma, we no longer still set the 200mA caps bit anyway.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Aaron Lu <aaron_lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The sd host controller spec indicates the the MAX_CURRENT value may
be returned as 0. In this case other methods need to be used to
return the current. If 0 is returned and there is a regulator,
ask the regulator for how much current is available.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
Reviewed-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Extend the sh_mmcif driver to support GPIO card detection, provided by the
slot function module. The original .get_cd() platform callback is also
preserved for now.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Currently mmc host drivers have to decide whether to enable card
detection before calling mmc_add_host() -- in which case a card
insertion event can arrive before the host has been completely
initialised -- or after mmc_add_host(), in which case the initial
card detection can be problematic.
This patch adds an explicit indication of when card detection should
not be carried out. With it in place enabling card detection before
calling mmc_add_host() should be safe. Similarly, disabling it again
after calling mmc_remove_host() will avoid any races.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add primitive OF support to the sh-mmcif driver, which also makes it
necessary to be able to run without platform data.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add primitive support for OF to the SDHI TMIO glue, which also makes it
necessary to be able to run without platform data.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
The tmio-mmc driver is already using the generic GPIO CD handler in IRQ
mode. This patch adds support for CD polling mode and also checks for
availability of a WP GPIO.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Let SDHI platforms specify mmc_host::caps2 flags in their platform data.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Allow tmio mmc glue drivers to pass mmc_host::caps2 flags down to
the mmc layer.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Card Write-Protect pin is often implemented, using a GPIO, which makes
it simple to provide a generic handler for it.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
This prepares for the addition of further slot functions.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
A simple extension of mmc slot functions add support for CD GPIO polling
for cases where the GPIO cannot produce interrupts, or where this is not
desired for some reason.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
To handle CD and WP SD/MMC slot pins we need generic flags to specify their
polarity.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
struct mmc_host::hotplug is becoming a generic hook for slot functions.
Rename it accordingly.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add regulator support to the sh_mmcif driver, but also preserve the current
power-callback.
Also note, that the card power is not switched off during clock gating
periods, hence there's no need to power it on every time the card is
re-activated.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
From the original version of sh_mmcif the .set_pwr() callback has only been
used to turn the card's power on, and the .down_pwr() callback has been
used to turn it off. .set_pwr() can be used for both these tasks, which is
also how it is implemented by the only user of this API: the SH7724 ecovec
board.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
With aggressive clock gating the clock can be disabled during interface
inactivity. During this time its frequency can be changed by another its
user. Therefore when the interface is activated again and the clock is
re-enabled, its frequency has to be re-read.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
Regardless of whether the MMC bus clock is the same as the PM clock on
this specific interface, it has to be managed separately. Its proper
management should also include enabling and disabling of the clock,
whenever the interface is becoming active or going idle respectively.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
A check for NULL platform data can be conveniently made in the very
beginning of probing. Replace numbered error-handling labels in .probe()
with meaningful names to make any future reorganisation simpler.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Chris Ball <cjb@laptop.org>
Currently the SDHI glue for the TMIO MMC driver installs dummy .get_cd() and
.set_pwr() callbacks even if the platform didn't supply them. This is not
necessary, since the TMIO MMC driver itself checks for NULL callbacks. This
is also dubious if the platform provides a regulator for SD-card power
switching. It is better to only install those callbacks, if they are really
provided by the platform.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Currently the TMIO MMC driver derives the OCR mask from the platform data
and uses a platform callback to turn card power on and off. This patch adds
regulator support to the driver.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Instead of delivering one static clock frequency value, read from the
hardware during probing, enable the tmio-mmc driver to re-read the
frequency dynamically.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Every time the clock is enabled after possibly being disabled, we have
to re-read its frequency and update our configuration.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
We don't have to force-enable MMC interrupts in our .probe() method,
mmc_add_host() will trigger card detection, that will enable all the
necessary interrupts.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
host->dma_ops is not valid if host->usa dma is 0 so protect
host->dma_ops reference in dw_mci_resume
Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add a function to get regulators, supplying card's Vdd and Vccq on a
specific host. If a Vdd supplying regulator is found, the function checks,
whether a valid OCR mask can be obtained from it. The Vccq regulator is
optional. A failure to get it is not fatal.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The tmio_mmc_set_ios() function configures the MMC power, clock and bus
width. When the mmc core requests the driver to power off the card, we
inform runtime PM, that the controller can be suspended. This can lead
to the MSTP clock being turned off.
Writing to any 16-bit hardware registers with the MSTP clock off leads
to timeouts and errors being printed to the kernel log. This can occur
both when stopping the MMC clock and when configuring the bus width.
To fix this, stop the MMC clock before calling put_runtime_pm(), and
skip bus width configuration when power is off.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Simon Horman <horms@verge.net.au>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
The MMC_SLEEP_AWAKE and SD_IO_SEND_OP_COND commands share the same
opcode. SD_IO_SEND_OP_COND isn't supported by the SH MMCIF, but
MMC_SLEEP_AWAKE is. Discriminate between the two commands using the
command flags, and reject SD_IO_SEND_OP_COND only.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
In the current dwmmc driver there is support for selecting IDMAC from
the menu config option. If the support for IDMAC is enabled in the menu
config and the hardware configuration register's DMA_INTERFACE field is
0, the driver will still try to do the DMA initialization.
The dw_mci_idmac_init function currently implemented returns only success
indicating that the DMA initialization is always successful. This patch
adds a check for existence of the DMA IP to allow the DMA initialization.
Signed-off-by: Girish K S <girish.shivananjappa@linaro.org>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
