Jeff Layton [Tue, 11 Oct 2011 10:41:32 +0000 (06:41 -0400)]
cifs: clean up check_rfc1002_header
Rename it for better clarity as to what it does and have the caller pass
in just the single type byte. Turn the if statement into a switch and
optimize it by placing the most common message type at the top. Move the
header length check back into cifs_demultiplex_thread in preparation
for adding a new receive phase and normalize the cFYI messages.
Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <smfrench@gmail.com>
virtio-pci: Use PCI MMIO instead of PIO when available
Currently virtio-pci is specced so that configuration of the device is
done through a PCI IO space (via BAR 0 of the virtual PCI device).
However, use of PCI IO space (aka PIO) is long deprecated, and can be
awkward to use on some systems (for example IBM pSeries machines
typically have many PCI domains, and not all firmware/hypervisor
versions necessarily support PCI PIO access on all domains).
Therefore, it would be preferable for the virtio virtual PCI device to
advertise a PCI memory space (aka MMIO) BAR and have configuration
done through this interface instead. This can be done backwards
compatibly by advertising the MMIO BAR in addition to the existing PIO
BAR so that the guest driver can choose whichever interface.
In anticipation of adding such an MMIO BAR to virtio host-side
implementations (e.g. qemu), this patch updates the Linux virtio-pci
driver to attempt to use BAR 2 (which will be MMIO) in preference to
the existing PIO BAR 0.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Krishna Kumar [Wed, 5 Oct 2011 05:38:59 +0000 (11:08 +0530)]
virtio: Dont add "config" to list for !per_vq_vector
For the MSI but non-per_vq_vector case, the config/change vq
also gets added to the list of vqs that need to process the
MSI interrupt. This is not needed as config has it's own
handler (vp_config_changed). In any case, vring_interrupt()
finds nothing needs to be done on this vq.
I tested this patch by testing the "Fallback:" and "Finally
fall back" cases in vp_find_vqs(). Please review.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
virtio: console: wait for first console port for early console output
On s390 I have seen some random
"Warning: unable to open an initial console"
boot failure. Turns out that tty_open fails, because the
hvc_alloc was not yet done. In former times this could not happen,
since the probe function automatically called hvc_alloc. With newer
versions (multiport) some host<->guest interaction is required
before hvc_alloc is called. This might be too late, especially if
an initramfs is involved. Lets use a completion if we have
multiport and an early console.
[Amit:
* Use NULL instead of 0 for pointer comparison
* Rename 'port_added' to 'early_console_added'
* Re-format, re-word commit message
* Rebase patch on top of current queue]
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Acked-by: Chrstian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Amit Shah [Wed, 14 Sep 2011 07:36:46 +0000 (13:06 +0530)]
virtio: console: add port stats for bytes received, sent and discarded
This commit adds port-specific stats for the number of bytes received,
sent and discarded. They're exposed via the debugfs interface. This
data can be used to check for data loss bugs (or disprove such claims).
It can also be used for accounting, if there's such a need.
The stats remain valid throughout the lifetime of the port. Unplugging
a port will reset the stats. The numbers are not reset across port
opens/closes.
Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Amit Shah [Wed, 14 Sep 2011 07:36:45 +0000 (13:06 +0530)]
virtio: console: make discard_port_data() use get_inbuf()
discard_port_data() used virtqueue_get_buf() directly instead of using
get_inbuf(). Fix this, so that we get accounting for all received
bytes. This also simplifies the code a lot.
Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Amit Shah [Wed, 14 Sep 2011 07:36:43 +0000 (13:06 +0530)]
virtio: console: make get_inbuf() return port->inbuf if present
Instead of pulling in a buffer from the vq each time it's called,
get_inbuf() now checks if the current active buffer, in port->inbuf is
valid. If it is, just returns a pointer to it. This ends up
simplifying a lot of code calling get_inbuf() since the check for
port->inbuf being valid was done by all the callers.
Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Amit Shah [Wed, 14 Sep 2011 07:36:40 +0000 (13:06 +0530)]
virtio: console: Ignore port name update request if name already set
We don't allow port name changes dynamically for a port. So any
requests by the host to change the name are ignored.
Before this patch, if the hypervisor sent a port name while we had one
set already, we would leak memory equivalent to the size of the old
name.
This scenario wasn't expected so far, but with the suspend-resume
support, we'll send the VIRTIO_CONSOLE_PORT_READY message after restore,
which can get us into this situation.
Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sasha Levin [Sun, 14 Aug 2011 14:52:33 +0000 (17:52 +0300)]
virtio-net: Use virtio_config_val() for retrieving config
This patch modifies virtio-net to use virtio_config_val() instead
of a 'if(virtio_has_feature()) vdev->config->get()' construct to retrieve
optional values from the config space.
Cc: Amit Shah <amit.shah@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sasha Levin [Sun, 14 Aug 2011 14:52:32 +0000 (17:52 +0300)]
virtio_config: Add virtio_config_val_len()
This patch adds virtio_config_val_len() which allows retrieving variable
length data from the virtio config space only if a specific feature is on.
Cc: Amit Shah <amit.shah@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Sasha Levin [Sun, 14 Aug 2011 14:52:31 +0000 (17:52 +0300)]
virtio-console: Use virtio_config_val() for retrieving config
This patch modifies virtio-console to use virtio_config_val() instead
of a 'if(virtio_has_feature()) vdev->config->get()' construct to retrieve
optional values from the config space.
Cc: Amit Shah <amit.shah@redhat.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Michal Hocko [Tue, 27 Sep 2011 06:56:03 +0000 (08:56 +0200)]
lguest: move process freezing before pending signals check
run_guest tries to freeze the current process after it has handled
pending interrupts and before it calls lguest_arch_run_guest.
This doesn't work nicely if the task has been killed while being frozen
and when we want to handle that signal as soon as possible.
Let's move try_to_freeze before we check for pending signal so that we
can get out of the loop as soon as possible.
Signed-off-by: Michal Hocko <mhocko@suse.cz> Acked-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Jiri Kosina [Thu, 13 Oct 2011 23:32:33 +0000 (10:32 +1100)]
kmod: prevent kmod_loop_msg overflow in __request_module()
Due to post-increment in condition of kmod_loop_msg in __request_module(),
the system log can be spammed by much more than 5 instances of the 'runaway
loop' message if the number of events triggering it makes the kmod_loop_msg
to overflow.
Fix that by making sure we never increment it past the threshold.
Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> CC: stable@kernel.org
This patch causes the kernel uncompressor to determine the physical address
of the SDRAM at runtime. This allows the kernel to boot on both tegra2 and
tegra3 even though SDRAM is at different physical addresses on both SoCs.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
version of work done by Jong Kim <jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
arm/tegra: prepare Seaboard pinmux code for derived boards
This patch splits out the common part of pinmux and GPIO initialization for
seaboard and derived boards. This code is based on work done by Jong Kim
<jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
Stephen Warren [Wed, 12 Oct 2011 15:54:27 +0000 (09:54 -0600)]
arm/tegra: pinmux: ioremap registers
Use ioremap to obtain access to registers instead of using static
mappings. This reduces the number of users of the static mappings, which
will eventually allow them to be removed.
Note that on Tegra30, the number of register "banks" will decrease to 2,
and the packing of specific bits into registers will change significantly.
That's why this change adds the "*_bank" fields to the pingroup tables,
rather than implementing some more hard-coded scheme.
Also, completely remove the implementation of suspend/resume; Tegra doesn't
yet support suspend/resume, and the implementation is complex for the
general pinmux driver:
* Not all registers are used within each bank, so we probably shouldn't
just iterate over every register in the bank, and save/restore it,
since that would mean touching undefined registers.
* Registers are shared between pingroups, so we can't simply iterate over
each pingroup, and save/restore the registers it uses.
It'd probably be best have probe() calculate a bitmask of actually-used
registers for each bank, and have suspend/resume iterate over those
bitmaps.
Oh, and Real Soon Now, I should be looking into converting this driver to
the new pinmux/pinctrl subsystem, so I didn't want to put too much work
into the current incarnation.
v2: s/space/bank/ to match comments on reg_* fields in pinmux.h.
Re-order bank/reg parameters to pg_readl/pg_writel.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
Stephen Warren [Tue, 11 Oct 2011 22:16:14 +0000 (16:16 -0600)]
gpio/tegra: Convert to a platform device
v3: Make regs variable static. Remove empty init of tegra_gpio_banks.
v2: Retrieve IRQ and memory addresses from resources instead of hard-
coding them. Add back initialization of tegra_gpio_chip.of_node.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Grant Likely <grant.likely@secretlab.ca>
[olof: switched probe routine to __devinit] Signed-off-by: Olof Johansson <olof@lixom.net>
Olof Johansson [Thu, 13 Oct 2011 00:56:33 +0000 (17:56 -0700)]
ARM: tegra: devices.c should include devices.h
Resolves lots of sparse warnings:
arch/arm/mach-tegra/devices.c:102:24: warning: symbol 'tegra_i2c_device1' was not declared. Should it be static?
arch/arm/mach-tegra/devices.c:112:24: warning: symbol 'tegra_i2c_device2' was not declared. Should it be static?
arch/arm/mach-tegra/devices.c:122:24: warning: symbol 'tegra_i2c_device3' was not declared. Should it be static?
arch/arm/mach-tegra/devices.c:132:24: warning: symbol 'tegra_i2c_device4' was not declared. Should it be static?
[...]
Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Stephen Warren <swarren@nvidia.com>
Olof Johansson [Mon, 10 Oct 2011 04:57:04 +0000 (21:57 -0700)]
ARM: tegra: cpu-tegra: unexport two functions
Two static functions that are not exported:
arch/arm/mach-tegra/cpu-tegra.c:59:5: warning: symbol 'tegra_verify_speed' was not declared. Should it be static?
arch/arm/mach-tegra/cpu-tegra.c:64:14: warning: symbol 'tegra_getspeed' was not declared. Should it be static?
Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
projects / karo-tx-linux.git / log