Currently, when a PAN queue needs to be
stopped, we erroneously stop queue number 5
(for example) with mac80211 -- which doesn't
even exist!
To avoid that problem, recalculate the swq_id
for all queues when setting up the queues,
and don't use the default identity mapping
that is acceptable for devices which don't
support PAN.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Previously, we used the swq_id's mechanism
to have AC and HW queue different only for
aggregation queues. To be able to fix a bug
with iPAN simply always build the swq_id as
ac | (hwq << 2) and remove the flag bit.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of passing the txq->swq_id, pass the
txq struct directly to make sure that in the
future nobody will pass an invalid number.
Only three places actually change from using
the txq_id or the skb's queue_mapping to now
using txq->swq_id as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Even if this check were to happen, using the
txq_id here (which is a HW queue) would lead
to confusion in mac80211. Luckily, it doesn't
seem like this can ever happen.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Some variables are misnamed in the FIFO setup
code, fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Set the default led mode for different devices.
For the newer devices such as 6000g2a, 6000g2b and newer,
the default led mode is On/Off instead of blinking.
The led_mode still can be control through module parameter
0: system default
1: On/Off
2: blinking
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Use dynamic aggregation threshold if bt traffic load is high
to reduce the impact on aggregated frame.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
For newer devices, uCode provide both "number of frames sent"
and "number of frames acked" information inside the compressed_ba
packet. So instead of figure the success/failure information through
the bitmap, use those information which is much betrer approach.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Presently each one of the CPUs manually selects the same feature set, and
there's a reasonable expectation that none of these will change for
future CPUs in the SH-Mobile / R-Mobile family, so we move those over to
the top-level ARCH_SHMOBILE.
While we're at it, all of the CPUs support optional GPIOs via the PFC,
do not have I/O ports, and expect sparse IRQ, so we bring the
configuration in line across the board.
This more or less brings the ARM-based parts in sync with their SH
counterparts.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Sysfs attributes affecting device behavior should not be, by default,
world-writeable. If distributions want to allow console users access
these attributes they need to employ udev and friends to adjust
permissions as needed.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
udlfb has undergone a fair bit of cleanup recently and is effectively at
the point where it can be liberated from staging purgatory and promoted
to a real driver.
The outstanding cleanups are all minor, with some of them dependent on
drivers/video headers, so these will be done incrementally from udlfb's
new home.
Requested-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
ERROR: "netif_get_vlan_features" [drivers/net/xen-netfront.ko] undefined!
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix up the issue that array->eof_index needs to be able to be set
even if array->size == 0.
Ensure that we catch all important memory allocation error conditions
and/or kmap() failures.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
This reverts commit 80e60639f1.
This change requires further fixes to ensure that the open doesn't
succeed if the lookup later results in a regular file being created.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Trying to mount NFS (root partition in my case) fails if CONFIG_NFS_V3
is not selected. nfs_validate_mount_data() returns EPROTONOSUPPORT,
because of this check:
#ifndef CONFIG_NFS_V3
if (args->version == 3)
goto out_v3_not_compiled;
#endif /* !CONFIG_NFS_V3 */
and args->version was always initialized to 3.
It was working in 2.6.36
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Nick Bowler reports:
There are no unusual messages on the client... but I just logged into
the server and I see lots of messages of the following form:
nfsd: request from insecure port (192.168.8.199:35766)!
nfsd: request from insecure port (192.168.8.199:35766)!
nfsd: request from insecure port (192.168.8.199:35766)!
nfsd: request from insecure port (192.168.8.199:35766)!
nfsd: request from insecure port (192.168.8.199:35766)!
Bisected to commit 9247685088 (SUNRPC:
Properly initialize sock_xprt.srcaddr in all cases)
Apparently, removing the 'transport->srcaddr.ss_family = family' from
xs_create_sock() triggers this due to nlmclnt_lookup_host() incorrectly
initialising the srcaddr family to AF_UNSPEC.
Reported-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
This is already defined by linux/fb.h now, so punt the duplicate
definition from the driver header.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The function sh_mobile_fb_reconfig() contained a bug,
which caused the line_length to be set wrongly, if a mode
with a different X-resolution than the default one was chosen.
This caused 1080p24 mode to not work on AP4EVB.
Additionally the notifier chain was also called with the wrong
mode.
This patch fixes this, by using the X-resolution of the new
mode instead of the old one to calculate line length and
hands over the correct mode to the notifier chain.
Signed-off-by: Arnd Hannemann <arnd@arndnet.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The addition of CONFIG_SECURITY_DMESG_RESTRICT resulted in a build
failure when CONFIG_PRINTK=n. This is because the capabilities code
which used the new option was built even though the variable in question
didn't exist.
The patch here fixes this by moving the capabilities checks out of the
LSM and into the caller. All (known) LSMs should have been calling the
capabilities hook already so it actually makes the code organization
better to eliminate the hook altogether.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
arm: omap1: devices: need to return with a value
OMAP1: camera.h: add missing include
omap: dma: Add read-back to DMA interrupt handler to avoid spuriousinterrupts
OMAP2: Devkit8000: Fix mmc regulator failure
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
hwmon: (w83795) Check for BEEP pin availability
hwmon: (w83795) Clear intrusion alarm immediately
hwmon: (w83795) Read the intrusion state properly
hwmon: (w83795) Print the actual temperature channels as sources
hwmon: (w83795) List all usable temperature sources
hwmon: (w83795) Expose fan control method
hwmon: (w83795) Fix fan control mode attributes
hwmon: (lm95241) Check validity of input values
hwmon: Change mail address of Hans J. Koch
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hao Wu <hao.wu@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Alek Du <alek.du@intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Harrison Metzger <harrisonmetz@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sam Hocevar <sam@zoy.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
They should not be writable by any user.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oliver Bock <bock@tfh-berlin.de>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The permissions for the lpm debugfs file is incorrect, this fixes it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alek Du <alek.du@intel.com>
Cc: Jacob Pan <jacob.jun.pan@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some of the sysfs files had the incorrect permissions. Some didn't make
sense at all (writable for a file that you could not write to?)
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthieu Castet <castet.matthieu@free.fr>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Damien Bergamini <damien.bergamini@free.fr>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI: sysfs: fix printk warnings
PCI: fix pci_bus_alloc_resource() hang, prefer positive decode
PCI: read current power state at enable time
PCI: fix size checks for mmap() on /proc/bus/pci files
x86/PCI: coalesce overlapping host bridge windows
PCI hotplug: ibmphp: Add check to prevent reading beyond mapped area
pm_qos_get_value had min and max reversed, causing all pm_qos
requests to have no effect.
Signed-off-by: Colin Cross <ccross@android.com>
Acked-by: mark <markgross@thegnar.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
Make sure I2C adapters being registered have the required struct
fields set. If they don't, problems will happen later.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
It's about time to make it clear that i2c_adapter.id is deprecated.
Hopefully this will remind the last user to move over to a different
strategy.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Drivers don't need to include <linux/i2c-id.h>, especially not when
they don't use anything that header file provides.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Michael Hunold <michael@mihu.de>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Delete unused I2C adapter IDs. Special cases are:
* I2C_HW_B_RIVA was still set in driver rivafb, however no other
driver is ever looking for this value, so we can safely remove it.
* I2C_HW_B_HDPVR is used in staging driver lirc_zilog, however no
adapter ID is ever set to this value, so the code in question never
runs. As the code additionally expects that I2C_HW_B_HDPVR may not
be defined, we can delete it now and let the lirc_zilog driver
maintainer rewrite this piece of code.
Big thanks for Hans Verkuil for doing all the hard work :)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit. This is obsolete meanwhile, so fix it and hope the word will spread.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Alan Cox <alan@linux.intel.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Move the logging bits from kernel.h into printk.h so that
there is a bit more logical separation of the generic from
the printk logging specific parts.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
The fix in commit 6b4e81db25 ("i8k: Tell gcc that *regs gets
clobbered") to work around the gcc miscompiling i8k.c to add "+m
(*regs)" caused register pressure problems and a build failure.
Changing the 'asm' statement to 'asm volatile' instead should prevent
that and works around the gcc bug as well, so we can remove the "+m".
[ Background on the gcc bug: a memory clobber fails to mark the function
the asm resides in as non-pure (aka "__attribute__((const))"), so if
the function does nothing else that triggers the non-pure logic, gcc
will think that that function has no side effects at all. As a result,
callers will be mis-compiled.
Adding the "+m" made gcc see that it's not a pure function, and so
does "asm volatile". The problem was never really the need to mark
"*regs" as changed, since the memory clobber did that part - the
problem was just a bug in the gcc "pure" function analysis - Linus ]
Signed-off-by: Jim Bos <jim876@xs4all.nl>
Acked-by: Jakub Jelinek <jakub@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On the W83795ADG, there's a single pin for BEEP and OVT#, so you
can't have both. Check the configuration and don't create beep
attributes when BEEP pin is not available.
The W83795G has a dedicated BEEP pin so the functionality is always
available there.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
